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

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."

British Airways - more life & death

Both Croucher and emergn's consultants agreed there are areas of development where agile is not an appropriate choice or, in some cases, even an option. "Approximately 25% of our organization has already changed over to agile. And we are still working to grow that number; but in the process of growing that number we've identified areas where we are certain waterfall development is our only choice," Croucher said.

BA chooses to use the waterfall methodology in areas where there are a lot of requirements that can't be altered; where user communities are long established and the existing infrastructure is functioning at a level that can't be easily topped; and where major operational integration software has been built around an SOA foundation. "These are the 'big bang' areas where a tremendous amount of continuous integration is required and there is no room for discussion or testing of barriers," said Croucher.  


-- from Where Agile development works and where it doesn't: A user story

Digesting this....


Requirements that can't be altered?  How is that a barrier to Agile? Every project has constraints.

Ditto for SOA and, in general, legacy software that has to be accommodated.

"... the existing infrastructure is functioning at a level that can't be easily topped ...."  This smacks of arm-waving.  But if there really is a waterfall process that ain't broke, not only shouldn't you fix it, you should tell the world about it.



"... where user communities are long established ..."  This is the one real issue:  the difficulty of explaining the benefits of Agile to people who have major economic and emotional investments in the status quo.

This article is a specimen of a certain genre of "even-handed", "objective", "above-the-fray" punditry: sure, there's a time and a place for Agile, but NIMBY....

P.S. If you follow the link in that quote to "waterfall model",  you'll see this:

Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. 

Something missing?

More life-and-death Agility

The Rogers Commission found that NASA's organizational culture and decision-making processes had been a key contributing factor to the accident. NASA managers had known that contractor Morton Thiokol's design of the SRBs contained a potentially catastrophic flaw in the O-rings since 1977, but they failed to address it properly. They also disregarded warnings from engineers about the dangers of launching posed by the low temperatures of that morning and had failed to adequately report these technical concerns to their superiors. The Rogers Commission offered NASA nine recommendations that were to be implemented before shuttle flights resumed.

-- from Space Shuttle Challenger disaster - my emphasis.


Individuals and interactions over processes and tools  - if Agile principles had been applied, the Challenger might be flying today.   This makes the quote in my previous post even more hypocritical.

(Thanks to Sasha and Andy at Pathfinder for reminding me of this.)

Life-and-death Agility?

-- picture from Space Shuttle Challenger Disaster

A software development life cycle model (SDLC) is a very important tool for successfully executing a software development project, and it’s important to choose the right approach for the right project.  Some of the factors that would go into choosing the right SDLC model are:

• Risk and Complexity of the Project – you would never choose a very agile approach for building the Space Shuttle software. The risk and complexity of the project is probably the biggest factor in choosing the most appropriate SDLC model for the project. 
• ...

-- quote from Agile versus “Non-Agile” Development


When I read this, my first impulse was to say "just another old-line management type who doesn't get it".  But now I have an uncomfortable feeling about it.  Do I really believe that choosing waterfall development over Agile is a mistake - that the chances are good that it will come back to bite you?  I do - I'm pretty sure I do.

Then do I believe it would be prudent or even possible to use an Agile approach to building shuttle software?  Would I be a fanatic if I said yes?  Would I be inconsistent if I said no?  Don't I believe that Agile is the best way to deal with risk, uncertainty, unknowns? Can there be such a thing as "mission critical Agile", or are there some things that have to be done "the old-fashioned way"?

I certainly don't want to be a fanatic, but I think that if I don't believe that the best way to build the shuttle is with Agile, then there's something deeply wrong with what I do believe.

If I look at it from the standpoint of user acceptance testing, maybe the issue goes away.  Just as skeptics say, "extraordinary claims call for extraordinary proof",  we can say, "mission critical software calls for mission critical testing".

Suddenly this reminds me of how I overcame my fear of Ruby.  I spent years fighting for type safety, and now you're telling me to start typing like a duck?  I thought I could never trust a language like that. But then I realized that TDD is the answer - thank Dave for Rspec! - and I love Ruby to death.

If NASA doesn't have rock-solid acceptance testing, then it doesn't matter what approach you use - you can't trust the product. And if they do have rock-solid acceptance testing,  you're free to pick the most efficient and effective approach, because your problem is now insulated by the solid walls of a black box.

And the most efficient and effective approach will be ... Agile.

This doesn't mean that things don't have to change:  maybe we'd need a higher level of structuring of testing, above Fitnesse and XUnit and Cucumber and Rspec.  Maybe we need automated requirements traceability, but with stories and tests and coverage testing, not BDUF and humongous documents.

But change is what we embrace, and risk is what we face - with

 

Courage!

 

 [Bert Lahr pic from No Cowardly Lions Please!, which did not attribute source]