For a long time, I have been working with agile approaches and in particular with scaled approaches such as LeSS (Large-Scale Scrum). The most exciting questions here are up to what organizational size these approaches reach and how best to get started with an agile transformation. These questions are closely related, because in my experience, a transformation towards agile product development is often initiated "from above", but is usually started as a very small plant in the development department. There are voices that see a complete transformation of an organization in one go, as a quick and yet sustainable way to carry out a restructuring. In my opinion, this massively fails to recognise that an agile approach is much more than new titles, new roles and new processes. Above all, it is a mindset and this cannot be "implemented" sustainably in a hurry. Starting with a single product, identifying it in the first place and empowering a team to further develop this one product is already a big task and requires time and sensitivity in establishing it within an established organizational structure. Flanked by measures in the environment of this first product development unit or its embedding in the overall organizational context, is a necessary stabilization measure that is still pending long before any scaling.
So what does it actually mean to choose a "scaled agile approach"? There are at least two very different measures that are meant:
1. Deploy multiple product development teams to further develop one product
2. To make the entire organization, not just the development units, work in an agile or at least more agile way.
For the former, there are various standard frameworks, such as LeSS (Large-Scale Scrum), Nexus or Scrum@Scale, to name just a few celebrities. None of them really caught on. Rather, unfortunately, companies usually use curious hybrid forms of these approaches and classic Scrum, often spiced with a breeze of Kanban and with a little waterfall here and there. I attribute this to the fact that, on the one hand, none of these frameworks are easy to implement and, on the other hand, scaling is started when teams already have a few months or years of agile experience and attach particular importance to being self-organized and self-responsible and therefore also see themselves in a position to pick individual components from the scaled agile portfolio. This can be done, but unfortunately often happens in a supposedly mature environment and therefore often without the support of appropriate specialists in the form of a Scrum Master or Agile Coach. In the medium term, the latter then leads to bizarre stylistic flourishes and not a real agile approach. Unfortunately, what remains is the false impression that scaling within the development department cannot be successfully implemented.
The second form of scaling refers to the entire organizational structure, i.e. the attempt to transform an entire company into an agile approach. Unfortunately, the latter usually happens completely detached from agile product thinking, i.e. the heart and soul of agile approaches. It often comes in the form of SAFe and is trained and implemented by legions of agile coaches. On paper, SAFe is a great success story, as you earn tons of money from the implementation of this framework, and financial success makes you sexy. It is doubtful how seriously and sustainably a company is actually agile after switching to SAFe. A renaming of planning meetings and the awarding of "agile titles" alone is more of a cargo cult than a real change in mindset.
I'd like to talk about scaling in the first category and draw attention to a new approach that I just recently stumbled upon. It is called "Team Topologies" and is described in the book of the same name by Matthew Skelton and Manuel Pais. The starting point for this is Conway's Law, which states that when organizations design a system, they will choose a design that is a copy of the communication structures within the organization. Accordingly, the authors conclude that the organizational structure must already be chosen according to the desired end result. Another key argument of her remarks is that the complexity of a system is growing and the cognitive abilities of each individual, each team and the entire organizational structure are increasingly challenged. Accordingly, it is crucial to take this cognitive load and its management into account in the organizational structure. The goal is to identify areas of responsibility that can be clearly separated and that can be worked on independently. Identifying the relatively independent units required for this and deriving a system and sub-system from them that holds together, is coherent, contains clear boundaries and, on the other hand, maintains loose couplings between some units is called the "Reverse Conway Maneuver" and "Team Topologies" describes what this maneuver looks like in practice and can be implemented.
The book argues that there are only four fundamental types of teams that can work together in three different ways:
1. "Stream-Aligned Teams": something like an agile team, such as a Scrum team
2. "Enabling teams": a team of specialists, technical or product domain, who have the necessary resources to conduct research, evaluate tools, explore and propose technical approaches. In other words, it helps stream-aligned teams to make better, more well-founded decisions for implementation.
3. "Complicated Sub-System Teams": a team responsible for the implementation of a complicated sub-system within a product. Expert knowledge is required for this implementation and cannot be implemented within a stream-aligned team in terms of cognitive utilization.
4. "Platform Teams": a team that develops and delivers internal services for the purpose of reducing the cognitive load of stream-aligned teams. This involves digital services such as self-service APIs, support and the operation of the corresponding infrastructure for these services.
Here's an illustration from the book about these four fundamental team types and how they work together:
To put it simply, "Team Topologies" describes that it is crucial, in the agile sense, that the stream-aligned teams have product responsibility and act in a self-organized manner. In the context of scaling, however, areas of responsibility can be identified that make it sensible to set up one or more of the three other "support teams" in order to bring about a significant relief for the stream-aligned teams.
If I have now whetted appetite for this topic, I can recommend the following lecture on YouTube, which sheds light on the topic in much more detail than I was able to do here in a short time: Adaptive Organizational Design with Team Topologies (youtube.com)
Furthermore, the book recommendation: