The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Agile & Iterative Development (Newbie Question)

My company has asked me to identify consultancies for a large development project that will last the rest of the year.

Based on what I've read, I believe Agile & Iterative is the way to go, so I've been identifying firms that say they are Agile.

I'd go as far as to say I'm a big fan of the idea of Agile & Iterative.

What are the arguments against Agile & Iterative? Logical, rational, reasonable arguments regarding the actual produced product. I just want to be sure I'm getting a balanced view here.

I'm talking about Agile & Iterative in general, not a specific methodology like SCRUM or XP.
David Jones Send private email
Tuesday, June 05, 2007
 
 
Since it's impossible to get a perfect piece of software after the first try, all software development ends up being iterative, whether it was planned or not. Versions, anyone?

As for agile, it depends mostly on how well the requirements are defined from the onset. For very precise requirements that won't change much, a large body of up-front design and documentation is useful, and going agile will most likely end up being counter-productive.

But the average software development project typically suffers from ill-defined requirements, which will change often to boot, so agile is usually the way to go.
Don't fix what ain't broke.
Tuesday, June 05, 2007
 
 
There is a book perfect for you:

"Agile Software Development Ecosystems" by Jim Highsmith (ISBN 0-201-76043-6).

It is a series of interviews of the gurus of all the agile methods you've heard about: Scrum, Dynamic Systems Development Method, Crystal Methods, XP, Lean, etc.

One constant theme kept resurfacing all through the book.  Here is an exerpt that exemplifies that theme:

"I recently asked the manager of a CMM Level 5 group the question, 'What makes your group successful?'  His answer was nearly identical to the success factors for Trimble's team: experienced software engineers, plenty of experience with the product, proximity, and an amicable group.  If skilled people who work well together are the core elements for success, then everything else should be as absolutely simple as possible...."
OneMist8k
Tuesday, June 05, 2007
 
 
> What are the arguments against Agile & Iterative?

It's said that a problem with Agile is that it's difficult to predict exactly what it will give you, not immediately but over the long term. If you know exactly what you want the product to be many months from now, then you can do that more traditionally.
Christopher Wells Send private email
Tuesday, June 05, 2007
 
 
Agile & Iterative Development in my opinion means continuous communication between all actors (clients,managers,developers). The only argue against communication is that you may repeat your self, annoying and waisting people time with same and same information or that you don't express you very well and people don't understand what you want to say. But, keep doing it, and in time you get better and better in communication.
Megabyte Maniac Send private email
Wednesday, June 06, 2007
 
 
"Agile and Iterative Development" as a general concept covers a wide range of approaches and some of the more difficult issues arise when a specific approach is selected.  Two general issues to address are lack of fixed scope and efficiency of development processes.

If the company has a major project to be completed by the end of the year, it may be difficult to convince management to let the scope float, i.e., not be fully defined.  This is especially true if the company is contracting out the work.  One of the true advantages of an iterative approach is to let the scope evolve.  Concentrate on the details of what is to be done in the current iteration and no more.  Management needs to focus on the big picture at a very high level and on the detailed issues in a very small area and nothing in between.

The second area that can cause difficulties in an iterative approach is inefficiencies in the development process.  If the company is use to 9 - 12 month efforts, then hand-off and turn over procedures can be relatively innefficient.  Going to a cycle of monthly (or shorter) iterations would mean, for example, that a one month test and integration phase is not financially feasible.  If the development cycles are reduced by about a factor of ten, then all of the supporting processes need to be reduced also by about a factor of ten.  Look carefully at the processes leading to hand-off to the development team / organization and the processes when development hands the iteration back.  All of the support organizations need to get on board with an iterative approach and adapt and adjust to fit.

I am convinced of the value of agile development, but it is more than a simple replacement of development methodologies.  The expecations and processes of the overall organization will need to change as well.
Wayne M.
Wednesday, June 06, 2007
 
 
So what is "Agile & Iterative"?  I thought I kept up on the basic buzzwords (or phrases in this case), but missed this one.  I have long been a proponent of "Iterative" but have been suspicious of "Agile".  So how did these get combined?
EMF
Wednesday, June 06, 2007
 
 
Agile and iterative would be bad when the project had a really crystal clear scope and goal, if the specification was set in stone and never meant to be changed. These kinds of projects are bad, since the custoemr always changes his mind on something.
TM Send private email
Wednesday, June 06, 2007
 
 
The agile approach has a number of assumptions which must be in place before it is really effective.

