Last week (December 12-13, 2019), I took part in a Professional Scrum Master (PSM) II training course hosted by Christiaan Verweijs and Barry Overeem, a.k.a. The Liberators. I consider thorough knowledge of all roles in the Scrum framework to be beneficial to my work as a Product Management Consultant. Additionally, I wanted to learn more about Liberating Structures, a technique for inclusive and collaborative dialogues that I have casually used over the past year or so. With these objectives in mind, I headed off to the training – only to encounter the following (almost Master Yoda-like) sentence at the start of the very first day:
“For Complex Work, There Are No Experts”
I keep coming back to this sentence for various reasons I feel are worth exploring in further detail below.
What does it mean?
1. It captures the importance of transparency, inspection, and adaption.
Scrum implements ’empiricism’, which Gunther Verheyen defines as “a process control type in which decisions are based on observation, experience and experimentation.” (Verheyen 2019, 106) The three pillars of empiricism are transparency, inspection, and adaptation. That’s of course very interesting, but why is it important?
Doing complex work involves many unknowns that imply risks (e.g. requirements, skill sets, team dynamics, technological developments, integration issues, legacy technologies, market developments, regulations, etc.). As a result, the steps and exact outcome of complex work cannot be predicted exactly beforehand, yet some way of addressing these risks is also necessary.
Scrum replaces inside-out and project-driven approaches that fix scope, time, and budget with outside-in and product-driven ways of working. These ways of working make use of empiricism to enable some degree of control over complexity and risks arising from it. Through inspection of the work done, knowing how and when to adapt on the basis of lessons learned becomes possible – provided there’s transparency of complex work and how this work is done.
Rather than depending on a single ultimate arbiter or expert who can call the shots, Scrum implements a process that features frequent checks and possibilities for intervention. This is done to assure the best possible decisions are taken given the information available at a particular point in time.
2. It suggests that the best time to start working on complex issues is right now.
If making exact predictions of unknowns and their risky implications isn’t possible, the best way to tackle complex work is to simply just start. Right now.
The exception here is complex work that is likely enough to involve risks that have a high impact. In such cases, it’s better to think twice before starting. In other cases, it’s best to just start. There’s no expert that can make an exact prediction of the outcome, but starting the work will at the very least deliver information about whether or not to continue, or yield knowledge on how to best proceed.
Especially in software development, many issues become clear only after some work has been done (i.e. some code has been written). Making a highly detailed masterplan beforehand is extremely wasteful and doesn’t make sense from a business perspective. That one part of the codebase that no one dared to touch turns out to be a serious impediment anyway, or clients realize they need a particular functionality sooner than expected after working with a first prototype of the software they ordered.
In Scrum, complex work take place in a controlled environment, making failure an option. Failure can be extremely valuable, for example when it leads to the decision to discontinue work that would otherwise eat up precious time and resources. Apparently, there’s no need for experts in this particular case of complex work, so let’s focus on something else. I would call that a great success.
3. It leverages high-impact collaborative forms of tackling complexity
If none of us are experts since noone can make an exact prediction, we can and should find out together.
In engaging the complex task at hand, Scrum ensures knowledge is pooled. Perspectives are exchanged, disagreements become explicit, and well-established patterns of thinking and ways of working are challenged. This can be highly disruptive in the best sense of the word.
Liberating structures really shine when it comes to collaborative work and exchanging points of view. The solo endeavor of the individual speaker giving a presentation is a form of centralized control in exchanging knowledge. Liberating structures, by providing an opportunity for everyone to speak and subsequently allowing groups to establish a shared point of view, are a form of distributed control that attempts to involve everyone.
In this context, admitting to not know is ultimately empowering: you’re not an expert, but neither am I. Let’s find out more together!
Caveats
Hierarchies are real and even necessary
In some cases, experts are identified due to the fact that they have the expertise to make the calls, or perhaps because their position attributes high responsibility to them. This is not always wrong. It might make perfect sense for someone to be the final authority when it comes to addressing complex work.
Take for example the Product Owner, the person in the Scrum framework responsible for maximizing value. Having multiple Product Owners or a committee of Product Owners can be highly disadvantageous, since it creates more handovers and stage gates that impede the realization and timely delivery of valuable work. Of course the Product Owner can consult multiple people, but he/she remains the ultimate authority when it comes to maximizing value. I’m a strong proponent of this more independent and sometimes even entrepreneurial stance of the Product Owner. The trick is to balance inclusive decision-making with high-impact delivery. Nobody ever said the Product Owner’s job was easy!
In addition, team dynamics and hierarchies are real too, so not everyone might have a say, the potential of liberating structures notwithstanding. Impeccable facilitation and moderation are essential, but can be hard to find in organizations doing Scrum.
Transparency hurts, sometimes (actually most of the time)
Organizations may be committed to a particular way of working, or may suffer from the fallacy of sunk costs that makes them think that high investments in the past are a good reason to continue investing in something.
Disrupting status quo frustrates vested interests. Organizations most often feature difficult to navigate cultures that function as immune systems that fend off what’s perceived as undesirable, such as the chagrin emerging from increased transparency.
Zombie Scrum
The maturity of Scrum is dependent on how well organizations deal with hierarchies (ranging from ‘chain of command’ to a proactive and horizontally organized staff) and transparency (ranging from highly political trench warfare to an innovation culture that embraces failure as a chance to grow). Scrum is deceivable easy to understand, but difficult to master in practice. Doing Scrum and doing Scrum well are two different things.
Given the heritage of the industrial paradigm, the journey towards more productive ways of tackling complex work is challenging, to say the very least. Suboptimal implementations of Scrum, a.k.a. Zombie Scrum, shouldn’t be confused with the real thing, but I fully understand the disappointment about Scrum that’s felt in many organizations.
References
Verheyen, Gunther. 2019. Scrum: A Smart Travel Companion. Den Bosch: Van Haren Publishing.
