Scott Ambler is a good guy. He’s done some interesting studies of project success for agile projects. If interested, you can see a lot of his work here at his agile modeling site.
Scott, in common with many agilists is an advocate of iterative delivery. I’m there!
He also likes to refer to a ‘special’ type of agile iteration, at the inception of a project; ‘iteration 0’. I like this term. As a tech. guy back in the day, I also liked 0-based indexing in programming languages such as ‘c’ but that’s a different story.
Scott and other proponents of iteration 0 are articulating in ‘agilese’ something that has been done for years in regular projects, basically the Reqs Analysis phase, that is:
- In any project, regardless of size or process approach you always have to have an upfront phase to outline at a high level the project goals, business needs and tech constraints/considerations etc.
- The outputs of this upfront cycle do not produce working deployable code or slivers of systems.
- This set of activities apply equally to both approaches; waterfall and iterative.
Regardless of how you dress it up, iteration 0 (and any prior agile phases) are effectively scoping phases in ‘traditional’ language.
They are all about establishing an initial baseline of ‘just enough’ requirements, as well as other ‘preparation’ type activities such as articulating and putting in place infrastructure requirements (eg: test harness, resource allocation etc.). All extremely familiar to anyone who’s managed any kind of serious project in a traditional phased manner.
The core difference and it is a profound one, is that waterfall approaches attempt to articulate all requirements up front during that phase, expecting them not to change, whereas iterative or agile approaches stress the need to have enough to proceed and understand that the requirements will likely change & be adjusted as new information surfaces. Therefore the time for iteration 0 is short in agile projects, relative to its traditional waterfall counterpart; the requirements analysis phase.
But back to my point, for ‘non-agilists’, understanding that iteration-0 is effectively an early analysis/inception phase will I think, come as some comfort. Documenting the requirements, func. & non-func up front to a ‘reasonable’ level makes much sense. Leveraging a lightweight BRD type doc complete with lightweight use cases is a pretty decent option for larger environments striving to go more agile.
In any case, whether we call it ‘iteration 0’ or ‘requirements analysis’ makes no odds to me, so long as the result is a reasonable sense of what needs to get done in the project, i.e. requirements both func and non-func to a certain acceptable level.
On the flip side of this, if there is an important message that traditionalists should take on board from the agilists regarding this phase, it is the ‘just enough’ mantra. Making that judgment requires real business analysis & project management skill. It is not something that a 5-day Agile SCRUM course will teach. Fortunately your existing experience will be a far better determinant of success in this regard.
