Background
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 organizations.
For background, I’m often called into organizations to investigate their ability to deliver. Such a study is holistic; it involves looking at the organizational 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:
- Something went wrong, and the organization wishes to know what happened where and when.
- Work (or sometimes even a transformation) is ongoing, and the organization wants a second opinion on risk or improvement factors.
- The organization expects an inquiry or audit into its delivery capability and wishes to be prepared.
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 organization. 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 behavior 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.
Example
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. 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 an 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!’
Elaboration
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 organizations. These release moments tend to take place 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 organizations plan these weekends and evenings, using overtime, specialized 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?
Explanation (Why this is wrong)
It was quite sometime later 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 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:
- We must do something.
- This is something.
- Therefore, we must do this.
Note that the ‘we’ doesn’t have to refer to the people having the problem or causing the problem. ‘We’ tends to be the people that see the problem and feel some form of ownership, be that a professional one or a political one. They will then also be the ones to propose solutions and execute them within their own ability.
Thus committing the Second Thing to prevent value delivery: Problem theft.
And with that preventing any real solution to the issue.
A Deeper Dive
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 it’s happened already. And as always, keep your eye on the problem itself, not the people involved. In almost every case I’ve seen, this issue (or anti-pattern) comes from a genuinely good place. People really want to help. And it’s hard not to help someone if you feel you can. So let’s take a more in-depth look at why, sometimes, not getting involved is the best thing you can do.
Problems are removed from the domain in which they can be solved
Here’s an example: A prevalent issue faced by organizations 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. I 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-organize, 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 siloed and dependent. But the problem is managed now. The issue with this is the nature of this problem is both organizational (teams are siloed) 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 something like Big Room planning, you’ve moved the issue into the process domain. It cannot be solved there, because that is not its nature.
The ability to deliver (quality) is impacted
No problem starts out big. This is so common in fact; it has lead to many quotes and stories of both an entertaining and horrifying nature. One such term I’ve come to learn is that of the ‘incident pit,’ finding its 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.
- The organization has done its Big Room planning, and work is underway. The market hasn’t slowed down, so new insights emerge over time, but the multi-month cadence resulting from the teams’ interconnectedness means that their course can only be minutely adjusted. Too much of a change, and they’d have to plan all over again. Everyone knows that would be expensive and exhausting, so they try to justify not too.
- At the same time, new technical issues emerge. These need to be fixed, but expediently enough so that the overall planning isn’t threatened. While good planning allows for some leeway, there is always pressure from both stakeholders and other teams.
- These things start piling up, because by managing the problem through process, more process must be added to manage further outbreaks of related symptoms.
- Decisions are being made on what to fix and what not. Quality ceases to be a standard but is discussed as an aspiration.
- Changes are made to the planning, but up to a certain scope it is decided this can be done by team representatives. A Gantt chart is considered to help coordinate it.
- Team members feel disenfranchised and leave, new people are brought in, but there isn’t enough time to fully onboard them, so you just tell them what to do.
Flow is gone. You’re suffocating in process now, as it blindly trashes about, trying to contain the many additional issues it keeps spawning. All promises of faster delivery of value and higher quality are forgotten as people try to figure out an ever-expanding set of ad-hoc fixes to problems they don’t understand, because there isn’t time. Hopefully, someone pulls the plug before you reach the bottom.
All because people wanted to help, by offering a ‘solution’ to a problem that wasn’t theirs to solve. I know, because I was this person.
While the scenario above might be a tad worse than most organizations experience, it is undeniable that unresolved issues will impact your ability to deliver, and the quality of what you deliver.
It results in a culture of passivity and frustration
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 right solution available, even if it takes a bit more work or requires expertise you don’t yourself have?
And yet, I’m sure that within your organization there tons and tons of these. Because I’ve seen them. And I’ve seen the molding wet towels of Release Weekends, Big Room Plannings, Retrospective reports, Jira and the vast amount policies, structures, habits, and technologies that cover up solvable issues every day. And the frustration people express when they talk about organizations they’ve left, and the disconnection they show talking about the organizations they’ve stayed at. It’s helicopter parenting as an organizational strategy.
The Solution
Next time, before jumping into action, take a moment to ask yourself a simple question. ‘Is this my problem to solve?’
Because you need to stop stealing people’s problems.
Sources & Inspiration
My own history of costly mistakes
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
Waking Up - Sam Harris