The Vice-President of Development hitched his chair forward, looked intently at the team lead, and deliberately softened his face. He was a master of body language, and he knew the exact fatherly tone of voice he needed to get the job done. The project has gone down in flames after a miserable Death March, and this meeting was a necessary step towards healing, reconciliation, and gearing up for the next project that would go down exactly the same way.

“Nash, you’re a terrific programmer and you have a lot of promise here as a team lead. I hired you, I believe in you, I want to see you succeed. I want to help you, but you have to help me help you. You and Pareto, the Marketing Project Manager, are both saying that the Waterfall Methodology just doesn’t work. Fine. If you both stick with that story, you’ll be ok for now, but to be honest, this company values process and blaming the process doesn’t look great.

“And right now, Pareto’s in a meeting with the Director of Marketing just like you’re in here with me. If you say it was the process, but Pareto says that you and the team screwed up, you’re going down hard and I can’t protect you. You’re out on the street. And you know the Director, he’ll do everything in his power to get Pareto to screw you over.”

The VP paused, watching the lead, waiting for the tell-tale tic. Aha, that subtle squirm. He leaned forward and lowered his voice. “Of course, if Pareto blames the process but you can show that he ignored your warnings about delays and misrepresented progress to the board… Well, that would be different. The Director’d let Pareto go in a shot just to cover his own ass, and he’d forget about you in a week. Just one of those things.”

“Of course, if you try blame Pareto and he blames you, … , well I can’t say what would happen. Not great, but with some work you could get back on the fast track. Better than being fired, for sure. Not as good as if you both stick to your theory that Waterfall doesn’t work, but here’s the bottom line: The way I see it, no matter what Pareto says, you’re better off saying Pareto screwed up than saying it was the methodology at fault. And thanks to the methodology you say doesn’t work, you have the evidence you need to show that Pareto wasn’t doing his job.

“So it comes to this: If he says it’s the methodology and you say it’s him, he goes down hard and you look like a star. If you both say it’s the methodology, well, that’s not bad. If he says it’s you and you say it’s him, well, not great but better than if you whine about the methodology and he says you screwed up: If you try to blame the methodology and he knifes you, you’re a dead man.”

“So, what’s it going to be? Is Waterfall a broken methodology? Or was Pareto doing it wrong?”

The obvious moral of the story is that in the abstract, it’s easy to blame the process. But once a project fails, blaming people for doing it wrong is always safer than blaming the process and taking a chance that the other people will blame you. And this could be why Waterfall survives: It’s the process that optimizes for blaming other people.

Update: A few people have asked whether this story could just as easily be told about Agile. Methodologies are distinguished by whether they conform to Theory D or Theory P.

Theory D methodologies, like Waterfall, make it easy to assign blame later. With Waterfall, marketing can show that the programmers failed to hit their deadlines, and development can show that marketing changed the scope and failed to properly specify their requirements. Theory P methodologies like XP and Scrum constantly recalibrate expectations, so if the result is disappointing, you are left blaming the inelasticity of space-time.

(Discuss)