Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why 'How to Scale Scrum' Is the Wrong Question to Ask

DZone's Guide to

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.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

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.

Design 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.

Organizational Design

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.

Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

Topics:
agile ,scrum ,agile adoption ,scrum teams

Published at DZone with permission of Cesario Ramos, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}