Life/Death/Agility 5: Criticality and Changeable Requirements

Milo Todorovich has pointed me to the granddaddy of FUD-on-Agile, Life/Death division:  Balancing Agility and Discipline: A Guide for the Perplexed  by Boehm and Turner.  I'm trying to find a copy (IEEE wants $19 - hello, I'm broke!).  I intend to post episode 4 of this series shortly, where I magically demonstrate the ultimate Agile approach to criticality, but meanwhile, here's a corrective to B&T - read the whole post:

The Boehm and Turner book is generally very informative and useful; I still turn to it as one of a handful of books that help me with Agile project management on a practical level. But here they seem to reflect the fear of adaptive development that was common in the early days. Organizations were reluctant to risk an important project on an approach that was, in their experience, unproven. Circa 2002 or 2003, the authors' guidelines made sense. In the 2006-2007 time frame, as the industry moves toward institutionalizing adaptive development at the enterprise level, we need decision criteria that are more in keeping with the realities of large organizations, and with the (now) proven ability of adaptive development to deliver high value and high quality results. 

Criticality and Changeable Requirements

Because the criteria presented by Boehm and Turner are reiterated on Wikipedia , and will therefore be read by many, let's begin by re-examining them. First, I disagree with the authors' understanding of the criticality criterion. In our experience, it is precisely on projects of high criticality that adaptive methods have shone. Predictive methods tend to bog down in paperwork and procedure. By the time project teams have completed the heavyweight up-front analysis required with the predictive approach, the criticality of the proposed project may well have escalated to crisis proportions. An adaptive approach enables us to deliver results incrementally, and thus to begin to chip away at the critical problem almost immediately. Customers are usually more satisfied with that outcome than with the typical outcome of predictive projects. Increasing the chances of success is surely all the more important when the project is critical. 

-- When to be Agile, by Dave Nicolette

More FUD on Agile

The notion that the XP team leader tells the customer "Sorry, I can't commit to anything" is a bit of anti-XP propaganda that has been spread around. I can't imagine I'd get much business if I told people that.

-- Charlie Poole on Contractor Rate Based On Velocity - thread in Yahoo XP group

I haven't seen that, but it's not that different from the unbearable lightness of requirements.

Life/Death/Agility 4: The Unbearable Lightness of Requirements

Another in the ongoing miniseries, Life/Death/Agility.

I've seen this argument online and heard it in conversation: the reason you can't use Agile on serious projects like the Shuttle is that there are hard requirements that can't be changed.

Apparently it's a principle of Agile that the developers can change requirements. 

I can just see a team explaining to a NASA manager, "We understand you thought you had this requirement, but you have to get over it and embrace change: because of the Agileological refactorization/cohesion principle, we're going to have to make the heat-resistant tiles out of Charmin."