Scaling Agile
Summary
Once organizations realize that agile ways of working can tremendously impact time-to-market, customer satisfaction, and employee engagement among many other things, they start thinking about scaling agility.
There is a misconception that if you are a large organization, you need a scaled approach. This is not necessarily true, as scaling is primarily relevant for those cases where the product is too large for a small team to develop.
How to slice products and whether to scale or not are probably more important questions than what type of scaling framework to select. Unfortunately, too few organizations ask these questions – maybe due to the large push of scaling frameworks from consultants.
Given an organization needs to scale, there are many scaling frameworks to choose from, among them SAFe, LeSS, Scrum@Scale, and a few others. But none of these frameworks should be applied out of the box.
Our firm belief is that organizations should take inspiration from these frameworks but rather than copying them they should look at a set of principles like decentralization of decision making, lean thinking, and empiricism incl. continuous improvement.
In order for any type of change to be successful including scaling agile ways of working, it is essential for managers to adapt their approach to work. For most of them it means moving from working in the organization to working on the organization.
The primary focus becomes empowering (allowing for decision making) and enabling (building capabilities for decision making) of teams and individuals. For this to succeed, managers/leaders have to start changing the structures, policies, and metrics of their org in addition to systematic development of their teams and team members.
Introduction to scaling agile ways of working
In almost every workshop I conduct students ask me about how to scale scrum or agile teams. The reason they ask is that there are rarely up to 10 people working in their organizations – usually there are much more than that.
Many of them come from large corporations be it financial services, automotive, pharmaceuticals, or medical technology. In many large corporations they have large products e.g. a car with many i.e. hundreds of people working on them.
The misconception here is that having many people automatically results in a scaled approach. This does not have to be true. An organization can have many people and many teams but as long as each of these teams is working on an individual product they do not necessarily have to scale – at least in the traditional sense of how we use the term scaling.
What does scaling agile mean?
Scaling agile becomes relevant when more than one team is working on the same product. It is worth reemphasizing this: many teams working on the same product. So in order to determine whether you need a scaled approach, it is important to look at your product definition first.
How can you define a product?
There are many ways to look at this. One way is from the customer perspective. What do my customers consider as a product i.e. what are they willing to pay for e.g. Microsoft Office?
Another perspective is a more internal one: what are the different components of a product that we can develop mostly independent e.g. Microsoft Excel or functions within Excel.
One perspective many organizations take is neither of the above. They much rather look at the different architectural pieces of a product and cut the teams based on that. This approach results mostly in silos and a lot of dependencies in between teams.
The second option can in many cases result in many small teams working mostly independently, thus not needing a formal scaling approach. But even if a scaling approach were needed it is much easier to coordinate each team and cross-team work as product boundaries are clearly defined.
How do we scale?
Further down in this article we will sum up the most common scaling approaches. But before we get there, we’d like to evaluate the question of how we scale and what principles can help us to scale in a better way.
Any agile team e.g. a scrum team has three distinct accountabilities: What do we build? How do we build it (technical)? How do we collaborate (methodology)? The biggest difference between the various scaling approaches is whether they scale the full unit i.e. the Scrum team with all its accountabilities or whether they scale only the How accountabilities.
This distinction is important as it directly relates to one of the key agile principles which is decentralization of decision making to the place where work and customer interaction happens. It is also important as this determines how many new roles are created and what the role of leadership outside of these teams becomes.
What type of agile scaling frameworks exist?
There are many ways to scale agile development within an organization. None of these approaches covers completely how an organization should be structured. They usually just cover the product development unit of an organization.
All the supporting units within an organization such as Finance, Legal, HR, Purchasing are not covered by any of the scaling frameworks. Although some – including consultants who sell these frameworks – claim this the case, it really is not.
In the section below we intend to share with you a general overview of the most used scaling frameworks. But beware that most used does not mean best. Our firm belief is that each of these frameworks have some distinct benefits, but also significant downsides.
Better than just copying one of the frameworks, is to understand the key principles for scaling agile development and creating something within your organization that is constantly evolving based on regular and frequent inspection and adaptation. Every organization is unique in its culture and its challenges… your way of working should reflect that.
Scaled Agile Framework (SAFe)
The Scaled Agile Framework – also known as SAFe – is probably the best documented agile scaling framework. It was invented by Dean Leffingwell and is updated on a regular basis. You can take a look at the latest version here.
SAFe is probably also the most prescriptive of all scaling frameworks. Maybe this is the reason why many large organizations start their scaling journey using SAFe. As mentioned earlier, this does not necessarily mean that SAFe should be the scaling framework of choice. Actually, I have yet to see a successful SAFe implementation.
SAFe takes a team-of-teams view which they refer to as an Agile Release Train a.k.a. ART. An ART is based on multiple Scrum or Kanban or whatever Agile teams. On the team level there are Product Owners, Scrum Masters, and Developers. On the ART level there are similar roles called Product Management, Release Train Engineer (RTE), and System Architect/Engineer.
This means that SAFe scales the whole unit of a Scrum team incl. the What accountabilities which are then with Product Management. This results in significant challenges as a Product Owner in SAFe is not the same as a Product Owner in Scrum. The SAFe Product Owner is mostly a person that refines the team level Backlog – which cannot really be called a Product Backlog anymore.
One of the key benefits of SAFe is that organizations tend to have less resistance moving to SAFe than to any other framework – at least this has been my experience. This can be good as it results in organizations taking the first step towards changing. It can also be bad if they believe implementing SAFe is already the destination.
One of the most important things to keep in mind is the closer a scaling approach is similar to your current organizational structure, policies, and metrics, the less it will result in you achieving different results. So implementing SAFe is probably easier than implementing some of the other frameworks, but most likely it will also not bring you much closer to achieving your objectives.
Large Scale Scrum (LeSS)
Large Scale Scrum – also known as LeSS – is another frequently used scaling approach. LeSS was invented by Craig Larman and Bas Vodde. Both of them are very experienced individuals and systems thinkers. Both of them are also very opinionated.
Compared to SAFe, LeSS only scales the How pieces of the Scrum team i.e. the Developers and to some extent the Scrum Master. LeSS in its most simple form does not create a Product Owner hierarchy. This means a LeSS Product Owner is really a Product Owner (in the Scrum sense) and works with multiple teams to accomplish the goals of and for the product.
Based on this definition a Product Owner in LeSS needs very mature teams. Mature in their understanding of the customer, mature in their understanding of how to breakdown Product Backlog Items, and mature in terms of working closely with stakeholders.
Compared to a non-scaled Scrum team where usually a Product Owner does most of Product Backlog Refinement, customer interaction, and stakeholder management, in LeSS there would not be enough time for a single person to do this of all of their teams.
As I am a big football (soccer) fan, I frequently use analogies from the world of football when talking to clients. Implementing LeSS is like playing in the Champions League. This is not something someone should do that has not demonstrated a great Scrum implementation already.
Compared to SAFe, LeSS takes away a lot of the bureaucracy of large organizations and with this many management layers. This feels uncomfortable for many people just looking at it let alone applying it.
A LeSS implementation is not easy and compared to what other frameworks claim, LeSS probably requires the biggest shift in how managers lead and also requires the most focus, energy, and time in developing people. The move from component to feature teams is just one of many examples.
This does not mean that LeSS is bad. If I had to pick one of these frameworks for my organization or for my clients it would probably be LeSS. But LeSS also takes the most commitment from senior leadership and the most time to prepare teams for. It will probably also lead to the most significant results.
For product development initiatives that require more than 8 teams, LeSS has a dedicated configuration called LeSS Huge. The one difference is that now LeSS also scales the Product Owner role. There is still one Product Owner, but for various areas there are so-called Area Product Owners.
Scrum@Scale
Scrum@Scale was invented by Dr. Jeff Sutherland, one of the co-creators of Scrum. Similar to SAFe, Scrum@Scale scales the full unit of a team i.e. the What and the How.
The level above the Scrum Team has a Chief Product Owner and a Scrum of Scrums Master. There is a Product Owner Cycle that results in the Executive Meta Scrum (EMS) and a Scrum Master Cycle that results in the Executive Action Team (EAT).
Similar to LeSS, Scrum@Scale puts a lot of emphasis on decentralization decision making to the teams. Jeff Sutherland himself is big promoter of the Product Owner being in charge of value creation for customers and not just someone that works on a Backlog.
The Scrum@Scale Guide documents quite well how the framework basically works. From time to time it gets a bit cryptic, but the fundamental piece is that Scrum@Scale is a fractal approach to scaling working Scrum Teams. Thus, it should also not be the entry point for any organization. Actually, this can be said about all scaling frameworks.
Nexus
Nexus was created by the other co-creator of Scrum Ken Schwaber. As a framework it seems to be very close to LeSS, although there is one distinct difference being the Nexus Integration Team. Other than that Nexus – similar to LeSS – primarily scales the How accountabilities while keeping one single Product Owner. You can read more on Nexus here.
Disciplined Agile Delivery (DAD)
Disciplined Agile Delivery – also known as DAD – was invented by Scott Ambler and Mark Lines. I am not an expert in DAD and – despite working with many organizations – have never seen it applied in real life. This does not mean that DAD is not being applied and that it does not work, it just means I have not seen it. You can read more about it here.
Spotify Model
This is an interesting one. The main people behind the Spotify Model – one of them is my friend Henrik Kniberg – say there is no Spotify Model. Still, many of the large consultancies sell this to their clients. They talk about Tribes, Squads and Guilds, while most of them (actually all of them) have never set foot into Spotify to see whether and how this “model” works.
The Spotify Model sounds fun and cool, after all Spotify is a fun and cool company. But does this model of a Scandinavian music streaming startup – even if it existed – really fit a German telecommunications company, a Swiss pharma company, or an American insurance? Personally, I highly doubt it.
Fortunately, no one at Spotify claims that this model can be applied universally… they actually don’t even claim that it works within Spotify. If you listen closely to what Henrik outlines in his videos about Spotify’s engineering culture you will hear him say that all of this sounds great, but they still have a ton of issues at Spotify and are continuously improving how they work. So there is not the model at Spotify… there are only snapshots.
How can you scale agile within your organization?
When we work with organizations our aim is to help them understand that while they can take a lot of insights and inspiration from various scaling frameworks, the most important piece is to understand some fundamental principles of scaling agile product development and then constantly evolving the organization towards these principles.
Some of the key principles that we look at are the following:
Do not scale if you don’t have to i.e. before thinking about scaling look at whether you can slice your product in a way that small units can work on them independently which makes scaling irrelevant
Every team and the team-of-teams are setup in a way that they ideally deliver customer value and are customer centric
Apply lean thinking i.e. reduce waste through limiting work-in-progress, rigorous prototyping (discovery), and frequent customer feedback
Continuously improve the way of working through regular and frequent team and cross-team retrospective meetings
Decentralize decision making as much as possible through creating clarity and developing competence within the teams
Embrace uncertainty and create a mindset of empiricism both for What is being built and How things are being built
This list is by no means exhaustive. But if an organization and its leadership team start taking these principles to heart we have seen them tremendously improve the organizational agility incl. customer satisfaction and employee engagement.
What do leaders need to know about scaling agile?
In too many cases have I seen leaders/managers believe that once an organization moves towards agile, they are not needed any longer. This is one of the reasons that many managers resist organizational change initiatives – the fear of losing their status or even their job.
I believe that no organizational change will happen without management both top- and middle-management. These groups are the ones that work on the organization compared to all the others who primarily work in the organization.
The organization itself is like a product. It needs to be developed. And given the fast changing environment for most organizations, it is my firm belief that every organization – similar to most products – is a work in progress i.e. needs to be continuously improved. This is the job of managers/leaders in the organizations.
For most leaders this means that their work significantly changes. For those who have been micromanaging their teams it means empowering and enabling the teams to take more and more decisions. For those that have been directly involved in product decisions it means to decide whether they want to stay in a product focused role or whether they want to move into an organizational development role. In either case, most managers/leaders need to adapt what they do themselves and how they do it i.e. most need to go through a personal agile leader journey.
Based on our experience, it is really helpful to have a model that helps you systematically structure your personal journey and take it step by step with the help of a great coach. If you want to learn more about how this can be done, take a look at our Certified Agile Leadership offerings.