Conventional Thinking About Planning – Morphed from Engineering Iterative Project Management / 03 - Lifecycle Planning Specify Design Develop Test Change Over The Conventional Project Lifecycle Requirements Analysis Design Code Test Deploy The ‘Waterfall’ Software Development Lifecycle
Waterfall Planning is based on several beliefs (from book):
Products can be completely developed in one pass
Requirements can be completed and frozen early
All requirements are of equal importance
Designs can be verified without building and testing something.
The entire project can be planned in detail with a high degree of precision at the start of the project
Everything important can be known at the beginning of the project
The project can ‘earn’ value by only doing one discipline at a time.
Most importantly, if we follow the prescriptive steps of our process, then all the project risks will be addressed and therefore one should measure teams on their ability to follow a plan and managers on their ability to create a plan .
Documentation intensive, etc.
The waterfall process attempts to do each step very well and eliminate redoing any steps again, once a step is completed
The plan itself is regarded as ‘lock’ and ‘contract;’ inviolate and perfect.
Comparing Conventional and Iterative Thinking on Planning Iterative Project Management / 03 - Lifecycle Planning Conventional Progressive Risk agnostic Actively attacks risk Risks drives the iterations. Predictive planning Adaptive planning Planning can respond to change Subjective measurement of progress Objective measurement of progress by demonstration of business value Delays integration and testing Continuous integration and testing Not done until the end where time is scrunched Nothing runs until the end Something executable produced every iteration Vice subjectively measure progress Difficulties at the end of the project Difficulties at the start of the project
Seven Habits of Successful Iterative Project Managers (book)
Break large projects into smaller projects and then break the smaller projects up into iterations
Attach the greatest risk in the earliest iterations
Produce something demonstratable every iteration
Do not delay integration and test
Every iteration should include integration and test activities
Be prepared to make mistakes and explore blind alleys.
Mistakes are to be encouraged if they reduce the project risk or challenge the project’s assumptions.