Organisational agility: Give people a VOICE
“You are special, you are a beautiful and unique snowflake”
You are, your team is and so are the complex adaptive systems that you are part of.
This is the third article in a series, sharing a number of observed antipatterns and corresponding patterns on the topic of organisational agility.
Traditional organisations need to adopt new ways of working in order to survive and thrive, to leverage the on-demand compute, information and communication power which is in the cloud and in our pockets, to keep up with competitors and challengers, and to delight customers. Today, for complex knowledge work, many are still applying a management model from the early 1900s optimised for manual labour in factories.
The antipatterns and patterns are based on lessons learnt through doing, including learning from failing. We have been servant leaders on better ways of working, applying agile, lean, DevOps, design thinking, systems thinking and so on, across a large (80,000 people), old (300+ years old), global, not-born-agile, highly regulated enterprise. I have been delivering change with an agile mindset, principles and practices since the early 1990s, about a decade prior to the Agile Manifesto, when the term ‘lightweight processes’ was used. The antipatterns and patterns are also based on learnings from the community, from other horses, rather than unicorns, on similar journeys.
Antipattern: Golden Hammer
The mandating of one set of prescriptive practices, organisation-wide, is often combined with the capital A Agile and capital T Transformation antipatterns. The Golden Hammer antipattern was summed up by Abraham Maslow in 1966 who said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail”. Herein lie two antipatterns: (1) Golden and (2) Hammer.
Antipattern part 1: Golden
Mandating any one set of practices on people and teams is an antipattern.
“Imposing a process on a team is completely opposed to the principles of agile, and has been since its inception. A team should choose its own process — one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking. Not only should a team choose their own process, the team should be in control of how that process evolves.”, Martin Fowler, 2006 (source)
The Agile Manifesto emphasises individuals and interactions over processes and tools, collaboration over contract negotiation, motivated individuals who are given support and trusted to get the job done, self organising teams regularly reflecting on how to be more effective, tuning and adjusting their behaviour, practices and processes.
“With so many differences, how can we say there’s one way that’s going to work for everybody? We can’t. And yet what I’m hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty. I was gonna say “tragedy”, but I think “travesty” is the better word because there is no one-size-fits-all. ”, Martin Fowler, Agile Australia 2018 (source)
Unfortunately, it is common at the moment to see prescriptive processes being mandated across teams and across organisations. This should not be done. Inflicting capital ‘A’ Agile is not empowering, it does not show respect for people, it drives fear and resistance and it is not taking an agile approach to agility. It moves the locus of control to be external, reducing psychological ownership and intrinsic motivation.
Perhaps this is not surprising where many leaders in large, traditional firms have got to where they’ve got to with a reductionist, predictive, command & control mindset. This gives rise to the Agile Industrial Complex. An old ways of working view is being applied to new ways of working. In some cases, it may take a new generation of leaders.
“Knowledge workers themselves are best placed to make decisions about how to perform their work”, Peter F. Drucker
Antipattern part 2: Hammer
There is no one-size-fits-all for organisational agility. There is no One Way™ that optimises outcomes in all contexts.
Your organisation, your customers, your value propositions, your environment, your processes, your system of work, your leaders, your teams, your constraints, your starting point, your behavioural norms, your heritage, your brand, your team and you, are unique.
“If the path ahead is clear, you’re on someone else’s path”, Joseph Campbell
Organisations are heterogeneous, not homogeneous. Organisations are emergent, not predictive. Organisations are complex adaptive systems.
“A complex adaptive system is a dynamic networks of interactions, their relationships are not aggregations of the individual static entities, i.e., the behavior of the ensemble is not predicted by the behavior of the components. They are adaptive in that the individual and collective behavior mutate and self-organize corresponding to the change-initiating event.” Wikipedia (source)
Growing agility (rather than scaling capital ‘A’ Agile) enterprise-wide is about leveraging that complexity, diversity and emergence, not inflicting sameness on every team. The approach to organisational agility cannot be cookie-cutter.
Your context is unique. To illustrate this point, here are some of the factors that make up your context:
It is interesting to note that the People category has the most contextual criteria and Tooling the least, reinforcing how much this is about people.
It was a quick exercise to brainstorm these contextual criteria and it surprised me that as many as 90 criteria emerged in a short amount of time. This is 1.2 x 10²⁷ (1.2 octillion) unique combinations of the criteria, assuming the criteria are binary, which they aren’t, there are many more combinations. Clearly, your context is unique and across a large organisation there are many unique contexts, like fingerprints. And your context is changing. And that pace of change is getting faster.
There are two contextual criteria in particular that I’d like to call out. Scaling Agile and Culture.
Scaling Agile can have many interpretations and meanings, from a handful of teams on one large product with dependencies not broken, all the way to the diversity and complexity of organisation-wide agility with thousands of value streams, teams and contexts. Depending on why you want to ‘Scale Agile’ and what you mean by ‘Scaling Agile’, your approach will differ.
Understanding the Incumbent Culture is key. Within one large organisation there will likely be a number of separate prevalent cultures, due to history, folklore, location, leadership style and so on. It would be foolish to take one approach across different cultures. There are many cultural models to use as a guide. Take Westrum’s typology as one example. If the starting culture is Pathological, then psychological safety will be thin on the ground. An autocratic culture is prevalent and in the worst cases there is a culture of fear with learned helplessness. I’ve spoken to teams who didn’t dare to inspect and adapt. A revolutionary approach to changing ways of working is not likely to be successful in this context. I have seen it fail with the imposition of Scrum and synchronised Sprints, which was a case of inflicting revolution in an environment with a lack of safety. A better approach in this context is inviting evolution over imposing revolution, starting with what you do now, for reasons I go into below.
“The level of consciousness of an organisation cannot exceed the level of consciousness of its leader”, Frederic Laloux
If the starting culture is Generative, if there is psychological safety, if there are already pockets of mastery, if there is strong survival anxiety with a high cost of delay, then it is possible that inviting revolutionary change is preferable in this context.
The challenge for any framework of practicecs in an emergent context is the balaning line between prescription for beginners and flexibility as people gain mastery. A framework either explicitly caters to adaptability to context by not being prescriptive on practices, shining a light on the problems and letting people work out how to solve them, or it is prescriptive and dogmatic. In the latter case as mastery grows you can treat the framework as a departure point and inspect & adapt away from it, so it is no longer being ‘done’, if that improves your outcomes.
Scrum and its scaled variants such as SAFe, LeSS, Nexus and Scrum@Scale, are revolutionary rather than evolutionary as they introduce new roles, artifacts, events and rules. The new roles, artifacts and events are non-negotiable. You’re either doing it or you’re not doing it. The scaled variants have evolved in in a context of scaling vertically, many teams on one large product, with dependencies. Disciplined Agile supports context sensitive choice with guidance. It suits the context of enterprise agility and scaling horizontally, catering to diversity and emergence, with guardrails. The Kanban Method is evolutionary, you apply it to your process, it shines a light on flow and impediments to flow. More on this topic in a subsequent post.
All are useful tools to have in the toolbox. One size does not fit all.
Pattern: Give People a VOICE
Don’t mandate one set of prescriptive practices across your organisation. Instead, apply an agile mindset to organisational agility and give people a VOICE.
Values & Principles
Intent Based Leadership*
Have your own clear and updated Values & Principles that guide every decision across contexts. Focus on Outcomes (for example, Better Products Faster Safer Happier), with a clear Why, with measures and fast feedback loops, not agile for agile’s sake or because your competitors are doing it. Practice Intent Based Leadership and empowerment based on the principle of Commander’s Intent, decentralise decision making, strive for high autonomy with high alignment, including teams working out for themselves how they will improve on the Outcomes in their context. Agility by invitation, not Agile Imposition. Leaders go first, role modelling the desired behaviours, with a clear employee engagement model. Provide Coaching and support to unlearn old habits and learn new ones, to grow mastery and to remove organisational impediments. Leverage many bodies of knowledge, have many tools in the toolbox. Be an omnist. Leaders at all levels coach and support continuous improvement and technical excellence. Perform Experimentation at all levels with fast feedback. Probe, Sense and Respond at the organisational, business unit and team level. Implement double loop learning. Become a learning organisation. Be the best at being better.
Values and Principles
Determine, update and repeatedly communicate the Value and Principles for your organisation, which inform every decision. These are the behavioural guardrails. They signal intent and they allow for behaviour which is not in line to be called out. This includes teams holding their leaders behaviour to account, helping teams to manage up. They should be timeless (for example, ‘Customer Obsession’ or ‘Continuous Improvement’) and apply across contexts.
Having defined your Principles, with many unique contexts, the practices will differ. To quote Dan North:
Practices will emerge by applying your unique Context to your Principles, with coaching and experimentation, leveraging many bodies of knowledge.
As articulated in the first post in this series, for the organisation clearly articulate Why you are looking to improve ways of working and what the desired Outcomes are (for example, Better Products Faster Safer Happier), each one having one or more measures. The Agendashift From Obstacles To Outcomes (FOTO) exercise is one tool which can help identify the Outcomes. Another source of inspiration are the Capabilities listed in Accelerate (Forsgren, Humble, Kim, 2018) which are correlated to higher organisational performance.
Intent Based Leadership
Adopt Intent Based Leadership as modelled by modern military command. Having provided the high alignment, give people high autonomy, empowering teams to improve on the Outcomes how they see fit, with fast feedback, data and support, starting small. Move authority to the information, not information to authority, decentralising decision making. Do not impose prescription. Make improvement of the desired Outcomes transparent. Adopt a pull, not push approach, within guardrails so that it is agile not fragile. Critically, foster psychological safety, so that people feel safe to experiment, moving the locus of control to be internal. Be a Transformational Leader, moving away from a command and control leadership style from the 1900s in the context of manual labour in a predictive environment. As per the State of DevOps Report, Transformational Leadership is highly correlated with higher organisational performance.
“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”, Antoine de Saint Exupéry
Provide Coaching and support on agility, not just on one prescriptive framework. Provide coaching and support on a high bar of technical excellence, on removing organisational impediments to flow and on continuous improvement both small (Kaizen) and radical (Kaikaku).
A federated, fractal structure of small Enablement Teams is a pattern which we have had success with. They perform a Servant Leadership role. Servant: there to nurture culture, remove organisational impediments, support leaders and teams, with autonomy, pull not push. Leadership: there to ensure high alignment, that there are clear outcomes with feedback loops and organisational guardrails to ensure that it’s agile not fragile and to enable both speed & control.
Now that you have a hypothesis-driven desired outcomes with measures and you have autonomy within guardrails, with coaching and support in a fractal manner, starting small, it is time for Experimentation with fast feedback in order to make progress on your desired outcomes.
As you are performing unique complex work within a unique complex adaptive system, you need to probe, sense and respond in that order. As with any experiment, everything is a hypothesis to test. The outcome of the experiment is not guaranteed as the system of work is emergent. Acting in the space, changes the space. Due to this, consider that many experiments may not be reversible and cannot be replicated, as the complex adaptive system will already have reacted to the input. As per Systems Thinking, there is not a linear cause and effect.
To get started, I find the following model for navigating change, from Dan North, works well:
“Visualise, Stabilise, Optimise”, source
Visualise: Before you can run experiments, first you need to ‘see’ and measure your current system of work. Pick a big wall and physically map out your workflow steps and the work in the system. End to end, not just in IT. For the vast majority of teams they have never before ‘seen’ their knowledge work like a factory floor and it is a shock. Impediments become apparent. Add aging on the tickets. Typically work is waiting 90% of the time in large organisations. This is where the waste is, slowing down the system, like too many cars on the motorway. You should Know Your Flow.
Look where the work isn’t
Stabilise: Control the amount of work in progress (WIP) in order to stabilise flow. Start putting fewer cars on the motorway. Introduce WIP limits, meaning that no work can be started until there is a free slot. The system now becomes a pull system, with work being pulled to the right.
Stop starting, start finishing
Optimise: Identify what you believe your biggest constraint to flow is and focus your improvement efforts on alleviating it, starting small, with fast feedback. Run one experiment (probe) and inspect the Outcome measures (sense). Remember that cause and effect are not linear. Work out what your next improvement experiment will be and go again (respond), amplifying positive experiments and dampening negative experiments. Make use of all bodies of knowledge, consider all frameworks to identify optimum practices for your unique context. Causal loop diagrams are a useful tool.
Once insights are generated from the improvement experiments, practice double loop learning to reflect back on the original Principles and Outcomes. Reflect, with contextual evidence, whether they should be updated as you gain more insight.
Be an Omnist
Any frameworks, practices or tools are a departure point, not a destination. Be an omnist. Draw from multiple knowledge bases, don’t only have one tool in the toolbox. Find your own way.
“Omnism affirms the necessity of one arriving at an understanding of reality based on personal experience, engagement, and inquiry, and an acceptance of the validity and legitimacy of the differing understandings of others. In this, there is, however, an implied system of values.” (source)
Values & Principles and Intent-based Leadership* give people autonomy within guardrails. Outcomes provide purpose. Coaching & Experimentation help people to build mastery.
OH: “It doesn’t feel transformational because the people affected by the changes are the ones driving those changes”
This approach shifts the locus of control of the complex adaptive system inward, such that people are invited to be, and with safety and support become, masters of their own destiny. In some cases, this requires overcoming an entire career of conditioning that the locus of control is external, that both the how and the what are prescribed. For some people, cultures, contexts and complex adaptive systems, Kaizen, evolutionary change is needed first, to show that the sky won’t fall in, to build confidence.
In order to deliver better business outcomes, to engage colleagues and delight customers, for change to be successful and lasting, don’t Inflict Agile, instead give people a VOICE.
Want to do an Agile Transformation? Don’t. Focus on Flow, Quality, Happiness, Safety and Value
Want to scale agile? Don’t. Descale the work first. Achieve big through small
In praise of SWARMing, Dan North
Also by the author:
Know Your Flow
Agile Manifesto Values add on for large enterprises
The PMO is dead, long live the PMO
The Yin and Yang of Speed and Control
Acknowledgements: thanks to Zsolt Berend, Mike Burrows, Tony Caink, Steve Denning, Mark Lines, Angie Main, Dan North, Simon Rohrer for feedback.
by Jon Smart, 21/09/22