Agile Development

Someone asked me the other day about agile development. Should we do it? Can we reduce the time we spend on requirements if we are doing agile development? Is it only good for some kinds of projects?

If you're reading this blog there is a good chance you know about Agile and have an opinion about it. Here's your chance to join in the fun by commenting on this post.

I jotted down these notes to share with my friend who asked the questions.

• What is it?
– There are a number of ‘agile’ methods with some similarities and differences. (Extreme Programming, Scrum, etc.)
– These methods all use an iterative and incremental process to develop multiple releases of a software product.
– Iterations can be measured in days, weeks, or months.
– Not all releases are necessarily ‘production’ releases but even ‘internal’ releases are working software and not prototypes or ‘throw-away’.
– Business people are actively involved, providing requirements and reviewing release results.

• What Agile is NOT?
– Agile is NOT a way to get software without requirements.
– Agile is NOT a way to get software without testing.
– Agile is NOT a way to get software without planning.
– Agile is NOT a development methodology you can adopt successfully overnight.

• Some challenges to be aware of:
– As iterations become shorter, it becomes more challenging to deliver complete features with meaningful business value in each iteration.
– The first iteration may be especially difficult as it may include a lot of up-front costs and not many features.
– Developing and managing the overall plan for a project with many iterations can actually be more difficult than for a project with a single iteration.
– Integration can be a significant challenge for larger projects with lots of iterations and builds.
– Without careful attention to project planning, management, and control there is a tendency for agile projects to deteriorate into chaos.

• Agility is a good thing (done correctly).
– Becoming agile is a journey, not an overnight transition.
– A good way to begin the journey is to shorten the iteration cycle time for your software projects. Look for opportunities to make the iterations smaller and shorter.
– Insist on active business involvement in providing (and prioritizing) requirements and reviewing software releases.
– Do the right level of requirements documentation for the project size, complexity, and risk. Don’t look at agile as a way to get software without requirements.
– Do the right level of planning, testing, and change control for the project size, complexity, and risk.
– The Seilevel way of documenting requirements works well with iterative and agile development methods.