Unintended Consequences - The Agile Death March
/In project management, the phrase "death march" refers to the demoralizing experience people assigned to a doomed project have just prior to and during its death throes. Agile teams generally avoid this type of death march by surfacing risk early and appropriately adjusting course. However, there is another type of death march that Agile teams can experience, and this Agile death march can prove equally if not more damaging to the organization than the type experienced by non-Agile teams. To illustrate the Agile death march, let me tell a little story.
Agile at XYZ Corp
Mary had been in product management at XYZ Corp for 7 years. In that time she had led 2 initiatives that had been successfully delivered but, alas, arrived too late resulting in low sales and dissatisfied customers. To speed up time to market, Mary and her team decided to adopt an Agile approach.
In the new approach, Mary built and ordered a product backlog making sure that the highest value items were at the top. To everyone's surprise, in the very first iteration, the team actually completed a few of the highest priority items. The stakeholders attending the review session were ecstatic when they learned that they could, if they wished, begin using the working features right away. The team basked in the stakeholders' delight. Getting up and going to work gained meaning and purpose. Team morale soared.
This same scenario played out iteration after iteration — the team would complete a set of features and the stakeholders would be delighted. However, with each subsequent iteration, the value of the items being built was lower than the preceding iteration. Mary recognized this diminishing return and decided to introduce some new high value items to the top of the product backlog based on feedback she had been collecting from customers using the product.
On hearing that Mary was going to introduce some new features, alarm bells started going off throughout the organization. Cries of "Scope creep!" and "But what about the features that haven't been delivered yet?" rang out. Mary tried to explain the higher value that the newly introduced features would provide, but her arguments fell on deaf ears. She was told to "Stay the course" and not to deviate from her initial plan.
As the team approached the mid-point of the original product backlog, they noted that stakeholders had stopped coming to their reviews. Gradually, over the preceding iterations, the excitement that had accompanied the reviews had faded. In addition, when the team needed clarification from a customer on an item they were working on, the customer who had formerly been happy to answer their questions no longer had time for them. They just didn't see value in spending time talking about a feature they didn't really need.
Mary and her team were baffled. Why were they being forced to deliver the remaining features if no one wanted them? Mary's arguments to introduce more valuable items were countered with arguments that "We must meet market expectations" and "keep promises made" despite evidence that earlier assumptions about the market value of the remaining promised features were invalid.
One day Mary arrived at work to find that 3 of her most senior and talented team members had resigned. In their exit interviews, each had said that they missed the obvious delight of the customers who used to come to the reviews. Further, working on items that customers didn't want was demoralizing. In essence, the team was suffering from delight withdrawal.
Unwittingly, the organization had switched from one death march to another. In Mary's earlier 2 initiatives, the team knew they were going to be too late to market and were forced to continue anyway — the classic project management death march. In the new initiative using an Agile approach, the team delivered faster and delighted their customers, but once the high value features had been delivered, the team entered an Agile death march where they were forced to continue working the product backlog which now contained only low or no-value features.
Interestingly, in 2002, Jim Johnson, chairman and founder of the Standish Group, published results of a survey which asked customers who had requested features in custom-built applications what features they actually used in the delivered application. The results indicated that 45% of requested features were never used. Iterating on the Pareto principle, it becomes clear that these "never used" features take up most of the bottom half of a properly ordered product backlog.
Have you every found yourself in a situation similar to Mary's? If so, what should you do? Stay tuned for 4 things you can do to avoid the Agile death march!
