The concept that defining "done" takes a Big Design Up Front, Water Fall, Plan Driven approach is a common red herring used by agilest. While a strong proponent of agile software development techniques, with direct experience with XP and Scrum, I'm tiring of the approach that agile software is the same an agile project management.
Defining done starts with a simple mission and vision description. For some recent projects I've been on they sound like this:
- For Hubble Robotic Servicing - Fly to Hubble using autonomous rendezvous and dock software, change the battery power system, exchange the wide field camera and do no harm to the telescope.
- For Crew Exploration - carry 4 astronauts to the International Space Station, remain docked for 6 months, return home with crew and any cargo.
- Claims Processing - replace all legacy systems, reduce claims processing cost by X%, and decrease processing time by Y%.
These are all descriptions of done. The details of how to get to "done" must emerge as the project emerges. In many domains (large government contracts) this emergence takes place through a series of review processes, prototypes, design validation tests, demonstrations, and even in the case of Joint Strike a full working aircraft used for a "fly off." (Boeing's lost because it didn't meet th specifications and was ugly) The term used is "assuring the increasing maturity of the program." How the definition of "done" matures is a process defined by the Integrated Master Plan. The Plan is a strategy for getting to done. The Integrated Master Schedule is the sequence of activities needed to assure that the Strategy is being fulfilled as needed by the customer
So What's the Problem Here?
The current discussion about agile software development processes being used as a replacement for agile project management misses several critical points:
- The sins of the past are not the processes of the present - anyone currently using a Waterfall project management process is out of compliance with DoD 5000. Can't make it any clearer. Waterfall is dead, dead, dead. Any and all claiming agile is the alternative to waterfall are comparing their approach to a dead process. Doesn't mean there aren't people out there still using waterfall. But they're using a dead process.
- The processes around project management include many more things than building and testing software as requested by the customer. A simple look at any Project Management methods, PMBOK, Prince2, IMP/IMS, any mature construction or aerospace companies program control handbook will reveal this.
- The discussion around "plan driven" project management processes is similar to the waterfall processes discussion. Plans are strategies. Strategies are hypothesizes. Hypothesizes need tests to verify their validity. These tests are the schedules and projects. Nothing is fixed, nothing can be fixed, without first testing the hypothesis. This is the basis of IMP/IMS, Event Based Planning and Performance Based Earned Value.
So What's Next?
- Have the agilest understand that agile software development is a critical process for the software components of a project, but there are other processes that surround the development of agile software development. These project management process may or may not need to be as agile as the development of the software. This depends on the context and the domain.
- Stop using the term Agile Project Management in the same context as Agile Software Development. This won't happen of course, but it'd sure be nice to start talking about how to improve the project management processes without all the dogma of agile software development and evangelist trying to make everything into an XP or Scrum solution.
