When you are dealing with large amounts of requirements, it is never easy to think about all the possibilities at one time. The design process works a lot better when smaller chunks are handled independently. It is a good trend to do things iteratively. However the art of iterations, is not a science in itself. Having iterations does not mean you are automatically doing it right.
There are many ways to iterate with different durations and you need to choose the best one for you and your team and the task at hand.
Some misconceptions of iterative design need to be addressed.
Simply using an iterative approach should make us better (fallacy - there is more to it)
Iterations are a set length (fallacy - they should not be)
A duration should not be set
In larger teams, where there are many designers working on many segments, you have to coordinate the iterations so they line up. Also by consequence, the iterations tend to be larger. As an example, I have found on average, larger projects experience 4-8 weeks of design and implementation as an iteration.
In smaller teams, you can find an iteration as small as 1-3 weeks. You will also find it harder to secure iterations with respect to testing and proving the iterations works. Larger teams can afford to incorporate resources that test iterations. The length of a duration therefore also depends on the amount to test.
You need to have iterations that vary according to the task at hand. You cannot fix an iteration as a policy only a guideline. It must be agile.
Get your hands dirty
When you are in a smaller team, a designer also has to provide more input into implementations and actually get involved. This is where larger teams sometimes fall short. The larger team, who has an architect who gets his hands dirty will be in a far better position to make a success of their design. No matter the size, architects must code. They must see and experience each iteration and fine tune it, while in it. The duration of a iteration can be adjusted by the architect.
Lastly a word on how to design in iterations:
DesignAbstraction first then DesignRefinement
A good design should be fairly abstract in early iterations becoming more refined over each consecutive iteration. This is to reduce refactoring (as it is time consuming), and to provide less chance of error. If requirements are discovered with each iteration, it should be used as a refinement of the initial abstraction and generalized design, rather than a change in the entire design.
Previous Topic
