Escape from Agile Hell (part 2)

The road to Agile Hell is paved with good intentions, and limited insight. An overall theme of my writings is to emphasise the fundamental role of continuous improvement (along with sense-making and collaboration) as a key foundation of successful work practice in the modern era.

But time for continuous improvement is a precious and fragile commodity that all too often gets squeezed out, and such squeezing out leads inevitably to working harder, not smarter.

Agile Hell is where you wind up when you implement some of the Agile productivity practices while omitting the equally important sustainability practices. Why would anyone do that? Two major reasons are naïveté, and moral hazard.

Naïveté: The deeper practices (and many of the principles and values) are quite sophisticated and can be counter-intuitive. Thus the tendency to pick and choose. Even if you take them all on faith, if you don’t understand them chances are they’ll get mis-applied.

Moral hazard comes into play when someone else pays for the down-side consequences of your decisions: a classic business scenario is when the sales person sets a project delivery date without consulting engineering. The sales person is remunerated on closing the deal, so cuts a fine delivery date for which engineering now has to answer to. The sales person gets rewarded for closing the deal, not for delivering the work. [Note that the sales person isn’t the villain here: the real culprit is whoever set up the rewards system, or copied it from standard practice.]

An example that combines both factors: In traditional (command-and-control) workplaces it can be unheard of to say “no” to work requests. Most Agile approaches radically change this arrangement by mandating that stakeholders collectively prioritise their work as a single, ordered backlog, for the work team(s) to “pull in” according to their capacity to deliver. Following the Lean-Agile way, the most important stuff gets done first. Teams get to concentrate on quality, and have time to continuously improve (which will lift productivity, gradually). It also sends a healthy signal back to stakeholders to not just ask for everything, but to start applying the Pareto Principal (also known as the 80:20 rule), and to slice their work requests fine — which helps with the flow of work.

A fast route to Agile Hell is for the (powerful) stakeholders to “push” the work they “need” beyond the current capacity of the team(s). The backlog still exists — so there is superficial use of Agile practice — but the reality of finite team capacity is ignored. To oblige the stakeholders the teams typically work overtime and/or sacrifice quality. Invariably time for continuous improvement gets squeezed out. All of these actions favour the short-term over the long-term. It may feel like a win for the stakeholders, and it may be for certain individuals, but it’s a net loss: for teams, for quality, for organisational culture, for improvement, and for long-term success.

The developmental step to fix this kind of problem is the equilibration of power relationships for the common good. This means powerful people need to give up some command and control, and for less powerful people to step up and take more responsibility and ownership. Both of these changes are significant, and more than a process change: they realign relationships and self-image. They are supported by process, but are deeper than that. They typically cannot and do not occur instantaneously.

The opportunity of Agile Hell

Here comes the silver lining. Agile Hell offers an opportunity to learn “the hard way”. It is the result of having acted on good intentions — introducing Agile ways of working — and then landing in a heap.

If some key people prove wise enough to not blame Agile itself (which would be a case of shooting the messenger) there is an opportunity to learn from mistakes. To do this involves reflecting and understanding on what went right and what went wrong, and what’s needed to do better going forward.

I have found the following sense-making exercises very valuable in this kind of breakthough-seeking:

For program and project rescue I’ve got a lot of mileage out of future-spective formats such as Dave Snowden’s The Future, Backwards (which I simplify a bit), and the Solution Focus technique of asking a Miracle Question of imagining a jump forward to a successful point-of-completion. Both techniques invite the use of imagination and perspective-taking to expand perspectives and generate critical fuel for insight, while not getting bogged down in the tarpit of the current difficulties.

In The Future, Backwards as well as imagining a jump forward to success (the best possible outcome / future heaven) we also imagining jumping forward to failure (the worst possible outcome future hell). Working backwards from future heaven we explore what positive steps were taken that led to such a great result. This encourages a critical examination of how various work practices lead to long-term success. By contrast, working backwards from future hell we ask what we can do to stop the apocalypse from eventuating. Bad short-term practices that lead to poor quality and morale get jumped on quickly using this technique, which can also be very cathartic.

A final helpful dimension of this exercise is to run The Future, Backwards separately among distinct groups: e.g. workers, operators, managers, and stakeholders. This not only increases safety among these groups, encouraging frank sharing, it allows for a follow-up showing each group what the other groups came up with, and discussing similarities and differences. The value of different perspectives is brought out, uncovering blind-spots, an antidote to moral hazard.

To address self-sabotaging behaviour, e.g. among managers who are hitting the wall in their careers and leadership groups who are getting stuck in a rut, I especially like Kegan and Lahey’s Immunity to Change approach. The thinking here is that we often know what to do to effect positive change, but are held back by outdated assumptions that served us well in the past, but have begun to outlive their usefulness. [These unconscious or dimly-understood assumptions constitute an immune system that defends against change — a metaphor drawn from how the body’s immune system defends against disease.]

For example, the widespread habit of never saying “no” to requests (which leads straight to burnout and undermines smart prioritisation), may be rooted in assumptions that saying “no” will mean being disliked and rejected. Immunity to change helps people and teams to systematically uncover and question these sorts of assumptions and replace them over time with more adaptive alternatives.


As Albert Einstein famously declared, “No problem can be solved from the same level of consciousness that created it“. If we find ourselves in Agile Hell we have been operating at an insufficient level, and the fix will involve not only re-instating the Agile sustainability practices (described in part 1), but also breaking through outdated assumptions, through deeper learning and perspective-taking.

* * *

Got questions or comments? Sign up for the Prager’s Law LinkedIn Group

Copyright © 2019 Daniel Prager. All rights reserved.