Scaling Agile Methodology is becoming the holy grail of agile project management, because many big corporations already bought the idea of agile these days. But how do you scale agile methodology for those larger organizations? If you do a bit research, you will find, that there are basically three answers to that question: LeSS, Nexus and SAFe. But can these frameworks really meet the expectations of managers, when they are dreaming of an agile “speedboat”? Lets have a look at those frameworks.
Scaling Agile with LeSS
If you want to run a LeSS project, you basically just allow your product owner (PO) to work for many Scrum Teams. That might work but could easily lead to a problem. Because in a regular Scrum Team, the product owner is a fulltime role that is often quite occupied. Being part of more than one team will then be a challenging job. It becomes easier for the PO if each team is working on similar topics. But the closer the teams’ areas are getting, the harder it will become to coordinate between the teams. Under these circumstances, dependencies between teams will raise. Those dependencies are contradicting the attributes of a Scrum Team as described in the Scrum Guide.
Another alternative, LeSS Huge, allows for a Product Owner Team with one PO and several Area Product Owners (APO). I found that to be a popular setting in many companies. But the Scrum Guide explicitly states: “The Product Owner is one person, not a committee”. And that is for a reason. A group of POs usually leads to complicated distributions of responsibility and wasteful alignment effort. So Scaling Agile with LeSS can work, but will cause in the best case a lot of communication overhead.
Scaling Agile with Nexus
The Nexus integration team is a new role that is essential within the Nexus framework. This team is accountable for ensuring an integrated increment after each sprint. This team is organized like a regular Scrum Team. Its increment is the integrated increments of other Scrum Teams. It is inherent to this organization, that the increments of the single Scrum Teams must then be not-integrated parts of the product, e.g. components. Obviously, those teams must then be component teams. But when we design agile working models, we usually try to avoid that and build feature teams instead. Because component teams again create dependencies, that need to be managed. Also, they do not create increments in a “usable condition” as described in the Scrum Guide. So Scaling Agile with Nexus might work in a similar way as LeSS, but also does not meet the expectations we have for a single Scrum Team.
Scaling Agile with SAFe
SAFe is an extensive framework that includes a lot of tools to manage a large organization on every level. It is like a complete cooking guide on how to be an agile organization. But this implies the assumption, that scaling agile is a complicated problem, that can be solved through a best practice. But isn’t it a complex problem instead, that should be solved in an empirical way? Also, the process of implementing SAFe requires a team of certified Consultants who have gone through an intense certification program and paid a lot of money for it. (It really is intense. I went through it). How does that comply with the principle of simplicity in the agile manifesto? The Agile Manifesto also believes in emergent design from self-organizing teams. How does that comply with a complete guide for organizations? Using SAFe is like cooking with Thermomix. You probably will be successful to cook a meal. But would you serve a Thermomix meal to paying customers in a restaurant? You probably will be faster than traditional organizations. But is this form of agile administration really the speedboat you were dreaming of?
How to solve your scaling issue
So, if agile methods are so hard to scale, how do you solve your scaling issue then? The answer is simple, but hard to implement: Do not scale agile. Instead, descale your organization. That means, breaking apart your big tanker into small, independent teams. Leave out all the wasteful reportings, controlling, etc. as much as you can
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Antoine de Saint-Exupery
There are two ways to achieve this kind of independency in your teams:
- You carve them out of your organization like a spin-off and cut all the (dotted) lines to the team. This will allow them to operate fully independent in a small setting. Do not underestimate the business impact, that such a team can achieve! You do not always need a large group of people to generate high impact.
- You completely transform (part of) your organization into a new kind of management system. A popular alternative to traditional organizations is, for example, the Holacracy system.
However, before you even think about scaling your agile project, you might want to get the basics right. To put it differently: if you scale a shitty process, you will end up having a scaled shitty process. Therefore, read my article about “The ugly truth about why you fail with your agile team” and go fix that issue first before considering scaling agile.
Key Takeaways
- There is no magic pill to scale agile without drawbacks
- “Scaled Agile” sometimes just is another form of corporate organization
- Think about descaling your organization instead of scaling agile
- Take away waste instead of adding structure, to cope with scalability
