Roger has made a great point in his post on Milestones Must Be Deliverables.
He says specifically:
The most valuable deliverables will in general be those that exercise risks - usually requirements or architectural risks.
I would like to reinforce that by stating project teams should iterate on the risks until the risks are satisfied.
The typical approach is where the team targets a watered down version of final product/application concept. This first deliverable is then incrementally improved upon on during the remaining iterations. What tends to happen is that the team takes the path of least resistance, from concept to final product, to get that first iteration out. Subsequently developers will defer issues like deployment, distribution, and efficient data access. Often this stuff can't be glued on later without significant cost.
Additionally, if the team is building a system that is replacing an older system, there is a great risk of just rebuilding the legacy system in a new programming language (Java, for example) through a new modern process (Scrum, XP, etc).
The idea of iterating over risks is in alignment with my early comments on the Stress Early, and Stress Often philosophy.
Another point of view on this can be read in Launch Late to Launch Often. In a nutshell, they iterated initially on scalability as that was a greater risk than being first to market.
Risk avoidance is likely to create a huge dept. Maybe this is the first risk that should be eliminated.
Leave a comment