Having already made an initial assessment with experts on agile frameworks in the article on the scaling of agility and also criticized the frameworks in dialogue with Boris Gloger, I set out to gather the frameworks and describe them. So here’s an overview of methods that address the question: How to scale Scrum?
Scaling Scrum with Frameworks
Scrum is widely used among agile development frameworks. The challenge: Scrum is based on the work of a small team and initially does not provide solutions for use in a large organization with a large number of teams. In recent years, various approaches to scaling agile approach have emerged from this need. The following is an overview of relevant frameworks, as well as an assessment of the measures and costs. For a simpler evaluation, I took every employee at a cost of 100 euros per hour. So it’s like you’re shopping for every employee as a freelancer. Each framework tries to find an answer to the question “How to scale scrum” in its own way. In the end, I had dialogues with agile coaches and Boris Gloger to say how scrum can be scaled.
Scale Scrum with Scrum of the Scrums
The simplest approach to scaling Scrum is Scrum of Scrums. Imagine a project with six teams. Each team, in turn, consists of 8 team members. All teams hold their own Daily Scrum Meeting. Thus, another scrum team, consisting of the scrum master of the first team, is formed. Experience has shown from our experience that a fundamental scrum of scrum level per 6 teams should be formed, as shown in the figure.
Scrum of Scrums sounds simple, but this approach is much more than a simple division of teams, as experience shows that work can often be redundant and does not ensure a holistic view of the project. A best-practice is to hold the team meetings in a time-shifted way to allow each team to review the work of the other teams and then discuss the whole project in a meeting of all teams (Scrum of Scrums). Here, for example, all Scrum Masters exchange information about the cross-team processes. This team also has a Scrum Master of the Scrum Master. Separately, it’s also a good thing to hold the Dailys so that each team can visit each other’s daily and get information from other teams. The subsequent Scrum of Scrums discusses the cross-team issues.
Overall, Scrum of Scrums is a good approach to lightweight scaling of scrums. One criticism is that the strengths of a scrum of scrum lie mainly in the exchange and coordination between teams and less in overarching planning. A scrum of scrum is not a planning process in the true sense of the word, but a constant exchange. If a consolidated plan is required, it must be drawn up separately. My experience shows that this lightweight concept works well for up to 6 teams, but with more teams it slips to too high an abstraction level (scrum of scrums of scrums of scrums of scrums). This results in little effort for the introduction, but a high risk that it will lead to problems with scaling with more than 6 teams.
Overall, Scrum of Scrums requires the following measures: formation of coordination team and coaching of these teams of the Scrum Masters. This causes different transaction costs depending on the size. However, these costs are quite low in relation to the effort up to 6 teams, as each Scrum Master has to hold some additional meetings here. With more scrum levels, i.e. Scrum of Scrums of Scrums, more full-time crummasters are needed to coordinate these teams. Thus, Scrum of Scrums in 6 teams causes an extra effort from one team. At 100 euros per hour, that would cost 128,000 euros per 6 teams (8 people) and 12 teams 384,000 euros (2 scrums of scrums of scrums team + another level). The effort increases extremely strongly with more than 6 teams and is therefore still in a healthy ratio in terms of cost/benefit ratio only with a maximum of 6 teams. For more information, please refer to the book of Gloger.
Scaling Scrum with SAFe – Scaled Agile Framework
The Scaled Agile Framework (SAFe) can be defined as a complex framework that has its particular strength in embedding scrum in classic business areas. This framework becomes complex because it has many roles, processes and practices. The core of SAFe is the stable organizational structure. Ingsesamt bases the considerations on the Lean House of Toyota (Respect, Flow, Kaizen). The framework itself is divided into team, program and portfolio level. The teams organize themselves “almost as usual” according to a slightly modified scrum based on XP practices ranging in size from five to nine members, a product owner and a scrum master.
SAFe summarizes teams at the program level in the so-called Agile Release Trains (ART). Five to ten teams (approx. 50-125 members) work together in one train and work on the challenges of a so-called program.
The final level is the portfolio level, which provides the programs with budget and targets (epics) based on considerations of corporate strategy and investment intentions. A distinction is made between Business Epics (customer-oriented) and Enabler Epics (technical solutions).
SAFe is not suitable for small and medium-sized projects. It involves a large number of concrete solutions from the management level and a high effort for the implementation. However, it can coordinate a large number of teams and master even very large releases without problems with the release trains. For a small number of teams, however, I would advise against a heavyweight framework like SAFe. This results in a high time-consuming introduction due to the high complexity. The introduction of SAFe is usually worthwhile with long-term implementation throughout the organization.
In order to implement the SAFe framework, far-reaching measures are needed. While there are hardly any costs at the team level, the Level program requires the formation of committees and special teams for the release train. In addition, metrics would need to be set to measure the team level and release train, as well as another team to integrate the product. In the portfolio level, further committees as well as the introduction of Kanban teams are necessary. These are just some of the necessary measures. It quickly turns out that massive change management is needed and that this effort with 12 teams is probably spread over an additional release team, a portfolio team as well as 1 program team and an extra panel as well as 2 change management teams and massive design effort. These teams alone would incur costs of more than 500,000 euros (for a team of experts with 100 euros per hour) without any necessary effort to take into account in the conception. For this reason, the framework for 12 teams is not in any cost-benefit ratio, as an unestimated amount of change costs will be added. However, as you can read on many websites, the framework is worth it with a large number (50-100) of teams. Click here to go to the homepage of the framework. For more information, check out Leffingwell’s book.
Scale Scrum with LeSS – Large Scale Scrum
The basic idea of the Large Scale Scrum is to adhere to sprint cycles and to conduct important scrum events, such as Sprint Planning One and Sprint Review together. Each team has its own restrospective, but there is also a joint retrospective of all teams. For horizontal coordination there are common product backlog refinements and an inter-team coordination (e.g. scrum of scrums). The standard framework for up to 8 teams defines only one product owner to keep the overall overview. The Hugh LeSS framework was designed for further scaling. This also includes Area Product Owner, which reports to the Main Product Owner.
LeSS thus defines a simple, hardly deviating approach from Scrum and a scalable structure. The focus on a hierarchy of Chief Product Owner, Area Product Owner and Team Level Product Owner also supports more than 8 teams without any problems. The Scrum of Scrums approach is enhanced with the hierakh structure of the product owners and thus provides a quick introduction for up to 16 teams, in my experience, relatively easily.
The measures for the implemetization of hugh LeSS are the establishment of the joint sprint teams as well as a team that supports the integration at the end of the sprint – additional product owners are also necessary for the implementation. Experience has shown that 12 teams require 4 additional product owners and a total responsible product owner. This means that costs of 80,000 euros are required for the product owners and 128,000 euros for the additional team. Click here to go to the homepage of LeSS. For more information, see the book of Vodde and Larman.
Scrum Scale with Nexus, DAD, …
In addition to the above-mentioned frameworks, there are other frameworks such as Ken Schwaber’s Nexus and the disciplined agile delivery from IBM. Nexus is fundamentally only to be understood as a guideline or open framework, and the IBM framework is only a collection of best practices. For this reason, they are neglected. See IBM’s book for more information.
And which one do I take now? How can I scale Scrum?
In the course of research on agility, I have studied these scaling frameworks in detail and wondered how they are rarely used – companies hardly seem to scale Scrum with it. I then evaluated the frameworks together with agile coaches and came to a surprising conclusion: Actually, these frameworks were described by the coaches as pure marketing frameworks. People would be pushed into a framework, and the real freedom that Scrum must offer was no longer given. For this reason, according to the coaches, the introduction of such frameworks was often aborted halfway through and new solutions and approaches were sought. Boris Gloger also told me in a dialogue the following:
Genderhinweis: Ich habe zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen, Diverse als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.
In my work, I have always experienced that large-scale projects managed according to agile principles lead to significantly better results. Behind Scrum, however, there are more than a few principles. Thus, it turned out that agile frameworks such as SAFe®, LeSS and Co. are very complicated. However, Scrum should be simple and get along with a few steps (Boris Gloger).
Falls es noch Fragen gibt, können Sie mich gerne anrufen. Hierzu einfach im Buchungssystem nach einen freien Termin schauen. Ich nehme mir jeden Monat einige Stunden Zeit um mit Lesern zu interagieren.
Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mirSie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne! Sie können dadurch Kunden und Fachkräfte ansprechen.
Ich suche aktuell außerdem Werbepartner für Bannerwerbung für meinen Blog. Sollte es für Sie spannend sein Fachkräfte oder Kunden auf Ihre Seite zu leiten, dann bekommen Sie mehr Informationen hier.
Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?
Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:
- Halten von Vorträgen zu Arbeit, Führung und Agilität
- Unterstützung Ihres Marketings (z.B Blogartikel)