The odds say that at some point in the last couple of years, a group of people that looked remarkably like this stock photo presented a flashy looking proposal to your board or executive team.
The proposal would have been printed on fancy paper stock, and sprayed with a light perfume.
It would have been handed over by a person with impeccable cheekbones and shiny cufflinks.
It would have promised to improve customer centricity through an ‘agile transformation’ and proposed something along the following lines:
- “We’ll base the transformation on the Spotify Model!";
- "We'll slash operational costs";
- “We’ll organise around ‘Customer Journeys’!”; and
- “We’ll create small, agile teams that will deliver faster!"
And the whole thing would have been utter, dribbling nonsense.
1. We’ll base the transformation on the ‘Spotify Model’
If... your organisation is not a digital native in the music industry, incorporated in Luxembourg, headquartered in Sweden, with offices in 17 countries, competing head to head with a key supplier, and has rough losses of 300 million euros on 8 billion in revenue
Then... the 2015 snapshot of Spotify’s engineering culture is probably not a great model for your organisation.
In 2015 Henrik Kniberg and Anders Ivarsson released a video describing a snapshot of Spotify’s evolving engineering culture and introducing the terms Tribe, Squad, Chapter and Guild to a broader audience. The authors have been consistent and explicit in their advice to other organisations: understand the principles behind what Spotify was doing, but design to your own context rather than copying someone else’s.
Concepts from Spotify’s model, from Google, from Atlassian, even from the Iriquois Confederacy, are useful, but copying how someone else does stuff and then pasting it into your organisation won’t work.
Ensuring that your operating model does not impede team success is one of the most critical aspects of leadership. The leaders of the system must:
- understand the goal of the organisation;
- understand their customers and how their products serve their needs;
- understand their supply chain;
- understand the technical, social, cultural, regulatory and geographical constraints to the way that they organise;
- design an operating model that is cognisant of those aspects; and
- continually improve it by identifying and removing impediments to the flow of work
Consultants can be really valuable in this process. They can bring great depth of theoretical and practical knowledge and broad perspectives gained from working across lots of industries.
But... if they promise to solve all your problems with someone else’s unique solution then they’re doing both you and themselves a disservice. With time your people will find ways to build the communication structures necessary to make things work in your context, but you’ll burn a lot of productivity and cultural goodwill in the process.
2. We’ll slash costs
If... you're using agile as a way to slash costs
Then... you're hampering your ability to create high performing teams
In the 1980s some familiar faces introduced matrix management to organisations. Matrix based management is the principle that if you have highly competent functional teams then you can use an orchestration layer (project / program and eventually portfolio management) to bring the functions you need to bear on a problem in the order in which you need them. Matrix based management actually works quite well in some operational value chains but it is fundamentally at odds with knowledge work because it is designed for large batches and fails to recognise that it is the knowledge that we acquire that is valuable, not the tasks that we complete.
When coupled with a tendency for low variability tolerance in traditional Project Management compared to the natural variability in knowledge systems, there is often a low level of trust between teams and leadership in matrix based organisations.
Through Project Aristotle Google discovered that Psychological Safety is one of the key attributes of High Performing Teams. To get the best out of our people we need high trust environments where they don't feel the need for self-protection.
If you use the term 'agile' to justify cutting headcount in an environment where trust is already a challenge, it's unlikely that the trust you need to implement it successfully will survive the process.
3. We’ll organise around ‘Customer Journeys’
If... you're trying to organise a complex enterprise around the Customer Journey
Then... you're going to have a bad time
Every organisation is different. They all have different constraints. They have unique people. Unique politics. Unique platforms. Unique supply chains. Unique customers.
Customer Journeys are great focal point in some contexts. However, it is also entirely appropriate for some parts of your organisation to be organised around business processes, platforms, capabilities, value streams or objectives. The idea that you can elegantly organise an enterprise of any scale around a single concept is mind numbingly reductionist.
There is a reason why most health systems use small cross-functional teams for things like surgery but use functional teams (GPs, Specialists, Nurses, etc) in general health operations. There is a reason why the military uses small highly capable squads for tactical missions but relies on more traditional structures for supply chain and logistics. There is a reason why the Enhanced Telecoms Operating Model (eTOM) is process aligned and delineates between the activities involved in planning, designing and building networks and the activities involved in operating them.
Every way that you organise your teams has inherent advantages and disadvantages (just ask anyone who’s tried feature teams for more than a year or two how perfect they are). Yes, some parts of the organisation might flourish when organised around a Customer Journey, but many parts of the organisation will flounder. You will get pockets of success and pockets of failure.
You will have far more success if you organise around a mix of operating model 'primes' rather than dogmatically trying to shoehorn your organisation into Customer Journeys.
4. We’ll create small, agile teams that will deliver faster
If... you're trying to create small, fast teams for everything
Then... you're going to drown in a sea of dependencies
There is a lot of research on team size. It is far from conclusive. Some research suggests that smaller teams, with heuristics like ‘7+/-2’, or ‘a team that you can feed with two pizzas’, are optimal. There’s also some work done on real life team data by Larry Maccherone from his time at Rally which suggests that bigger teams might be optimal in some cases (up to 15-20) if it means you can eliminate dependencies.
Why is the research inconclusive? Because context is king.
People like Don Reinhertsen and Troy Magennis have spent years looking at the flow of work through product and software development teams. Their conclusion? Throughput is primarily influenced by two factors - wait time (queue depth) and failure demand flowing back into the system. To take their work down to the simplest statement possible: Product and software teams are reasonably efficient and predictable at completing work, until they have to rely on other teams or deal with unexpected demand (e.g. failure demand). Small product / technology teams are highly effective in some contexts, but in some cases you might find you benefit from a larger team with less dependencies.
The nature of the work matters, too.
In a stable operational value chain dependencies between teams are reasonably easy to manage because their interactions tend to have less variance. Cross-functional teams are great for working out how to tackle a complex operational problem or working out the mechanics of rolling out something new, but process aligned teams tend to be better for operations at scale.
Team design should take into account the nature of the work, the capabilities required to deliver a slice of value, and the complexity of your environment. Lean towards smaller teams, but don’t be religious about it, and focus leadership efforts on the interactions between teams rather than the inner workings of the teams themselves.
As the vaccine roll-out starts to take effect most organisations are going to start moving towards a more stable remote first or hybrid remote model. Use an approach like the remote:af operating model design pattern that allows you to explore your context, agree on principles, and challenge your constraints. Bring your teams into a collaborative design process and create something that is unique to you. Never pretend that you're finished - your operating model and should evolve to meet changes in strategy, customer needs or budgets.
The people who pitched ‘agile transformation’ will be lining up to help, but it’s time to delete them from your playlist. Otherwise they'll be back again in five years selling the cure to the condition that they've created.
For a better approach to operating model design, read our series of blogs on the topic.
