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]