Some companies develop 1 product with 10s to 100s of people using Scrum. And they do that without adding any roles, events or processes to Scrum. They can do this because they use an organisational design that optimises for the right goals.
Design Goals
An organisation has a design, just like a truck or a Formula-1 car have a design too. A big truck is designed in such a way that it can efficiently move cargo from point A to point B. The efficiency usually comes at the price of long maintenance times. Changing the tyres e.g. is pretty hard work; it is usually done with a couple of people, requires lifting equipment and takes hours to complete.
The design of a Formula 1 car is optimised for speed and flexibility, and the car is not designed to keep working for a long time —1 race is enough. During a pitstop, more than 20 people work together and change the tyres really fast. All of the people have a specific task and spend most of their time waiting for others to complete their task. Working with this design makes it possible to change tyres much quicker than with the truck design — the world record was 1.92 seconds.
If you want to be able to change the tyres of a big truck in 1.92 seconds, you can try by using one of those Formula-1 pitstop teams. But that won't work, you will just end up with new roles, new tools and a new process. The design of the big truck is simply not optimised for speed; if you want to change the tyres of a big truck in 1.92 seconds you have to redesign the truck.
Organisation Design
A common organisational design is the Hierarchy. The Hierarchy optimises for a lot of things, but not for adaptability and speed.
John Kotter highlights some other importing goals of the Hierarchy.
”...the challenge is that, at both a philosophical and a practical level, the Hierarchy (with its management processes) opposes change. It strives to eliminate anomaly, standardize processes, solve short- term problems, and achieve stopwatch efficiency within its current mode of operating...” - John Kotter
Some more optimising goals of the Hierarchy are control and resource utilisation a.k.a. 'ass to chair time'.
The Hierarchy leads organisations to be designed as single function groups. The groups are managed by single function managers and have key measures and targets to assess how well they are performing.
There are groups that specialise in a part of the business like for example contracting or billing. Next to that, you also see specialisation in technology like for example, Java, .NET, Oracle and so on. Furthermore, you can find groups specialising along functions like testing, architecture, security and project management.
The Optimising Goals of an Agile Organisational Design
There is nothing wrong with the Hierarchy as long as it's optimising goals are in line with the goals you want to optimise for. But, if you want to become Agile you probably want to optimise for the following goals:
- Shortest Lead time - The delivery time from idea to working product in the hands of the customers;
- Adaptability - Being able to change direction fast and at low cost and
- Learning - Learning about the customer needs and wants; learning about the product, the used process and organisational design.
And these goals are not in line with the goals of the Hierarchy.
Organisations who want to become Agile in the Hierarchy often try by introducing new roles, new ceremonies, new processes and artefacts; but it is very unlikely that they will succeed. At best, they will end up doing lots of Agile ceremonies, with new fancy names for the same old things, but will not become Agile. It is like bringing the Formula-1 pitstop team to change the tyres of your big truck in 1.92 seconds, it just won't work!
So, do not ask how to scale Agile across your Hierarchy.
Instead Ask: How To Redesign Your Organisation And Become Agile?
To become Agile you need an organisational design that optimises for the right goals! This often means an organisational redesign with very broad impact. Below a few typical steps to take:
- Design your organisation around your product so that it optimises for delivering a customer feature end-to-end without delay. You do not want to optimise on resource utilisation or 'ass to chair time'.
- Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle.
- Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block.
- Organise your teams, that work on 1 product, to work in a single iteration. And ask them to produce an integrated product increment every iteration so that you maintain a consistent view on progress.
- Move to cross functional line managers working in a cross-functional organisation so that single function optimisation is discouraged.
- Introduce a Human Operations system that also values team work and strives for the right competencies.
Find out more
As one of the ScrumPlop authors, I strongly recommend to read the pattern sequences we wrote. Furthermore, I recommend the LeSS publications and Nexus Guide for learning more about building your Agile organisation.
- Scaling Sequence at ScrumPlop.org
- Product Organisation Sequence at ScrumPlop.org.
- LeSS Organisational Structure.
- Nexus Guide.