On November 22nd 2019 I gave the closing keynote at Scrum Deutschland, a talk called ‘The Four Things You Do To Prevent Value Delivery’. In this keynote, I discussed the trends I found during my research at multiple organisations.
For background, I’m often called into organisations to investigate their ability to deliver. Such a study is holistic, it involves looking at the organisational design, technical capabilities, culture and knowledge, and type of control and metrics used to define success. I get these kinds of request usually because of three main reasons:
As expected, repeated studies have allowed me to observe some patterns. Some of these have to do with ‘the system’, the whole of hierarchy, setups, technology and so on that make up an organisation. The impact of the human element in all of this surprised me though. Not because of its presence, but more how it impacted everything. I didn’t find any malicious behaviour at any point. What I found where people trying their best, making an effort to be helpful, and yet this often resulted in issues in the delivery capability. It is these observations that I shared in my (happy to say well received) keynote. And now in these four articles.
Some time ago, I was teaching a Professional Agile Leadership class. It’s an enjoyable class to teach (and attend), and in this case I was teaching it in-house to a management team at a large Dutch corporation. Partway through the first day, there was some consternation. Against my advice, some of the attendees had been checking their emails and it seemed one of their reports was causing a fuss. Much whispering ensued. Anticipating a learning opportunity, I asked to share what was going on, that we might discuss it in the class. It turned out the employee had asked for a long weekend, a Friday plus Monday off. Everyone agreed this employee was being very irresponsible and should know better. Confused, I asked what the problem was. This was the response:
‘Holiday? It’s Release Weekend, all hands on deck!’
This scenario is probably familiar to many of you. It certainly was to me. Bringing the culmination of several weeks, if not months, of changes to multiple systems to production tends to be a massive undertaking for many organisations. These release moments tend to be planned in the evenings and weekends. This is done so as to hit the least amount of customers possible with the inevitable errors and outages. Select personnel is expected to be present to fix issues as they manifest. For this reason, many organisations plan these weekends and evenings, using overtime, specialised crew or a rotation of developers.
For the longest time, this approach to releasing was just ‘one of those things’ to me. It was annoying, sure, but something that could be planned for. And increasing the release frequency by reducing the size of releases made those release moments less impactful. Yet they still required planning and attendance.
But over time, I started wondering. Why did I assume release difficulties as a given? Worse, what did it do to developers, communicating beforehand that their issues would be fixed in post-release crunch time? And why on earth were they not managing this themselves?
And what else was being managed for them?
It was quite some time later the the answer came to me, as I was rapidly approaching what could have been a burn-out. I had been trying to get into meditation to help calm my mind. One of the questions I was teaching myself to ask every time I invested myself into something was ‘Is this my problem to solve?’. I have been trained for years to see issues, ongoing or yet to form, and advise on their resolution. It’s not something I could turn off, and my problem was that I felt ownership of everything I saw. It wasn’t sustainable. Hence the question.
And then I thought back to all those release weekends. And the planning meetings, the dependency mapping, all the tools devised over the years to manage the issues inherent to value delivery in complex systems. And it hit me. Problems were being solved, or to be more correct, managed, but were they solved by the right people?
Looking into things further it seemed once again I, and many others, had fallen victim once again to a fallacy common enough to have a name. In this case, it is something called the ‘Politician’s Syllogism’. It received this name in an episode of the BBC series Yes, Prime Minister. Its form is as follows:
Thus committing the Second Thing to prevent value delivery: Problem theft. And with that preventing any real solution to the issue.
Before I give you the solution to this issue let’s discuss why problem theft is something you will want to guard against, or resolve if its happened already. And as always, keep you eye on the problem itself, not the people involved. In almost every case of this I’ve seen, this issue (or anti pattern) comes from a genuinely good place. People really want to help. And it’s really hard not to help someone if you feel you can. So let’s take a deeper look at why, sometimes, not getting involved is the best thing you can do.
Here’s an example: A very common issue faced by organisations at scale is that of dependencies between teams. This is an unfortunate scar left over from many years of factory-style efficiency being implemented everywhere. We can explain the origins but suffice to say, many teams work within silo’s and so need to coordinate what they work on to deliver value. This is an issue, and therefore We must do something. So, what’s a quick way to deal with this? Why, a Big Room planning session of course! This is something. Get everyone together, have them self-organise and come up with a joint planning. To make sure this doesn’t happen all too often, plan ahead for a few weeks/months. Now the problem is solved, because there is now a way to deal with the issue. Therefore, we must do this. But is the problem solved now? No, not at all. Teams are still silo’d and dependent. But the problem is managed now. The issue with this is the nature of this problem is both organisational (teams are silo’d) and probably technical (teams can’t change the code independently of each other while guaranteeing quality). These are both problems that can be solved. But by introducing Big Room planning, you’ve moved the issue into the process domain. It cannot be solved there, because that is not its nature.
No problem starts out big. This is so common in fact, it has lead to many quotes and stories of both a entertaining and horrifying nature. One such term I’ve come to learn is that of the ‘incident pit’, finding it origins in diving. It states that over time, seemingly small issues may cascade to a point where they can (sometimes literally) drag you down. It is therefore expedient to avoid getting ensnared, or resolve even small things as quickly and professionally as possible. Let us return to the example above and go all the way down the incident pit.
Imagine for a moment, you’re back to living at home with your parents. You could move out if you want to, but so far you’ve not felt the need. You’ve just walked into the bathroom and you notice the floor is a bit wet. It turns out the hose to the washing machine isn’t attached to the water tap correctly, so it’s dribbling water. You yell downstairs that there’s an issue and that you’re going to fix it. But as you prepare to close the tap to attach the hose correctly, one of your parents tells you not to bother and just put a towel down. You protest, clearly your solution is the right one. But to no avail. At the start of every day since, there’s a wet towel on the bathroom floor that needs replacing. It’s starting to get smelly. Depending on the type of person that you are, you will either ‘deal with it’ or start planning on moving out. Because you are forbidden to fix the water issue, even though you know you can. It’s a ridiculous example right? Who in their right mind wouldn’t allow an issue to be solved if there’s a good solution available, even if it takes a bit more work or requires an expertise you don’t yourself have? And yet, I’m sure that within your organisation there a tons and tons of these. Because I’ve seen them. And I’ve seen the moulding wet towels of Release Weekends, Big Room Plannings, Retrospective reports, Jira and tons and tons of policies, structures, habits and technologies that cover up solvable issues every day. And the frustration people express when they talk about organisations they’ve left, and the disconnection they show talking about the organisations they’ve stayed at. It’s helicopter parenting as an organisational strategy.
Next time, before jumping into action, take a moment to ask yourself a simple question. ‘Is this my problem to solve?’ And please stop stealing people’s problems.
The Incident Pit and Politician’s Syllogism are explained over at Wikipedia. In Praise of Wasting Time - Alan Lightman The Psychology of Computer Programming - Gerald Weinberg And my own history of costly mistakes.