Want to scale agile? Don’t. Descale the work first. Achieve big through small.
This is the second post in a series, sharing a number of observed anti-patterns and corresponding patterns on the topic of organisational agility (aka digital transformation).
We are in the midst of a Turning Point in a 50 year cycle, in the Age of Digital, as well articulated by Carlota Perez in ‘Technological Revolutions and Financial Capital’. At the time of writing, seven of the top ten firms by market capitalisation are technology companies. Less than two months ago, on 26th June 2018, General Electric, the last remaining original constituent of the Dow Jones index which was created in 1896, left the index, as it was contributing less than half a percent. In 2004, GE was the largest firm in the world by market value and only two years ago, in 2016, GE was still in the top ten. This is an indication of how we are in the Turning Point, how the previous industrial incumbents are shrinking and how firms with new business models and new ways of working, leveraging significant shifts in technology have become the new dominant forms of human organisation.
In sharing the anti-patterns and patterns, it is worth noting that everything is context dependent. An anti-pattern for one scenario might be a pattern in another context, in particular based on the current cultural norms of an organisation. That said, I believe that the anti-patterns to be presented are applicable in the context of the majority of large, old, bureaucratic, global enterprises (horses rather than unicorns).
They are based on lessons learnt through doing including learning from failing. Along with many talented people, we’ve been servant leaders on better ways of working (the application of 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, with personal experience of delivering change with an agile mindset, principles and practices since the early 1990’s, about a decade prior to the Agile Manifesto, when the term ‘lightweight processes’ was used. The anti-patterns and patterns are also based on learnings from the community, from other horses (rather than unicorns) on similar journeys.
Anti-pattern: The bigger the capital ‘T’ Transformation, the bigger the change curve
The Kubler-Ross Curve originated from psychiatrist Elisabeth Kubler-Ross’s work on grief, published in 1969. It has been found to be valid in the majority of situations relating to change and we have repeatedly observed this pattern to hold true via feedback from colleague surveys.
The bigger the capital ‘T’ Transformation, the bigger the change curve. If embarking on one large, broad, Transformation, expect an almighty big and deep dip in the curve. The bigger the dip, the harder it is to climb out of and the longer it takes. Given that some firms are facing an existential threat, there may not be sufficient time to climb out of that big dip.
In large, diverse, regulated, multinational organisations, where the cultural norm is most likely to be control or competence based, a capital ‘T’ Transformation with a big dip in the curve, will make the journey a harder and more challenging one. There will be a greater degree of denial, frustration and anger. The change stands a higher chance of cultural tissue rejection, with more ammunition for those averse to change. Things will get significantly worse before they get better.
For organisations that take this approach, with a broad scope, where people leave as a Project Manager on a Friday and rejoin as a Scrum Master on Monday, and in some cases need to reapply for their new role, the chances of genuine, embedded, internalised, long lasting, successful change which leads to improved business outcomes, over cargo cult behaviours and new labels on existing ways of working, are greatly lowered. As per this post , this drives fear, which drives a lack of action and resistance.
Hardest at the beginning
When starting out on transforming ways of working, increasing organisational agility, embarking on a ‘digital transformation’, it is hardest at the beginning. The antibodies to change are strong, there are vested interests at stake, the impediments to better ways of working and flow will be at the their highest, there will be the most amount of dependencies impeding flow, understanding is low, the force is strong with cognitive biases with no anecdotal stories or hard data from the organisation to challenge them and this is Yet Another Transformation (time to put your head in the sand and let it blow over). An analogy is skiing. It’s cold, painful, slow and hurts when learning to ski. It’s hardest at the beginning, uses up the most energy, when snow ploughing. Break past that, and once able to parallel turn, enjoyment goes up, speed goes up, energy usage for the same distance and time goes down, it becomes fun and addictive. Does it make sense to have a large number of people all snow-ploughing at the same time, on poor quality snow, in an environment not yet set up for skiing, bumping into each other, without enough ski instructors to go around?
Limited re-learning velocity
Furthermore, large, old, bureaucratic, traditional organisations have a limited capacity and a tolerance with which they can change over time. Organisations have a limited re-learning velocity. Re-learning requires organisational unlearning, which is harder than learning from a clean sheet. Behavioural science studies show that cognitive overload is a major theme in rejection of change. Cognitive reasoning is finite and easily depleted. According to research by Dr Wendy Wood, approximately 40% of decisions that people make everyday are not decisions, but are habits and the majority of these habits in going from a traditional to a new way of working, need to be unlearnt.
“The thoughtful intentional mind is easily derailed and people tend to fall back on habitual behaviors. Forty percent of the time we’re not thinking about what we’re doing. Habits allow us to focus on other things…Willpower is a limited resource, and when it runs out you fall back on habits.” (source)
Where the change has not been internalised and embedded, where it is forced across an organisation in a broad manner, it is like one large elastic band, as soon as a leader mandating capital ‘T’ Transformation moves on, the organisation (people’s habits and codified processes) snap back into previous ways of working. It takes 3 to 5 years, best case, for a large traditional organisation to develop a new muscle memory. And then there is no end date to continuous improvement. For more on this topic, see Barry O'Reilly’s book Unlearn (Nov 2018).
Big Bang. Big Risk.
This approach is also not living it’s own values or applying its own principles. It is not applying an agile mindset to increasing organisational agility. It is big batch, big bang and big risk. It is approaching change in a manner counter to the change being asked of colleagues.
Bureaucracy
According to Parkinson’s Law, “ work expands so as to fill the time available for its completion”.
I propose a corollary to this which is that “processes, control points and standards expand based on the number of audit and control staff employed”. This is in an uncontested space (i.e. in the absence of a group of people focussed on optimal ways of working)
Parkinson goes on to say that “the number employed in a bureaucracy rise by 5–7% per year irrespective of any variation in the amount of work (if any) to be done”.
He cites two factors: (1) “An official wants to multiple subordinates, not rivals” and (2) “Officials make work for each other” and he gives the British Colonial Office as an example. In the nearly twenty years from 1935 to 1954, looking only at peacetime years, the average rate of growth of employees at the Colonial Office was 5.89% each year (within a narrow range of 5.24% to 6.55% p.a.), whilst the British Empire shrunk by 76% from 17 to 4 million square miles in the same time period. The size of the Colonial Office was inversely proportional to the size of the the Empire.
“It would be rational, prior to the discovery of Parkinson’s Law, to suppose that these changes in the scope of Empire would be reflected in the size of its central administration. But a glance at the figures shows that the staff totals represent automatic stages in an inevitable increase. And this increase, has nothing to do with the size — or even the existence — of the Empire.” (Cyril Parkinson, 1955)
As large, old, enterprises, with years of organisational scar tissue and 100 year old ways of working are going to be at the highest level of inefficiency and bureaucracy that their revenues can (or perhaps in the Age of Digital, cannot) support, this is one reason why it is sub-optimal to take that organisation and apply a scaled agile framework across the whole organisation in one go.
It is important to descale the organisation, to descale the work, before scaling agility (not scaling capital ‘A’ Agile, which is doing not being).
Achieve big through small
Start with small teams, small slices of value and small investments.
“Nail it before you scale it” (thanks Cliff Hazell)
Pattern: In order to scale, descale first. Achieve big through small
Instead of a big bang transformation, with one big dip in the curve, achieve a big outcome through early, often and small slices of value.
Pursue evolutionary and continuous transformation aligned to outcomes, linking together a series of smaller change curves. Start in areas which are naturally receptive, the natural champions. The dips are not as deep, the learning and feedback is quicker, there is less risk and the champions, who have been trying to do this despite the firm in the past, are best placed to beat a path through the organisational jungle, likely with a growth mindset and personal resilience.
This approach is in line with the Kanban Method principle “Agree to pursue incremental, evolutionary change”. As time goes by, I have found myself to value David J Anderson’s Kanban Method principles and practices more and more, in the context of organisational agility, at all levels from strategy to the team.
Hence, don’t take a large team working in a traditional manner, on a traditionally developed product (whether IT or not) and apply revolution all in one go. Apply an agile mindset to the rollout of agile. Achieve big outcomes through (1) small teams, (2) small investments and (3) small slices of value, supported with capability building, training and coaching as well as help to remove organisational impediments. Identify where there is ‘elephant carpaccio’ which can be delivered, when starting out with a traditional waterfall team, likely as per Conway’s Law, with a monolithic system. Eventually there should be no elephant in the room. Leaders should ensure that there is a psychologically safe environment for experimentation and learning.
Case study of descaling work
By way of an example, I’m aware of a scenario where there was a team of about 100 people who had multiple multi-year failed attempts to deliver business value in a waterfall manner. Following this, with the appointment of a leader who had a track record of successful delivery, a team of five was created, working with agile principles and practices. Within 12 weeks, there was a product in the hands of customers, in a production environment, solving a customer need and providing much needed learning and feedback. From this point on, the team size didn’t grow to be above three teams of nine or fewer people each, despite expanding significantly in scope in terms of the business lines supported, due to the success in the first business line.
Taking the original 100 people and applying a frog march of mandated certification, re-applying for your job with a different title and a cookie-cutter approach would not have addressed the inherent bloat at the time (it’s not a 100 person problem, in fact 100 people is a large part of the problem), would not have internalised the change so that it comes from within thus building a learning organisation, is not optimised to context, is costly and does not maximise business outcomes & customer delight.
Fractal
For large organisations, and the approach that we have taken, where there are multiple business units (each one large enough to be standalone company in it’s own right, and in fact used to be, with their own culture and folklore), the ‘achieve big through small’ approach can be taken concurrently (whilst limiting Work In Progress) in a fractal manner. Each business unit pursues a limited series of small change experiments starting in fertile soil, with a small central Centre of Enablement (CoE) providing servant-leadership support and dealing with bubbled up organisational impediments. An agile mindset is applied in terms of empowerment and not being prescriptive on the How (within guardrails and a common vocabulary). This in turn can be done at the sub-BU level, and so on. The leads from each business unit come together weekly as a virtual team. Applying an agile mindset, all of the virtual teams of BU or sub-BU leads are agile team sized (single digits). It’s quick to spot common organisational constraints and allows for swarming on alleviating the constraints.
Scale agility, not Agile, vertically then sideways
A mistake that we’ve made in the past has been to start at the team level and go sideways (more teams), along with the top level support. However, even with specific targeted training, this can fail to engage one or more levels of middle management, also known as the Frozen Middle or more kindly, the Pressurised Middle, as there is not always a clear role to play in the change. This is a common characteristic in any culture change in large organisations and is not a reflection of the people, it is a reflection of the situation they are in and how people in these roles are engaged.
A personal learning, when starting small, from a people perspective, is to have a vertical slice of an organisation go first. The leadership team is team #1. With the existing structure, have a vertical slice of that org volunteer to go first, including leaders at all levels, preferably natural champions, with as few dependencies on other teams as possible. Ideally this will be value stream / product / service aligned, not a role-specialisation alignment, such as just the BAs or just the Engineers or just the PMs. Middle management at as many levels as there are, have an explicit role, coaching and being coached on continuous improvement in ways of workings, as per the Toyota Coaching Kata and with multiple-level portfolio Kanban being adopted to focus on visualising and limiting work in progress.
Then scale agility (not capital ‘A’ Agile) sideways, at a sustainable pace, working towards the organisation becoming a network of interdependent services. Go for more slices of the organisation, which are value stream / product / service aligned, supported by a small BU Centre of Enablement, providing coaching, training, shared learning, clearing the path for the teams. Pursue incremental, evolutionary, outcome-oriented, continuous transformation.
This doesn’t mean that scaled agile frameworks are not used. It is up to each team and area to decide what works best for them. Each framework is a valuable body of knowledge and can be a good departure point. In some cases they can provide a common vocabulary and in all cases it’s about trying what works in your unique context, with a focus on better business outcomes (as per my previous post). We aim to avoid framework fundamentalism, preferring to be Omnists. For more on this topic, see Dan North’s excellent article on SWARMing.
Again, at the beginning it’s the hardest, as the rest of the organisation is not set up for Continuous Everything. Several years in and good progress has been made by supporting functions (GRC type functions, InfoSec, Compliance, Audit and so on) also working in a way which supports small and often, conversation over a contract, with multidisciplinary long lived small teams, value stream aligned and in a context-relevant not one-size-fits-all manner.
Exemplar Community
To help amplify the learning, the overcoming of impediments, and adoption of better ways of working, we have an Exemplar Community. There are benefits of membership, such as additional training, external speakers, shared learning and prioritisation on the pull of the virtual andon cord. You don’t need to be exemplary to join, it is voluntary and there is a psychological contract in that teams agree to strive to become exemplary, jumping in with both feet, with a focus on measurable business outcomes (not activity or output). Consistently these teams exhibit far superior outcomes (for example 23x fewer production incidents on average), provide hard data as to benefits for the critics who are swayed by hard data, provide storytelling for emotional buy in and via cellular mitosis are able to spread better ways of working.
UK Government Digital Service (GDS)
UK GDS have taken a similar path. To quote Adam Maddison, ex-Head of Agile Delivery at GDS from Agile Cambridge 2016:
“What’s our approach to scaling at GDS? Do not scale. But we do have a number of large programmes.”
“At GDS we absolutely haven’t ignored scaling frameworks. We’re quite happy to use features from those frameworks if they truly deliver value. But we are absolutely not wedded to any methodology or framework. We will always adapt features to our own use.”
In both the case of GDS and in our context, the ‘big’ in ‘achieve big through small’ is articulated via the Roadmap, which articulates Strategic Objectives and quarterly Business Outcomes on long lived value streams / products / services. These in turn are broken down into small vertical slices of value, like layers of an onion, as outcomes not activities and delivered via Continuous Everything. Achieving big outcomes through many small steps and continuous learning.
Summary
- Achieve big through small
- Descale the organisation and the work first
- Nail it before you scale it
- Scale agility, not capital ‘A’ Agile, at a sustainable place, with support
- Leaders go first
- Work towards the organisation becoming a network of interdependent long-lived services, with high cohesion, low coupling and customer-centricity
- Apply an agile mindset to the adoption of agility
