The Theory of the Dead Horse in Scrum
There is a delicate balance between agility and commitment to reaching goals.
Commitment can lead to rigidity when the commitment is set to ‘the plan’ or ‘the destination’, instead of ‘the goal’. Alternatively, one may manoeuvre flexibly past various destinations, without ever achieving (or even setting) goals. One might, with dedication and commitment, try out ever new ways without getting anywhere.
The Fallacy of ‘Pretentiously Succeeding’
In business, when we experiencing difficulty or failure, we tend to attribute it to our efforts, commitment, methods and resources. But likewise, when our methods and resources appear to be failing us, we get told we are not doing it right or are not trying hard enough.
The Tribal wisdom of the Indians, passed on from generation to generation, says that, “When you discover that you are riding a dead horse, the best strategy is to dismount. — The Theory of the Dead Horse
Our ability to decide the best way forward depends on our ability to determine if the horse is in fact dead. Inspect and adapt.
But that ability, in business, isn’t always appreciated or well-received. In many organizations, one would require a great deal of courage to merely suggest that “the horse might be dead”. ‘Dead-claimers’ might be told, “Don’t come with problems, come with solutions". They’ll be considered pessimists and perceived as uncommitted.
We tend to be biased and look for evidence something works, not how it isn’t. We partake in a ‘success theatre’. The sunk-cost fallacy also plays a role here: the unwillingness to fold when one is invested.
We are also biased in the way that, when we seek to validate hypotheses, we often fail to treat invalidated hypotheses as a success.
It’s not the horse… it’s you!
When we are told to ‘take my horse to the Old Town road’, yet learn the horse ain't movin’… management might look to:
- Buy a stronger whip.
- Change the rider.
- Appointing a committee to study the horse.
- Arranging to visit other countries to see how other cultures ride dead horses.
- Lowering the standards so that the dead horses can be included.
- Re-classifying the dead horse as living-impaired.
- Hiring outside contractors to ride the dead horse.
- Providing additional funding and/or training to increase the dead horse’s performance.
- Doing a productivity study to see if lighter riders would improve the dead horse’s performance.
- Declaring that the dead horse does not have to be fed, it is less costly, carries lower overhead and, therefore, contributes substantially more to the bottom line of the economy than do some other horses.
- Rewriting the expected performance requirements for all horses.
And my favourite:
- Promoting the dead horse to a supervisory position.
Dead Horses in Scrum
One might argue that Scrum prevents horses from dying in the first place as Scrum Teams frequently inspect the health of the horse… But don’t be fooled, this fallacy manifests itself comfortably in the Scrum and the Agile domain too.
- The Development Team needs to be more cross-functional so it has all the competencies to ride dead horses.
- Harness several dead horses together to increase velocity.
- Introduce ‘pair-horseriding’: Assign riders in pairs to dead horses.
- Remove Technical Debt to reduce the total cost of owning dead horses.
- Tell the Scrum Master to fix the dead horse, after all, the Scrum Master is responsible for resolving impediments, right?
- Blame the Development Team for underestimating their ability to ride dead horses.
- Blame the Development Team for not having the skills, creativity and commitment to ride dead horses.
- Bring in the Product Owner to re-emphasise the Vision of reaching ‘Old Town road’ to motivate the Development Team to try riding the dead horse again.
- When the Development Team suggests to dismount the dead horse, re-emphasise the meaning of the Scrum Value ‘commitment’ to them.
- Instruct the team that they are ‘self-organizing’ and ‘agile’. They are responsible for figuring out a way to ride the dead horse to Old Town.
- If an inspector determines that one or more horses deviate outside acceptable limits, and as a result, the horse will be unacceptable to get to Old Town, the horse must be adjusted. An adjustment must be made to the horse as soon as possible to minimize further deviation.
Calling Out Dead Horses
This reminds me of the children’s story ‘The Emperor’s New Clothes” where the little boy, during the parade, shouted out:
“But he isn’t wearing anything at all!”
The Emperor’s New Clothes exists everywhere in business as ‘pretentiously succeeding’ is the norm.
In these examples, it’s simple to establish a ‘dead horse’ or a ‘naked emperor’. However, in business, it is often not all that obvious. All in all, one should be reserved in ‘calling out dead horses’ and ‘naked emperors’. There might be repercussions. But, one also shouldn’t jump the gun and call a horse ‘dead’, leave it behind, simply because it wasn’t moving and merely resting.
“it’s not dead it’s just resting!”
Scrum has mechanics for detecting and calling out Dead Horses. Developing Transparency helps teams see and understand things as they actually are. Teams develop situational awareness, a shared understanding and radical candor. Inspections help teams establish that their case is indeed the equivalent of a Dead Horse and that the horse is not just sleeping. Through adaptation, they are able to dismount and move on.
The Scrum Values exist to help teams dismount timely. The Scrum Team members have the courage to do the right thing: call out it’s dead and dismount. The Scrum Team and its stakeholders agreed to be open about the challenges: they define the horse by its state: ‘dead’. The team respects one another so they won’t blame each other for the death of the horse. In retrospect, they will learn, assess the root cause and adapt.
Often teams don’t consider cancelling the Sprint as a valid adaptation. If indeed the Product Owner agrees that, as the whole point of the journey was to sell that horse to the stakeholders, without the horse, there is no point in going to Old Town. The Product Owner agrees the stakeholders will not value a dead horse either. The Product Owner thus cancels the journey and informs the stakeholders.
As Good as Dead
In any case, the Theory of the Dead Horse in context to Scrum is really about empowering the team. The riders, in the analogy, who are being forced to ride the dead horse no matter what will be only as effective as the dead horse.
So is your team currently trying to ride any dead horses and either unable or refusing to dismount? Is ‘X’ technique, feature or method alive or dead? Why not run a ‘Dead Horse Retro’? Yeah, I just made that up, but here is a helpful canvas. I hope this story and canvas will help your team master the art of knowing when to dismount.
We need to inspect the usefulness of our interventions/experiments and abandon/change them if we find out they are local optimisations or not, at a systemic level. We have to learn how to minimize the time between learning and adaption (the time between the horse’s death and the dismount).
This requires transparency.
“Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.”
So that observers share a common understanding of ‘Dead’ timely and not wind up in a variant of the Dead Parrot sketch, Naked Emperor or Dead Horse theory situation.
But moreover, it’s my intention with this article and theory, to provide means to stimulate organisations to facilitate a safe discussion, with a bit of candor and with a bit of humor to break the ice.
I’ll leave you with some final words of wisdom. In Scrum, we are backpackers, not roadmappers. So in business with roads and (dead) horses consider:
If you feel like jumping from Dead Horses to Invisible Cows: