Having already been in the Article on scaling agility have made an initial assessment with experts for agile frameworks and also in the Dialogue with Boris Gloger the frameworks have been criticized, I set out to collect the frameworks and describe them. In the following you will find an overview of methods that deal with the question: How can you actually scale Scrum?
Scaling Scrum with frameworks
Scrum is widely used among agile development frameworks. The challenge here: Scrum is based on the work of a small team and does not initially provide any solutions for use in a large organization with a large number of teams. As a result of this need, various approaches to scaling agile procedures have emerged in recent years. In the following you will find an overview of the relevant frameworks, as well as an assessment of the measures and costs. To make the assessment easier, I have taken each employee at a cost of 100 euros per hour. So it’s like buying every employee in as a freelancer. Each framework tries in its own way to find an answer to the question: “How can you scale Scrum”. In the end, I had dialogues with agile coaches and Boris Gloger in order to be able to say how Scrum can be scaled.
Scaling 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 shows from our experience that basically one Scrum of Scrums level should be formed per 6 teams, as shown in the figure.
Scrum of Scrums sounds simple, but this approach is much more than a simple division of teams, as experience has shown that work can often be redundant and a holistic view of the project is not guaranteed. A best practice is to hold the team meetings at different times in order to enable each team to assess the work of the other teams and then to discuss the whole project in a meeting of all teams (Scrum of Scrums). Here, for example, all Scrum Masters exchange information on the cross-team processes. This team also has a Scrum Master, the Scrum Master. Independently of this, it is also advisable to hold the dailies offset so that each team can visit the other’s daily and thus receive information from other teams. In the subsequent Scrum of Scrums, the cross-team problems are discussed.
Overall, Scrum of Scrums is a good approach to easily scaling Scrum. One point of criticism is that the strengths of a Scrum of Scrums lie mainly in the exchange and coordination between teams and less in overarching planning. A Scrum of Scrums is not a planning process in the actual sense, but a constant exchange. If a consolidated plan is required, this must be drawn up separately. My experience shows that this lightweight concept works for up to 6 teams, but with more teams it slips into a too high level of abstraction (scrum of scrums of scrums of scrums). This results in little effort for the introduction, but a high risk that it leads to problems when scaling with more than 6 teams.
Overall, Scrum of Scrums requires the following measures: Formation of a coordination team and coaching of these Scrum Master teams. 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 a few additional meetings here. If there are more Scrum levels, i.e. Scrum of Scrums of Scrums, additional full-time scrum masters are required to coordinate these teams. With 6 teams, Scrum of Scrums causes additional work for one team. At an hourly rate of 100 euros, that would cost 128,000 euros per 6 teams (8 people) and 384,000 euros for 12 teams (2 Scrum of Scrums of Scrums Team + one additional level). The effort increases extremely sharply with more than 6 teams and is therefore only in a healthy ratio in the cost / benefit ratio with a maximum of 6 teams. For further information, please also note this Book by Gloger .
Scaling Scrum with SAFe – Scaled Agile Framework
The Scaled Agile Framework (SAFe) can be defined as a complex framework, which has its particular strength in the embedding of Scrum in classic company areas. This framework becomes complex because it has many roles, processes and practices. The core of SAFe is the stable organizational structure. Overall, the considerations are based on Toyota’s Lean House (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 on the basis of XP practices with a size of five to nine members, a product owner and a scrum master.
SAFe brings together teams at the program level in the so-called Agile Release Trains (ART). Five to ten teams (approx. 50-125 members) work together in a train and work on the challenges of a so-called program.
The last 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 entails a large number of specific solutions from the management level and a high level of effort for the introduction. However, it can coordinate a large number of teams and master even very large releases with the release trains without any problems. For a small number of teams, however, I would advise against a heavyweight framework like SAFe. This results in a high expenditure of time for the introduction due to the high level of complexity. The introduction of SAFe is usually worthwhile with a long-term implementation throughout the organization.
In order to implement the SAFe framework, far-reaching measures are necessary. While there are hardly any costs at the team level, committees and special teams must be formed for the release train at the program level. In addition, metrics for measuring the team level and the release train would have to be defined as well as another team for integrating the product. Further committees and the introduction of Kanban teams are necessary at the portfolio level. These are just a few of the steps you need to take. It quickly turns out that massive change management is necessary and that with 12 teams this effort is distributed over an additional release team, a portfolio team, 1 program team and an extra committee as well as 2 change management teams and massive design effort. These teams alone would cost more than 500,000 euros (with a team of experts at 100 euros per hour) without including the necessary effort in the conception. For this reason, the framework for 12 teams has no cost / benefit ratio, as there will be an incalculable amount of change costs. As you can read on many websites, however, the framework is worthwhile for a high number (50-100) of teams. Here it goes to Framework homepage . See this for more information Book of Leffingwell.
Scaling Scrum with LeSS – Large Scale Scrum
The basic idea of Large Scale Scrum is to adhere to sprint cycles and to carry out important Scrum events, such as Sprint Planning One and the Sprint Review, together. Each team has its own restrospective, but there is also a common retrospective for all teams. For horizontal coordination, there are joint product backlog refinements and inter-team coordination (e.g. Scrum of Scrums). The standard framework for up to 8 teams defines only one product owner, who should keep the overview. The Hugh LeSS framework was designed for further scaling. This also includes Area Product Owners who report to the Main Product Owner.
LeSS thus defines a simple procedure, hardly deviating from Scrum, and a scalable structure. The focus on a hierarchy of Chief Product Owner, Area Product Owner and Product Owner at team level also supports more than 8 teams without any problems. The Scrum of Scrums approach is expanded with the hierarchical structure of the Product Owner and thus provides a quick introduction for up to 16 teams, in my experience, relatively problem-free.
The measures for the implementation 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 with 12 teams, 4 additional product owners and one product owner with overall responsibility are required. This means that costs of 80,000 euros for the product owner and 128,000 euros for the additional team are necessary. Here is the Homepage of LeSS . See the book by for more information Vodde and Larman.
Scaling Scrum with Nexus, DAD, …
Overall, in addition to the frameworks mentioned, there are other frameworks such as Ken Schwaber’s Nexus and the disciplined agile delivery from IBM. Nexus is basically only to be understood as a guideline or open framework and the framework from IBM only as a collection of best practices. For this reason these are neglected. See this for more information Book from IBM.
[yop_poll id=”20″]
And which one do I take now? How can I scale Scrum?
In the course of researching agility, I looked at these scaling frameworks in detail and was amazed that I rarely see them in use – companies hardly seem to scale Scrum with them. I then evaluated the frameworks together with agile coaches and came to a surprising result: Actually, these frameworks were described by the coaches as pure marketing frameworks. People would be pushed into a framework and the actual freedom that Scrum had to offer was no longer given. For this reason, according to the coaches, the introduction of such frameworks was often canceled halfway and new solutions and approaches were sought. Also Boris Gloger got me into a dialogue said the following:
[werbung] [fotolia]In my work, I have repeatedly made the experience that large-scale projects managed according to agile principles lead to significantly better results. However, there is more to Scrum than just a few principles. It has thus been found that agile frameworks such as SAFe®, LeSS and Co. are very complicated. However, Scrum should be simple and take just a few steps (Boris Gloger).
