What does done look like?

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.

Comments

[Glen B Alleman]

David,
The bst starting point is the Dayton Aerospace site. It's at www.daytonaero.com. Go to the ETC page, http://www.daytonaero.com/links/etc.htm. At the bottom is the Integrated Program Management Handbook. This book provides three distinct phases.
1. Government writing the RFP
2. Proposal response
3. Execution
There is an example in the back of a real IMS.
After going though that, I've got some training materials that might help, but getting the vocabulary straight is the starting point.

[David F. Plummer]

Can you identify any web sites that show a good example of an IMS?

[John Sitka]

Done dosen't look like anything,
But if you want to look at it through useful lenses it appears like a wisp of an opportunity or a handshake like the passing of the baton to the next guy. Think of it like a relay race. Your lead runner has a personal best, that is the opportunity for the subsequent runners to take the baton and set the teams best. Here the example is speed because that is the goal, but it could just as easliy be quality, functionality, profit.

The baton passing is the act of being done, a declaration of transition that signals an complete attempt(the leg) and an evaluation(the stopwatch or competitors) as well as a continuing process to something greater. The next day of racing the total doneness state is often interpreted as Zero but that is false with respect to the runners speed or any of the goal measurements such as quality, functionality, profit. A runner dosen't run only one race and an untrained or unskilled individual could never contribute to doneness either. But the end result after training and skills and work can contribute to the value streams of doneness.

Done is only an acceptance of an unrealized goal.

If people could run at the speed of light there might be an arguement for the pursuit of speed "as done". But every other measurement of done could be held to a higher measure.

So when do you stop counting?
When you get to the biggest number.

What's the biggest number?
somebignumber
Oh yeah!, somebignumber + 1

Done, never seen it, but I do forget stuff. I'm very glad I've forgotten how to ask.. "When will you be done?" As it hurts the case more than helps.

[Dave Nicolette]

It seems there are many herring in the sea, and they're all swimming away fast (obscure nerdy joke: the herring are red-shifted).

Glen writes, 'The argument taking place on Agile PM is a fine example of "speak in this way or you're not speaking about agile." "Do exactly these process steps or you're not doing agile."'

That's as may be - I haven't read that particular discussion - but the fact some people speak in that manner doesn't make them spokespeople for agile development, and doesn't make their statements the definition of "agile". The first principle of the Agile Manifesto gives greater emphasis to interactions among people than to process formalities. The very phrasing you cite violates that basic principle. Dogma it may be, but is it "agile" dogma? "Do exactly these process steps" sounds to me pretty much opposite to agile thinking.

[Glen B Alleman]

Keith,
Interesting about the "check" list. Event the agile manifesto is a check of things that are done while doing agile. Certaintly XP is a check list. Scrum a bit as well.
The check list approach can also have a paradigm around it and even an attitude.
Earned Value as 32 items on its check list (ANSI/EIA 748B), as does most Lean processes and certaintly the IMP/IMS Program Events up trough Critical Design Review.

[Keith Sader]

Mike,

Thanks for the response, and I would have to agree with you that the automatic gainsaying of someone not using the approved vocabulary is dogma.

I've just never thought about agile that way. Whenever I give my intro-to-Scrum talk I always say that agile is a heuristic, not a checklist. If you're making decisions that positively impact the 'left' side of the manifesto while doing minimal harm to those items on the right side, you're agile enough. The practices, in my opinion, can differ as long as the software gets delivered and the people involved are satisfied with their work.

I also do think there needs to be some more work/research done on 'agile' enterprises. It's one thing to deliver software, it's another thing to deliver software + product and/or services.

[Glen B Alleman]

Mike,
Thanks for the post. I'm a user of agile software development processes. I'm not a developer (stopped in the 80's) but a manager of project managers. Some doing software development, some doing projects with software development.
The core issue for me is the transisiton from traditional approaches to more agile ones. This is staright forward, since many of the problems with projects start with failing to understand the inappropriate use or application of processes.
Coming from agile software development to project management seems to be harder - for some reason. Recognizing the core project management processes as the basis of "doing project management" seems to be skipped by the agilest.
There is just as much "hacking" in traditional project management as there is in agile development, so we're all in the same boat.
The question as always is - are we agilely managing projects or managing agile software projects?

[Mike Vizdos]

Hi,

Good posting. Informative.

Unlike many of the "Scrum" vs "XP" folks out there, I work with teams in doing that makes sense.

Nothing in "agile" is really new.

That being said, I make sure that people who are starting to associate "agile" with terms like XP and Scrum *understand* what they mean by using those terms.

There is a huge difference between hacking and using "agile."

Oh, and you may want to take a look at my site and one of the postings I posted on "done" by teams -- implementingscrum.com/
cartoons/implementingscrum-
20061127.html

Thank you!

- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com

[Glen B Alleman]

Keith,
Of course it's agile dogma. The argument taking place on Agile PM is a fine example of "speak in this way or you're not speaking about agile." "Do exactly these process steps or you're not doing agile."
The dogma of agile is - as you suggest - just as strong as the dogma of Earned Value, CMMi (not a methodology BTW), and any other "methodology."
Why then all the holier than though response to any critism of any aspect of agile other than to protect the "dogma?"
One common saying in the academic community (we live in a college town) is "the smaller the issue the more the retoric." Maybe that the case here.

[Keith Sader]

Ok, "dogma of agile software development" made me laugh.

Where can I find a copy of this dogma? I must have missed the Agile-Manifesto dogma website.

I understand what you're saying re:"the rest of the project", but there's still way too much SDLC dogma embedded in the software development industry from top to bottom management.