For example:
1. It requires that the stakeholders remain in close contact with the developers. The idea is that the stakeholders are periodically reassessing what they want and what the state of the current development effort is. Many organizations are not structured to allow for this close coupling.

2. It requires an understanding that the final deliverable is not fixed at any point except when the stakeholder declares the project complete. This makes organizations that are set up to validate deliverables against a pre-defined (i.e. a priori) set of requirements uncomfortable. Additionally, the agile method does not support the concept of a fixed development budget very well. An agile process includes an agile budget (i.e. the budget should probably be re-assessed at every sprint or every couple of sprints) Most organizations what to fix a price for the development effort at the beginning and not change it during the process. (a fiction at the best of times)

3. Agile does not support the concept of 'farming out' work very well unless the farmed out work fits within the context of a single sprint or the external development shop is in-sync with your agile methodologies.

4. Agile assumes that the stakeholder is able to correctly assess when a deliverable is 'good enough'. Sadly, some people can never make up their minds or are ill-equipped to make these assessments but are still put in the position of authority. Development has no ability to point to a requirement set and say "It's done.". This makes resource planning for the development shops often very challenging.

5. Agile requires higher levels of communications, not only between members of the development team, but throughout the organization. On the face of it, this sounds like a good thing but managing all those communications interfaces takes time and effort. Often the cost of maintaining communications is not factored into the time planning. Consider that in a group of 'n' people there are n(n-1) possible 1-1 conversations.

Don't get me wrong. I think that, in the right environment, agile methods are very effective, but they can be grossly ineffective in the wrong one.
Just A Guy Send private email
Thursday, June 07, 2007
 
 
Everyone claims to be Agile these days.

Go and read Rapid Development by Steve McConnell. You will then be in a position to ask these consultancies far more challenging and insightfull questions than "are you agile". And remember that Talking the Talk is easy. Check for demonstrable evidence of Walking the Walk.

One final thing, remember that a consultancy business model is based on a) charging the client as much as possible, b) locking the client in as much as possible. Good luck.
Nigel Ainscoe Send private email
Friday, June 08, 2007
 
 
How did you come to that conclusion, while clearly knowing nothing about it? You know, there might be a correlation there.

Agile == Excuse to avoid the overhead of formal systems. Those would be the (albeit very few, and incomplete) basis for repeatable successful software delivery.

Removing the cost of supporting formal systems maximises the efficiency of converting revenue dollars to short term shareholder dividends for a consultancy.

They will attempt to convince you that because all established software development methodologies are immature and incomplete, you are better off without one.

Agile is The Emperor's New Development Methodology.

Iterative == Excuse to defer indefinitely the formal definition of design form boundaries.

You wouldn't even start making a snack without knowing how you wanted it to end up.

With no agreement on what is being built and hence no defined endpoint, a consultancy can leech on to your corporate captial bloodstream indefinitely.

Furthermore a consultancy can never face penalties for non delivery since the it is always possible to deliver *something* especially if it is undefined in functionality and quality can be improved by descoping buggy and non functioning features.

Agile & Iterative you will find yourself hurtingly indefinitely and staggeringly efficiently towards conversion of your budget into some consultancies profit. But it *will* save you having to think about it. Good luck.
Hans Anderson
Friday, June 08, 2007
 
 
Hans Anderson, I haven't read a better trolling in a long time... :)
Don't fix what ain't broke.
Friday, June 08, 2007
 
 
Nigel is pretty much the only person here who hit on the real issue, IMO: don't worry about what companies call themselves "agile", but look for verifiable evidence that they have a history of producing satisfactory code, on time and on budget, etc., whatever actually matters to you.

Agile techniques might be able to help with these things, but there are lots of ways to develop software, and just because you claim to be "agile" doesn't mean you're effective.
Jesse Send private email
Friday, June 08, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz