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 called into an organisation to perform a study. A new product had been developed to replace an older, third party solution that was no longer tenable. The launch was less than satisfactory. The UI was a mess, many features were only partially done or completely absent and the product was so unstable that it was down more than up. The organisation had to revert back to the old third party solution at great cost, after several (costly) years of development. In my research, I found many issues throughout the development process, but one stuck out in particular. In Scrum, product accountabilities are clear: The Product Owner is accountable for the business of the product (strategy, releasing, profit & loss, etc.) and the Development Team is accountable for the quality of the product (releasability, maintainability, stability, documentation, architecture, etc.). While the organisation claimed to have used Scrum, these accountabilities were not secured in this way. I spent many interviews trying to find out who was accountable for things. Product Management would point to Development Teams, Development Teams would point to Architects, Architects would point to Project Managers, back to Product Management, and so on. Every time I would get the same answer:
‘That’s on us? I thought that was on them.’
Before we dive into an explanation of how these things happen and how they can be avoided, it’s worthwhile to look at the history of this company. Because there wasn’t much special about it. In all honesty, there are not that many special companies. This company, like many others that reach a certain size, had been set up bureaucratically, and was in the initial stages of moving past that paradigm into one more suited for creative knowledge work. So let’s look at what that word actually means. What is bureaucracy?
First off, it’s important to note that bureaucracy isn’t bad. It is certainly better than the system it replaced, various forms of despotism. In many ways, it is a vital part of modern civilisation. As with most things, it takes people to turn it into something bad. It is for this reason, and one other that I’ll explain later, that most people I’ve worked with over the years (and yes, that is an anecdotal observation) tend to dislike the system.
German sociologist Max Weber, who was the first to formally study bureaucracy, listed the following traits:
But this company was changing.
The field of product development is not a simple one. In this context, complex work is done. This means there are more unknowns than knowns, and you don’t know what you don’t know. There is very little predictability to be had, and virtually no repeatability as you never solve the same problem in the same way twice. Speed is the name of the game here, as the more often you deliver, the more often you can check assumptions and adjust course. The First of Four article explains these things further. For this article, let’s see what this does to the traits of the bureaucratic system, if one is trying to be effective in a complex environment:
Yeah, that’s quite a lot of text. In more simpler terms: While a bureaucratic system works great in a simple and complicated context, it is an extremely inefficient approach to organisational control in a more complex one. So change is needed. And not just operationally. It is a wholly different paradigm for an organisation to move into.
It is said the road to hell is paved with good intentions. This is to some extent what happened here. The organisation, in their switch to a more Agile way of working, had decentralised control and encouraged self organisation. They had let go of many things that used to be clearly defined. And they had realised that as the company was learning to deal with this, it was going to happen with some struggles. They had embraced the value of failure. But there is failure, and there is failure.
What this organisation had done was use something I call the Underpants Gnome approach to transformation, after the South Park episode that popularised the concept. It consists of 4 simple steps:
It was during this study that I was sent an article by Gary Pisano called ‘The Hard Truth About Innovative Cultures’, published in the Harvard Business Review. It’s worth a read. What stood out to me was the very first, somewhat paradoxical statement:
‘Tolerance for Failure but No Tolerance for Incompetence’
And there we had it. While there were other issues at play, this explained the situation I described earlier. The organisation was committed to moving to a new paradigm. They had embraced Agility to run their business, and encouraged Scrum at the team level. But in their eagerness, they had no assured themselves that the people given broader accountabilities were competent enough for those accountabilities. In other words, they went from the bureaucratic system of managed incompetence to unmanaged incompetence, instead of the Agile system of unmanaged competence.
The Scrum Teams barely knew Scrum, they certainly had no formal education. The Development Team had zero experience in maintaining architecture, solid testing and thorough documentation, given that until that point they had just been coding requirements. Leadership didn’t know what they ought to be doing, just many things they felt they shouldn’t be doing anymore. What they did do, was tolerate incompetence, including their own.
It is extremely important for any organisation that deals in creative knowledge work to have a high degree of tolerance for failure. It is equally important to not tolerate incompetence. This doesn’t mean getting rid of everyone that is ‘incompetent’. What is means is assuring that people receive the education, support and experience to be competent for the accountabilities they have. Guiding them until they no longer need guidance. Because this assures and increases the quality of failure.
Stop tolerating incompetence.
Wikipedia - Bureaucracy Gary Pisano - The Hard Truth About Innovative Cultures