I sat through a two-day presentation on project estimation and lifecycle selection by Steven Tockey of Construx Consulting. The material was exceptional as I would expect from a company owned by Steve McConnell of Code Complete fame.
When we got to the Agile approach, he explained scheduling as follows:
--------------------------------
From your prioritized
wish list, decide what your next development cycle will create by
assigning resources to work items until available resources = 0. Plan your cycle to operate on a 4-6 week schedule and keep iterating until the wish list is complete.
He also discussed the
fact that Agile doesn’t allow for structured requirements development.
As we know, Agile people will tell you “just put it on the prioritized
wish list”. The idea of placing
requirements on the wish list is correct, but it is too difficult to be
executed and managed well (without proper tools) on varying types of
projects where requirements development and critical path become too
complex.
---------------------------------
Mr.
Tockey’s view of Agile is correct by the terms of Agile, but the root
failure in both camps comes from ignoring the differences between
push-based and pull-based development. In pull-based Lean development an arbitrary release schedule of 4-6 weeks is not only silly but it creates bad behavior. Push-base Agile creates
starting and stopping in the development process and also allows for
Parkinson’s Law to play a greater role in the project. While
Agile restrains Parkinson’s Law greatly when compared to a Code/Fix or
waterfall model, it still allows for ill-effects and your real
awareness of underlying problems is limited to a window that opens
every 4-6 weeks. By then the awareness can be dulled by other side-effect interactions that happen as a result of the core problem.
This leads me to think there needs to be a list of rules for Lean project management systems similar to Chris Date’s 12 Rules of Distributed Databases. These rules need to be more than just guidelines or suggestions. On these rules, any implemented system can be judged on effectiveness. For example, one rule might be “any lifecycle model can be followed under lean through gating techniques.” A
second rule that balances the first could be “projects should never be
constrained to one lifecycle model during their lifetime due to
changing conditions over the natural course of the project.” It
isn't until Lean can be described in these project management
terms that it can be embraced by the Construx's of the world.