If you have been on a software product development team for any length of time, you have undoubtedly experienced the joy of the proverbial death march. On the off chance that you haven’t, the death march happens when a hard deadline gets set for a product launch, and the development team can’t meet it.
How did the team get there? Let’s rewind to the beginning of the project to find out. An organization's leaders get input from internal and external sources to decide about product priorities. Based on their understanding, they will focus the product development effort on delivering a broad set of customer outcomes.
If the leaders align with Agile principles, they will not dictate to teams when this work needs to be completed. That doesn’t mean they don’t want to know. They do. So, they ask the inevitable question, “When do you think you can complete this work?” Knowing that the devil is in the details, teams will set about coming up with their best estimate and adding some padding.
How much padding is enough? If you add too much, you get called out for being unrealistic. There is pressure to add as little padding as possible most of the time. Furthermore, estimating significant work efforts is a fraught exercise. Teams can NEVER anticipate the magnitude of “unknown unknowns.” In other words, there are always things that you will learn along the work path that you didn’t anticipate before you got there.
Sometimes, unknown unknowns are manageable -- other times, they are not. If they get exposed near the beginning of the project, adjustments may be possible, but in my experience, they happen closer to the end.
Additional risks involve changing requirements. Agile teams “welcome” changing requirements. It would be nice if changing requirements meant less work, but it rarely does. Remember that estimate your team gave at the beginning of the project. THAT’S the time frame everyone remembers.
Product launches are an intricate dance involving many players. Not all of these players are likely to be internal to the company. There are marketing, public relations, sales, support, training, finance, and various business partners. Each of these players will likely have a role to play. Based on their effort, their work will kick in with varying lead times before the prescribed launch date.
Once enough players have engaged in the launch process, moving the date gets increasingly difficult. Meanwhile, the development team(s) have no choice but to continue putting one foot in front of the other. When the current pace of the march toward completion appears insufficient to meet the launch date, the team attempts to speed up.
Speeding up can have its own problems. This usually means cutting corners. Safeguards put in place to achieve quality outcomes get compromised. Inevitably, these compromises will result in unanticipated work -- further threatening the deadline.
Adding resources might be an option, but usually, by the time it becomes clear that the deadline is in jeopardy, all oars are in the water. The only lever available is hours. Longer days. Weekends. The death march begins. Stress levels rise. More mistakes are made. Panic sets in.
The most common outcome is a hasty launch riddled with lots of scrambling to keep the boat floating while recovery efforts get implemented. Burnout rates are high. Attrition rates go up. Stress saps the joy from the work.
Avoiding the Death March
There’s no silver bullet for avoiding the death march. The best and easiest thing to do is to encourage teams to pad their work estimates generously and live with the answer regardless of how inconvenient they may be. Maybe leadership really wanted a fall launch, but teams don’t think it can be done. Don’t push them to “figure out a way.” They’ll do it for you, but the “way” will not be what you want.
The more challenging option is for the entire organization to embrace the Agile philosophy. It’s not enough for product development teams to embrace changes in scope (even late in the process). Everyone involved must make an effort to do this. For that to happen, non-engineering teams (e.g., marketing and customer service) must receive an invitation to anticipate a moveable deadline at the beginning of the effort.
They may need support in utilizing Agile principles to structure their efforts in a way that anticipates a shifting deadline. How they communicate with their stakeholders will be different from the start. External business partners may not be used to working this way, so new approaches may be necessary. Springing these changes on them late in the effort will not work. Preparation is paramount. Finally, when the scope changes -- DON’T HIDE IT! Communicate loudly and widely. Be transparent about options, and don’t allow quality to be compromised.
Some leaders use the “just figure it out” approach to product development. They are not Agile leaders. They will inevitably derail any attempt at Agility. I have seen this behavior play out all too often. Most of us have. Next time you start a product development initiative. Fight to avoid the death march before getting underway. It’s worth it for everyone.
Comments