Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Punitive Agile: The Forgotten Phase in Waterfall

May 18th, 2011 · 5 Comments

Eighty Percent Done Feels Like Twenty Percent of the Way There
We’ve all been there. The project is 80% through and all the pieces that were built separately are finally starting to get bundled together. The back office gets connected to the service bus, the service bus gets connected to the web app, the web app gets some data from a mainframe data feed… blah blah blah. The only problem is that nothing works. Rightfully so, everyone is freaking out.

If you’ve been in this situation, you know what happens next. The project goes into crisis mode. Executives, project managers, and stakeholders start making apostate statements that contradict every process and principle of the last fourteen months. Phrases like the following are heard in status meetings, checkpoints, etc:

  • I don’t care what else Joe is working on. Just lock him and everyone else in the same room until they figure it out.
  • Process? Don’t talk to me about process. Talk to me about what needs to happen to get this project into production.
  • If there is something preventing you from making progress, I want to know about it right away. Why? Because I’m going to get it out of the way that’s why. I don’t care what the problem is or who’s causing it – getting this project live is more important than everything else.
  • Just forget about the requirements documents. Just call Mary when you have a question and do whatever she says. Then, as soon as you are done, deploy it to test and get her to give you a thumbs up or thumbs down. Then just move to the next thing on your list.
  • It doesn’t matter who does what. Even if it means you work on something you don’t like or aren’t super good at, we just have to keep making progress and we’re not going to wait for Mike to free up just because he usually does the widget development!
  • We don’t have time to write formal test scripts – just find a business person who can explain how it’s supposed to work and then test it the best you can
  • Every morning we are going to get together and have a quick planning session. There will be no sidebars, no debates, no discussions. Just tell me what you’ve done, what’s next, and who you need me to kill

I’ve seen this happen at least a dozen times on waterfall projects that I’ve been on. Most of them were ultimately successful, but the last 20% of the project felt like we were expending more effort than the whole first 80% of the project. This phase is typically accompanied by 12-18 hour days, multiple checkpoints per day with executives, and catered meals (only so you can keep working without stopping to eat).

Every Successful Waterfall Project Has It

I like to tell people that I’ve got a half-billion dollars of waterfall projects on my resume. I’m pretty sure this is in fact true – in the first ten years of my career I was a part of multiple $100 million plus projects, most of which were epic failures. But I was also on some dramatic successes. Every single one of the successful waterfall projects I was on went through the punitive agile phase I describe above, without exception. I don’t think a waterfall project can succeed without it.

What Happens in the Punitive Agile Phase?
So, let’s use agile terminology to describe what happens in the Punitive Agile phase:

  • Colocation
  • Collaboration
  • Continuous Planning
  • Continuous Acceptance Testing
  • Standups
  • Roadblock Removal
  • Collective Code Ownership

All of these things become critical practices at the very end of a waterfall project in spite of the fact that most of the people on the team don’t even know that agile has given them names. On the projects where I saw this happen, we didn’t do them because someone on the project had been on an agile team once upon a time and thought that it would be a good time to introduce the concept. That wasn’t it at all – without any knowledge of agile, we made a value shift that we instinctively knew had to be made if we were going to have any chance at being successful. The value shift we made was pretty much identical to the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It’s Not Fun or Sustainable – that’s Why I Call it Punitive

I actually enjoyed the punitive agile phase of the waterfall projects, at least until the long hours and constant stress of it all started to wear tempers, minds, and bodies to nubs. I often bemoaned the fact that it was impossible to work like this forever, because it was clear to me that it was a much more effective way of building software than the high risk nature of the waterfall approach.

It doesn’t take long for the punitive nature of this phase to rear its head, and not just because of the reasons I just mentioned. There is also the fact that entering into this phase is perceived as a failure, and even if you pull it out in the end, no one is going to forget the last two months of “Hell” that made it all possible. There will be a post-mortem, where the developers will say that if the PM had only made the business stick to their original requirements this would never have happened. The project manager will say that if he’d only been given the resources he’d asked for from the very beginning this would never have happened. The executives will say that if you’d done a better job planning the project and coordinating with supporting teams this would never have happened. The thing that no one will say is this:

If we had only worked in the first 80% like we did in the last 20%, it would have been fun, sustainable and this never would have happened.

Drop the punitive. Just do the agile.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

5 responses so far ↓

  • 1 Mike Kelly // May 19, 2011 at 8:53 pm

    First, to dispel any confusion, let it be known that I /do/ make the best widgets.


    Excellent post. Brings back some fond – and not so fond – memories.

  • 2 Michael Marchi // May 24, 2011 at 8:03 am

    I think the punative phase is a management constant. It can be applied to Agile projects as easily as it can with Waterfall. Although Punative Agile is just as dysfunctional as Weaponized Scrum ( — and neither can be truly called agile, or healthy.

  • 3 David Christiansen // May 24, 2011 at 8:19 am

    Absolutely true! Punitive agile is unhealthy no matter when it happens. The irony of punitive agile in a waterfall project is that it 1) is more healthy than a waterfall death march and 2) it is often the key ingredient in making an otherwise doomed waterfall project a success

  • 4 Steve Vernon // Aug 9, 2011 at 7:57 pm

    Great post – I read it and passed the concept along to my current team as some of the group is heading this direction again – as always! Procrastination, risk avoidance, issues that get hidden until the end – never ending story, but gotta love it as it is an option to teach and reinforce agile again!

  • 5 Agile Adoption Approaches in the Wild | Information of Technology. // Sep 21, 2011 at 5:36 am

    […] Agile Punitive agile is the last phase of a waterfall project, when project leaders shed all but the essential processes […]

Leave a Comment