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]