On September 12 2019, we ( Nadine, Joris, Vaishal and Cesario ) provided the keynote at the LeSS conference in Munich. We shared the story about how we improved the Spotify inspired ING model with LeSS. My friend Rowan Bunning was present at the keynote and wrote a super nice summary of the talk. You can find his blog here.

The paper ‘Why Isn’t Your Current Approach to Scaling Agile Working?” written by Cesario Ramos co-authors with Kurt Bittner was recently published on InfoQ.

Having trouble scaling your agility? You’re not alone; even organizations who have agile success in isolated pockets have trouble scaling that agility to the broader organization. The challenges express themselves in familiar patterns. Do any of these look familiar?

  1. Your copy of another organization’s model doesn’t work
  2. Your organization’s design conflicts with the goal of agility
  3. You are trying to “copy and paste” what works for one team to all teams
  4. You are independently optimizing different parts of the organization
  5. You are under-invested in agile engineering practices

In this paper, we discuss common systemic challenges for scaling agility. We close with a comparison between the approach to these challenges by popular scaling frameworks.

You can read the complete paper at InfoQ here.

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.

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

I was talking to a company that is implementing the Spotify model and needed some help. They wanted to know the difference between LeSS and their Spotify model. We first discussed what LeSS is. I told them that LeSS is an organisational design that optimises for shortest lead time, flexibility and learning. What single team Scrum does for a 1 team, LeSS does for whole development organisations.

This answer started an interesting discussion on the difference between between their Spotify model and LeSS. I am not an expert on Spotify model but I understood enough about their implementation to have a good discussion. I briefly summarised the 3 main points of our discussion below:

Human resources

A possible difference between their Spotify implementation and LeSS is that they have ‘chapter leads’ that have HR responsibility over people in their chapter. So for example they can have a Testing chapter with a lead that has HR responsibility of the testers in that center of excellence; this is a single function organisational element. In LeSS we try to not have such a single function organisational structure. Instead, cross-functional managers that have HR responsibility over cross-functional teams are preferred; this promotes multifunctional-learning and therefor flexibility of your organisation.

Continuous improvement

Another point is that LeSS is based on Empirical Process Control; there is no model to copy. Copying a model from another organisation is dangerous as contexts differ and it is highly likely that it won’t provide the benefits in another context. The most value is not in copying the model itself, but in the journey of discovering a model that works for you, and all the learning that follows from that.

But even worse is that copying a model will not lead to a feeling of ownership. Ownership is promoted when people create something themselves, and if people feel ownership it is more likely that they will improve it; hence it is a precondition for continuous improvement by the people doing the work. Just copying what other people do, makes it harder to feel ownership. It will be more like renting and that makes a difference. I treat my rented cars different then the cars I own 🙂

Also, from the perspective of continuous improvement it might not be such a great idea to reach for an end state that you can actually reach; because you might actually get there 🙂 And then what?, what happens when you have implemented the model? are you then done? mission accomplished?

This company understands that and they take continious improvement very seriously.

The model emerges

So, deciding to implement a model a-priori as the end solution is like providing the answer before knowing the question. To me this is kind of silly; don’t do that. Instead you can start with the simplest process that works. And then you build it up using Empirical Process Control and a framework that makes transparent to all what to improve; that framework is called Scrum. We like to say that it is better to build your method up instead of tailoring it down. So you add stuff as the need for it emerges.

From what I understood they are doing that and doing it successfully.

These days scaling Scrum is a hot topic. How can I use Scrum to deliver a big product with multiple teams? The most common approach I see at my customers is scaling Scrum by adding more Scrum teams with a Product Owner and Scrum Master per team.

Scaling using Copy-Paste

Scaling is about increasing in size. I’ve been told that fire departments scale their operations depending on the severity of the fire. Depending on the scenario, they increase the size of the trucks that join the fight, the number of trucks, the number of people and the coordination and communication process as needed. This approach is what I call Copy–Paste scaling. You ‘copy’ the trucks and people needed and ‘paste’ them to form a larger group while adding extra processes for communication and coordination.

When you apply this scaling approach to Scrum this means increasing capacity by copying and pasting Scrum Teams in your development group. You add Product Owners, Product Backlogs, Scrum Masters and Development Teams. To support and coordinate this growth, organizations typically augment with special roles such as ‘feature owners’. They also add extra layers of coordination, e.g. ‘release train management’, extra processes e.g. ‘integration test phases’ and even additional artifacts e.g. ‘value stream backlogs’. Unfortunately, this approach results in diminished team-customer collaboration, leading teams to focus on delivering components in isolation, instead of an integrated potentially shippable product. And now you are slowing down rather than speeding up.

The Copy-Paste approach to scaling Scrum gets you into trouble rather quickly because of three main reasons:

  • Scrum and Agile are based on essential values, principles and practices and just adding more people does nothing about using those at scale.
  • Developing software is creative work not production work. Therefore, adding people does not necessarily increase productivity.
  • The ability of teams to independently produce valuable and bug-free product every Sprint is essential. Copy-Paste scaling does nothing about improving the required engineering practices.

An example at one of my customer sites.

One of my customers operates in the energy trading business and their development group is distributed across three sites. They initially started with a few teams, but quickly scaled up to thirteen teams over a couple of months due to market demands.

Figure 1: The added overhead of Copy-Paste Scaling. (E.g. The Green Feature is developed out of sync introducing sequential development.)

The development group supports a business process that consists of roughly thirteen steps. Naturally, following a copy-paste scaling approach, they formed thirteen Scrum Teams for those thirteen steps. Each team had its own fake Product Backlog, Scrum Master and fake Product Owner. Each team worked on a single step of the business process, even though a feature largely required multiple business process steps in order to deliver value to a customer. Therefore, the teams did not optimize for adding customer value but rather for producing lots of code.

As a result, the teams and “Product Owners” needed extensive planning and coordination in order to align their work and deliver an integrated product. Additionally this model also introduced delay in testing and customer validation; hence more defects, information scatter of a feature across teams and opaque measures of progress. The result was low productivity, high defect rates and unhappy customers.

What to do?

With large products, there are generally a lot of users. These users typically get value by working in a single area of the product. When there are many such Value Areas in your product, often you find the necessary deep understanding of all those areas cannot be maintained within a single Scrum Team. Therefore, you should scale your Scrum organization along customer domains or Value Areas.

When you specialize your teams along Value Areas as seen from the customer perspective, the teams can focus on a subset of the customers. Therefore, each team needs to understand one customer domain only, while still able to deliver complete features that the Product Owner can sell. Therefore, you only need 1 Product Owner and 1 Product Backlog and no added organisational complexity. You have multiple team Scrum instead of multiple Scrum teams. 

You can read more about this in the paper Scale Your Product Not Your Scrum and the Scrum pattern Value Areas.