Iterative Development
Often, software development/implementation projects suffer from a number of the following problems (they are usually present in business improvement projects as well):
- Large amounts of time and money are expended before there is any visible (executable/testable) result.
- Various types of flaws remain undiscovered for lengthy periods resulting in large amounts of rework when eventually discovered.
- Any development work must wait until all the requirements are documented, agreed, and signed off.
- Changes to the requirements are difficult to manage and expensive.
- The end-users don't get to see the product until it is largely complete - and then ask for significant changes.
These problems generally occur in projects that follow the "waterfall" approach - where requirements are completed before design is started, design is completed before coding is started, coding is completed before integration testing is started, and everything is completed before the business is allowed to use it.
Iterative Development is a fundamentally different approach that addresses these issues. However, it requires a significant mind-set change for all members of the team, which can be quite difficult to make. A number of pointers are provided below, but you are best served by having an experienced practitioner on the team. If you can successfully make the transition to Iterative Development, and all it entails, the rewards are large. There is a significant increase in the satisfaction of the stakeholders, and a reduction in the costs and timeframes of the project.
There is much discussion about how to do Iterative Development well. Based on my experience, I believe the following pointers will help ensure success:
- Set clear objectives for each iteration. For example, "all architectural risks mitigated" or "all features required to support the sales process built and tested". The iteration is not over until the objectives are met.
- Adopt a "just-in-time" mentality. An example would be to not produce the detailed requirements for a feature until you are ready to design, build, and test that feature.
- Don't build reuseable components. Harvest existing components, and enhance them to make them reuseable. If you know a component has reuse potential, then you can build it to be reuseable, so long as at least 85% of the effort and cost is spent on functionality required in this iteration or the next couple of iterations. In other words, don't do it until you have to.
- Understand that a deliverable is never "finished". It only "meets the objectives of the iteration".
- Understand that you do not know if the requirements are complete and correct until the users are all using the system and are satisfied with it (in other words, never).
- Use the risk list to plan the iterations. For example if the requirements for a feature are going to be difficult to pin down (they are identified as a risk), this feature should have its requirements detailed and be designed, built, and tested in an early iteration. Then, the stakeholders can see it, and, based on their feedback, a revision of the requirements, and the resulting modifications planned for a later iteration.
- The entire project schedule falls out of the tension between the opposing pulls of "just-in-time" or "don't do it until you have to" and "mitigate risk early". Hence successful Iterative Development is inextricably intertwined with good Risk Management.
- Make each iteration a "mini-waterfall". That is, for the selected requirements to be completed in the iteration, the requirements are detailed, designed, built, and tested all in the one iteration.
- Overlap the iterations - just a bit. What do the analysts do once they have detailed the requirements for an iteration? Support the designers and developers on the current iteration, and get started the next iteration. What do the programmers do whilst waiting for the requirements? They are still working on the prior iteration. This means if feedback from certain requirements is needed before commencing some others, these are best scheduled to non-consecutive iterations to allow the first one to complete before the subsequent one commences. However it is important that iterations never overlap by more that about 30% of their length, and that no more that two iterations are ever open at the same time. This means that some flexibility in the skills and tasks of the team are necessary.
- Time-box the iterations. This means to set the iteration duration to a fixed length of time (usually 2 to 12 weeks for "typical" projects), and then expand or contract the scope of the iteration to meet the deadline, being mindful of still meeting the objectives of the iteration.
- Have a dedicated project manager to perform the detailed scheduling of iterations. The overall project plan is just a set of milestones and dates. The detailed planning of each iteration is not performed until the start of the iteration. However, this planning is driven from the risk list, and must take into account shared components that are required by multiple requirements. If you do not have a work for a full-time project manager, then the project manager can perform other roles. However, they must be project manager first, and other roles second. Otherwise, the planning may not be done properly, and the whole Iterative Development fabric unravels.
Additional Resources
Online
- Kruchten, P 2001, 'Going Over the Waterfall with the RUP', The Rational Edge, September 2001
