This is the final article of this series, and I'm posting it now on Scrum.org because... I forgot to do it earlier. Anyway, here's the Fourth and Final thing you do to prevent value delivery. I'm assuming you've read and (hopefully already corrected) the First, Second and Third Things. I found these things during my years of working in the (attempted) change industry.
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
I was once called into an organization because a team had a sudden, catastrophic drop in ‘Velocity’, a container term used in Scrum to indicate how much work a Team can finish within a Sprint. Apparently, initial communications to the team resulted in them claiming there was no issue. Their manager, not wanting to engage in conflict, asked me to have a look.
What had happened was simply that the team switched their estimation tools. Before, they, like the other teams there, used Story Points to estimate the effort of different backlog items. In a recent retro, the Developers argued that they were pretty good in conversing about the complexity of items, and the ‘pointing’ was distracting. So, as an experiment they switched to throughput measures. So, their Velocity switched from a point measure (36 per Sprint) to a simple item count (7 per Sprint). Perfectly correct, and actually something I applauded them for.
Yet when I communicated this back to the manager, they complained that if teams could define Velocity however they’d like, it would be very hard to measure the amount of value delivered by all the teams. Confused, I told them that Velocity says nothing about value, and asked them what else they were measuring. Something like costs, profits, ROI-per-Sprint, perhaps customer happiness?
Their answer?
’We heard something about customers and costs. Once.’
Elaboration
As it turned out, when they started using Scrum they had tried to engage frequently on intended outcomes and value measures. They had multiple trainings and coaches come over to help, both for the teams, the leadership, and their stakeholders. But learning new ways of working takes time, and money and success were at stake.
When time started becoming an issue, stakeholders took a renewed interest in the product backlog, especially where it involved features that were promised or sold to customers. Questions were asked on why value needed to be measured more frequently, and in more detail, if customers in the past were already happy and coming back for more business. Especially when everyone is already behind on delivery.
The teams, after some time, gave up trying to debate it. All the stakeholders cared about was how much was being delivered. Which was measured (and sold) in terms of Story Points. Ultimately, all the transformation had achieved was a lot of teams delivering as they always had, except in Sprints. Deviating from the routine, like what the team in example did, was immediate cause for concern.
This entire scenario is all too common, and, unfortunately, perfectly predictable.
Explanation (Why this is wrong)
While we would all like to think we’re mostly rational beings with free will, the reality is far more complex. Starting with the work of Kahneman and Tversky, much research has been done in what determines the decisions and behavior of people. These varied insights have led to our understanding that humans are ‘boundedly rational’, that is that our rationality (the thinking part of us) is limited by all sorts of evolutionary and environmental limits.
Why is this the case? Well, simply put it’s because thinking is expensive. So your brain is optimized to not think wherever possible. Let’s look at this in a bit more detail. In their book Thinking, Fast and Slow, Kahneman and Tversky introduced the concepts of System 1 (Fast) and System 2 (Slow) thinking.
- System 1 is our unconscious system. It’s automatic, stereotypic and emotional. It’s also low energy.
- System 2 is our conscious system. It’s logical, calculating and deliberate. It’s also high energy.
We are optimized to use System 1 as much as possible. It’s the System you also use the most during the day. More than 90% of your time is spent in System 1. It likes routine and heuristics. It’s why we have all these cognitive [biases] and [fallacies]. System 2 is called by System 1 when it encounters very new things or unexpected outcomes. This has an evolutionary benefit. The human brain is already one of the most energy-intensive organs, so keeping it in a low power state as much as possible helps when a steady supply of food isn’t a guarantee. Deliberately engaging System 2 is therefore hard for us, which is why we can’t keep it up endlessly. And yet, our society has developed to a point where many of us (certainly those reading this) use System 2 for their work. And even when engaged, System 2 is eager to throw things back to System 1 as soon as possible. People are ever, unconsciously, looking for what I like to call the ‘Path of Least Cognitive Resistance’.
So, what does this mean for transformative work? When trying to change the way people work and the culture they’re in, we are ultimately trying to introduce new behavior. Which means new heuristics. In other words, we are trying to ‘rewrite’ System 1’s ‘If This Then That’ database to some extent. This can be done, to some extent. Much of it the behavior of people though has less to do with themselves and more the environmental context they are in. We optimize for the environment that we are in. So, if we want to introduce new behavior, this behavior should be what correlates to the Path of Least Cognitive Resistance. In other words, it should result in the least amount of calls to System 2 possible. Especially considering most people’s jobs require them to call System 2 far more often than intended.
And yet, this is almost directly opposite to how most transformations are ran. Commonly, they involve teaching, coaching, rewards, inspiration sessions, interventions, challenges, and so on. ’Stop and think about it’ is heard often in some form, which is as ridiculous as it is unfair. Increasing the cognitive load on people already under cognitive load means increasing stress. Add to that that their environment often remains the same. Stakeholders may for instance still ask for planned vs actual reports. This means discrepancies in the behavior and outcomes, which results in stress.
Increases in stress means System 1 is less likely to call System 2, which means people fall back to known heuristics. Or more simply, they continue to do what they always did, and use their rationality to justify this. Often under the veneer of ‘pragmatism’ or ‘the unique nature of the organization’. Which is perfectly understandable.
Solution
So what then? How can we transform the way an organization behaves? Whether that be one person, a company or a society, the answer is the same: Use the Path of Least Cognitive Resistance.
For individuals, we’ve seen this principle applied in Stephen Guise’s Mini Habits work. Mini Habits work by putting the bar for a habit so low that it takes no ‘willpower’ (overriding System 1 with System 2) to perform a habit, and that it’s actually more cognitively expensive to excuse not doing it.
On a bigger scale, Richard Thaler and Cass Sunstein’s Nudge Theory offers a framework to influence people’s behavior through analyzing the environment they are in and introducing subtle changes (nudges) to alter the Path of Least Cognitive Resistance. Any decent UX Designer will have a library of nudges they call on when designing a product, to guide the user to the intended outcome.
Concretely though, if you want better outcomes for your transformation, stop making it a ‘Big Thing’ that requires much effort and thinking. Rather, be invisible. Define the behavior that you are looking for, and then continuously strive to make it as easy as possible for people to show that behavior. Rather than ask ‘How do I get them to act different’, ask ‘Why is acting like this the easiest?’. Because, in the end, we’re not the rational, free-willed individuals we’d like to think we are. We’re buggy flesh robots with a thin veneer of rationality. Have some understanding, and mercy.
I get the irony of demanding you to activate your System 2. I feel justified though, because if you’re reading this, transformational work is probably already what you do.
In short, my advice is this: Stop bothering people, just make things easier.
Sources
- Daniel Kahneman, Amos Tversky - Thinking, Fast and Slow
- Richard Thaler, Cass Sunstein - Nudge
- Jonah Berger - The Catalyst
- Stephen Guise - Mini Habits
- Sam Harris - Free Will
- Cal Newport - Deep Work