How to eat an elephant
How do you eat an elephant? One bite at a time!
Likewise, agile collaboration projects are delivered in small bite-sized pieces, delivering small, incremental releases and iterating (we call them milestones which do consist out of X stories).
In more traditional collaboration projects, the (simplified) lifecycle is Analyse, Develop, Test – first gathering all known requirements for the whole product, then developing all elements of the project, then testing that the entire product/project is fit for release. In agile collaboration, the cycle is Analyse, Develop, Test; Analyse, Develop, Test; and so on... doing each step for each feature, one feature at a time.
Advantages of this iterative approach to software collaboration include:
- Reduced risk: clear visibility of what’s completed to date throughout a project
- Increased value: delivering some benefits early; being able to release the product whenever it’s deemed good enough, rather than having to wait for all intended features to be ready
- More flexibility/agility: can choose to change direction or adapt the next iterations based on actually seeing the result and how people appreciate it or not.
- Better cost management: if, like all-too-many collaboration projects, you run over budget, some value can still be realised; you don’t have to scrap the whole thing if you run short of funds
For this approach to be practical, each feature must be fully developed, to the extent that it’s ready to be released, before moving on.
Another practicality is to make sure features are developed in priority order, not necessarily in a logical order by function. Otherwise you could run out of time, having built some of the less important features – as in agile software collaboration, the timescales are fixed.
Building the features of the project "broad but shallow" is also advisable for the same reason. Only when you’ve completed all your must-have features, move on to the should-haves, and only then move on to the could-haves.