Dysfunction #3: Lack of Autonomy and Empowerment
In this series, I am going to reflect on what I have learned about Scrum and its large-scale adoption in a non-IT environment through my own revelations and indeed, failures, while working at a large UK-based company, rolling out its own flavour of Agile Transformation. Capital “A” and capital “T” intended.
Originally published at https://www.linkedin.com in November 2020.
When Scrum is being adopted in an environment with the purpose of developing a product, it is not only the teams that will have to start thinking differently about work — the environment will also have to change to support Scrum, because this framework “grows” best when sown on the soil of autonomy. In my interpretation (just to be on the same side), autonomy means self-governance and freedom from external control, whilst empowerment to me means authority to make decisions and bear the burden of those decisions. In an environment where both autonomy and empowerment thrive, constraints (sprint and event duration, for example) offered by framework are supposed to be liberating.
The New New Product Development Game
In product development, there are a few questions one needs to answer:
- Why?: Why do we need to do this? What needs are we serving? Who will benefit?
- What?: What is it exactly that we need to do?
- How?: How are we going to do it?
In more traditional environments, the “why” is usually tackled by the business and product departments. They, in partnership with engineering, define the “what” and then engineering will figure out the “how”. What remains in the hand of the team, the people actually performing the work? An imperative command: “do this” — and the response to these “requests” will have to be “yes” — compliance without any involvement, engagement or empowerment.
When Scrum is adopted, the dynamic described above has to change completely. In theory, the Product Owner should radiate a vision that will help the team understand “why” something needs to be done and “who will benefit” when the problem is solved. Then, driven by inspiration, the team will collaborate with the PO to figure out the “what” exactly needs to be built: during this cooperation, the vision is translated to epics, stories and tasks in the backlog. Finally, the team decides on “how” members will do the work:
Use Your Illusion
When you compare the two pictures I have drawn, you will see why traditional management and leadership might have adverse feelings to Scrum: when done right, it looks like an uncomfortable power grab from their perspective, and it is — the framework challenges the status quo of the “we have always done it that way” mentality as it hands decision-making powers back to where they belong in the space of knowledge work: the people who actually do the work.
In order to counter the situation described above, management will be compelled to offer the illusion of autonomy and empowerment, but whilst boasting about it with conviction at company all-hands and make-me-look-good video clips designed for employees, they might cascade down KPIs, metrics or downright product specifications and implementation details that will actually limit creative freedom and experimentation. Instead of inspiring people with a problem the company wants to solve, team members are resorted to execute pre-defined solutions which might just result in sub-optimal products.
In addition to management, team members might also feel challenged by Scrum. In transitioning organisations, people have gotten used to being told what to do (and how) for such a long time that they might be oblivious or intimidated by the brave space offered by the framework. Instead of wanting to experiment and find out what might lead to better solutions, they will focus on their own metrics and just achieve them using tried and tested means, methods and tools. In this race, there is no time let alone desire or energy and headspace to think up novel ways — acting upon feedback and iterative learning is simply not a part of the process. People will always feel more answerable to their managers than their team members or their product owner — again, something that the spirit of Scrum challenges.
And what do you think might happen when teams want to influence decision-making of management with an improvement idea using actual data? They will, of course, hastily prepare a ppt (you can’t explain anything to execs without a strong deck) and on the big day they have ten minutes to present. In most cases the budding feeling of empowerment, however, is shredded to pieces and compliance is being encouraged when their data-driven suggestions based on actual feedback from flesh-and-bone customers are wiped off the table without giving an inch of consideration. A lesson is learnt: employees are not hired to question management’s decisions. One side of the scale has numbers, data and feedback and the other holds the opinions of management. Guess which will win.
And what happens when, due to working in cross-functional teams, people finish stuff sooner and now they want to release? Well, you guessed it right: the PO will not be invited to the table to have their final say on what and when needs to be shipped. Instead, management will inspect the end-product and will give it the green lights. Where is the power and responsibility that comes with creative freedom, one might wonder. How could a well-meaning Product Owner be held responsible and accountable for the product vision when most product decisions have been made upfront.
But hey, I’m not blaming management — if I was in their shoes, I would probably do the same due to the fundamentally flawed system of motivation applied in our corporations. The reason why, in my view, it is nearly impossible for our leaders to advance the empowerment and autonomy of employees is the Taylorist™ rewards structure.
It is not the salary our management is after: their focus is the bonus, and they will get it if they can please the markets and shareholders quarter by quarter, YoY. And here lies the problem: we know from Dan Pink and Sam Gluckberg’s candle problem that a large reward actually limits creativity and instills aversion to risks. So therefore, how will a leader who’s focusing on that massive stock option or cash reward empower employees to take a chance and pursue risky ideas? And how likely is it that people on the floor will want to play around with new ideas when they know that if they just “get on with it”, they will be rewarded well at the end of the year?
In our scheme, we do not ask the initiative of our men. We do not want any initiative. All we want of them is to obey the orders we give them, do what we say, and do it quick. — Frederick Taylor
When management maintains firm control over ‘what’ they want teams to deliver and can accept or reject ‘how’ they do it, we are just lulling ourselves into believing that we are part of this creative endeavour where figuring out as we go in an iterative and incremental manner, the fundamental tenets of agile, is possible. What Scrum needs to thrive is autonomy — for people at the coalface to make decisions and take their fate into their own hands. And what autonomy needs to breed is trust from management and the release of control. All of this, with the illusion of Scrum, needs to be challenged and exposed, because if things go wrong, people might want to find a scapegoat. And then…
Who gets to blame? Scrum gets to blame…
Originally published at https://www.linkedin.com.
