Dancing under the waterfall

I've been interviewing quite a bit recently, and in the interviews, I've had to explain what our development cycle is like. My response:

"NASA is a waterfall shop. We're an agile group."

Some of the more fascinated interviewees have broken out of the interview vibe to ask how that's done. Enough have done so that I've decided to write up how you get your group to be agile when everyone else wants to do waterfall.

What is Waterfall?

Waterfall is something that is best used when you want to make sure that components of a shuttle aren't going to fail. Sure, things can always go wrong. But you want to prove that at every point along the way that due diligence was given to all the details.

In essence, there's a bunch of steps, and traditionally, you have the engineers and developers at every point. Steps are completely done before moving on to the next step. There is no iteration. You get one shot to get it right. As a system goes, it should work, until you get people involved. People don't like saying 'Okay, we're done. On to the next bit,' especially when their buy-in group is large. There will always be one last thing to add.

You need a magician

If you're in an organization that's bought into Waterfall, it's not going away any time soon. Millions have probably been poured into the people that crafted it, the people that maintain it, and the systems that support it. So, to the larger organization, you need do some slight of hand.

It is a magic trick. The large organization is the audience. One person plays the magician, going along with the flow of the waterfall, making everything appear as if it's going along as it always has.

The developers are also an audience. To them, it should appear that they are working in an agile shop. Their development cycles are short, requirements are tightly controlled, and they stop coding on the day they thought they were going to.

You need a spokesperson

The waterfall method assumes that everyone will be available during all parts of the process. It assumes that developers are absolutely vital to requirements gathering and design, as well as the QA after implementation.

No geek I ever met has ever loved requirements gathering. If you want to punish a geek, don't take away telecommuting or the cappuccino machine. Tell them they have to sit in on requirement and design meetings. Just don't blame me if it ends in a envelope opener to the carotid.

You need someone that's technical to be the spokesperson to sit in on these meetings. They need to have the ability to be quizzed relentlessly about the capabilities of your system, and answer quickly and accurately. No "I'll take it back to my team..." Next time, they'll just ask for the team to come.

You need to forget

One disadvantage of dancing under the waterfall is that once you're done coding, you don't deploy quickly. There's lots more paperwork and testing to go through before you hit the build button. So the build procedure that you have at the end of the development cycle needs to be flawless... because you're not seeing it again for a few weeks. For our group, it can be up to six weeks before we actually do a build for any release.

The developers must come to terms with this. It's not elegant, it kills the momentum, but it's as good as one can usually get under waterfall. There's good news though!

Keep 'em busy

The biggest trick to keeping everyone under an agile system is being able to think about three releases at once. Why do you have to do this? Because while you're gathering requirements for one release and following the QA on another, they're writing a completely different release.

So, let's say we're working on NASA Science 2.1.

2.0 is in QA and being prepped for deployment.

2.2 is the release I'm gathering for.

Once 2.1 is done, they immediately get the next set of requirements, coded into tickets that are ready for work.

Sound like a lot of work?

Well, let's just say it's good that I'm dancing under a waterfall. One can get pretty sweaty.