Why 'How to Scale Scrum' Is the Wrong Question to Ask
Why 'How to Scale Scrum' Is the Wrong Question to Ask
Going Agile can be hard, especially for large companies used to working with older methodologies. Read on for some sound advice on adopting Agile.
Join the DZone community and get the full member experience.Join For Free
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 organizational design that optimizes for the right goals.
An organization has a design, just like a truck or a Formula-1 car has 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 tires, for example, 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 optimized for speed and flexibility, and the car is not designed to keep working for a long time —1 race is enough. During a pit stop, more than 20 people work together and change the tires 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 tires much quicker than with the truck design — the world record was 1.92 seconds.
If you want to be able to change the tires of a big truck in 1.92 seconds, you can try by using one of those Formula-1 pit stop 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 optimized for speed; if you want to change the tires of a big truck in 1.92 seconds you have to redesign the truck.
A common organizational design is the Hierarchy. The Hierarchy optimizes 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 optimizing goals of the Hierarchy are control and resource utilization, a.k.a. 'ass to chair time.'
The Hierarchy leads organizations 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 specialize in a part of the business like contracting or billing, for example. Next to that, you also see specialization in technology like, Java, .NET, Oracle, and so on. Furthermore, you can find groups specializing along functions like testing, architecture, security, and project management.
The Optimizing Goals of an Agile Organizational Design
There is nothing wrong with the Hierarchy as long as it's optimizing goals are in line with the goals you want to optimize for. But, if you want to become Agile you probably want to optimize 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.
- Learning - Learning about the customer needs and wants; learning about the product, the process, and organizational design.
And these goals are not in line with the goals of the Hierarchy.
Organizations who want to become Agile in the Hierarchy often try by introducing new roles, new ceremonies, new processes and artifacts; 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 pit stop team to change the tires 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 organizational design that optimizes for the right goals! This often means an organizational redesign with very broad impact. Below are a few typical steps to take:
- Design your organization around your product so that it optimizes for delivering a customer feature end-to-end without delay. You do not want to optimize on resource utilization or 'ass to chair time.'
- Find a Product Owner that understands the market, has an entrepreneurial 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 organizational building block.
- Organize 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 of the progress being made.
- Move to cross functional line managers working in a cross-functional organization so that single function optimization 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 reading the pattern sequences we wrote. Furthermore, I recommend the LeSS publications and Nexus Guide for learning more about building your Agile organization.
Published at DZone with permission of Cesario Ramos , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.