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.
