As discussed in my previous post we arrive in Agile Hell when a few Agile practices are adopted, providing an initial productivity bump, without also including the equally important Agile sustainability practices. It’s like you put a bigger engine in your car, but neglected to upgrade the transmission and brakes: you’re going to wear parts out, and may well crash!

Escaping Agile hell starts with putting back the sustainability practices. For project or product work it’s as simple as one, two, three:

1. Monitor and measure your (or your team’s) capacity: How much quality work can you do in a short fixed period (typically one to four weeks)?
2. Plan to do 70% or so of that, to allow room for learning, improvement, and emergencies.
3. Make sure someone (you?) holds up the proverbial s*** umbrella, and is prepared to say “no” to unreasonable requests, and manage the reasonable ones.

The first point grounds our approach in empiricism, or as we say today, “data”. Rather than planning based on wishful thinking, we learn (quickly) from experience. By knowing your capacity based on historical data, you are providing a reasonable and defensible basis for your forecast. For example, if you estimated that you could deliver 10 units of work last week and only delivered 8, it would be unclear how you could reasonably deliver 9 or 10 next week. On the other hand, if you forecast 8 and delivered 9, upping your forecast next week might be ok, although the conservative approach would be to forecast 8 or 8.5. Some people take an average over the last 3 to 6 timeboxes to smooth out statistical outliers.

The second point acknowledges uncertainty and complexity. We can’t predict exactly how long complex work will take to do, and leaving some buffer allows some room for when this unpredictability goes the wrong way. Without this buffer most work systems either sacrifice quality or team well-being. Both are bad options for all concerned in the long run. This is not to say that occasionally you shouldn’t put in overtime (e.g. in an emergency), or intentionally sacrifice quality, e.g. in making a throw-away prototype, but working long hours is unsustainable, and low quality work tends to lead to poor outcomes.

The third point is critical, if you can’t say “no” to unplanned work from powerful stakeholders, your 30% buffer will quickly evaporate. If the buffer over-runs because of legitimate emergencies, replanning is in order. I call this “horse-trading”: you’ll need to not deliver on something previously planned in order to bring in the urgent, unplanned work. Better to plan a little less, and if you finish really early you can always pull something else small in, late in the timebox.

Saying “no” is healthy (up to a point). It forces prioritization. Saying “yes” to everything gives your stakeholders the illusion of infinite capacity. That’s unrealistic and leads to a lot of stress to deliver large amounts of low value work.

Time for improvement

Now, even if you allow time to absorb uncertainty and complexity in your planning, that’s not quite the same as reserving time for improvement. The natural extension is that whenever you complete your planned work early you devote the rest of the timebox to improvement, but in a high pressure environment those early finishes may become rare to non-existent.

In such environments I recommend reserving an hour a day (or so) for learning and improvement. A weekly block of time is another option. My friend and sometime colleague Sarah Taylor calls this practice “Fri-play”. As with learning to play a musical instrument, regular practice is much better than the occasional binge.

An alternative to quarantining time is to treat improvement as another form of work, on a par with delivery, and insert improvement cards into your backlog of work, usually with medium priority.

Continuous flow systems like Kanban have a different approach to creating the necessary slack needed for sustainability and improvement, by enforcing hard work-in-progress limits (which lead to slack generation in response to unbalanced flow) and applying the improvement and coaching katas of Lean. We will discuss these another time.

This is nothing new

It’s not as if workplace hell — where employees work long hours to the detriment of their mental and physical health — is a new phenomenon. Many organisations work their staff (especially juniors) very hard, without paid overtime, exploiting fear and ambition, and harnessing social norms to buttress this approach.

In many of these workplaces this kind of lifestyle is endemic: law firms, many parts of finance, management consulting, medicine, many startups, and computer game development to name just a few. There is some variation by culture and nation: the USA (where extra hard work is sanctified in the protestant work ethic and a price of chasing the American dream) and Japan are notorious, with the Japanese even having a word for death by overwork: karōshi. Mainland Europe is a bit different: I once had a German colleague who explained to me that in Germany if you didn’t complete your work within the statutory 35 hour week, you were assumed to be under-skilled and referred for remedial training.

The crazy part is that this kind of work pattern is detrimental to quality and creativity, as well as individual happiness. It’s likely that working longer for sustained periods especially in knowledge work results in bad decisions and outcomes that generate more re-work.

The Agile sustainability practices (see above) help defuse this problem, but only if they are taken very seriously.

Conclusion

In summary: Agile approaches include sensible mechanisms for avoiding over-work, but are challenging to apply in many work cultures.

The visible tell-tale signs are carry-over work (or deadline slips), over-use of overtime, poor quality, and staff disengagement. As these are recognised as inhibitors to performance, opportunities inevitably arise to fix these problems and restore balance.

By measuring and publicising the capacity of yourself or your team and planning to do a little less, you acknowledge the reality of uncertainty and complexity and providing the necessary stimulus for prioritizing high value work.

If you always say “yes”, you’ll find yourself and your teams burning out on large amounts of low-value work. That’s not good stakeholder management — that’s called being a doormat. It’s much better to work with your stakeholders to slice and prioritize their work, and then your team(s) can pull achieveble amounts of work and deliver great quality with a reasonable degree of predictability.

The alternative is a blame-fest.

* * *

In Escape from Agile Hell (Part 2) — coming up next — I will explore an approach to what to do when all of the above makes perfect sense, but still seems politically unattainable in your current situation.

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

Copyright © 2019 Daniel Prager. All rights reserved.