1 Introduction

The rising popularity of agile software development is based on many benefits like managing changing priorities, increasing time to market or team moral [1]. Agile is composed of values, principles, and methods. Scrum [2] is the most used agile method across all organization types and sizes [1]. All these methods base on different Agile Practices, like Daily Stand-Up or Sprint [2]. However, Scrum and all other Agile Methods are not sufficient to achieve the desired benefits of all kinds of organizations regarding agile development. Especially for big projects or organizations, Agile Methods are not sufficient, since they were designed for small teams only. However, organizations with big teams also want to develop Agile. Therefore, several so-called Scaling Agile Frameworks increasingly came up in the last six years. The most famous ones according to [1] are the Scaled Agile Framework (SAFe) [3] and Scrum-of-Scrums [4]. For those commonly used frameworks, some experience reports and studies exist, especially for SAFe [4,5,6]. However, also less known ones like FAST Agile Scaled Technology (FAST) [7] or Recipes for Agile Governance (RAGE) [8] exist. Scaling frameworks are based on practices on the technological and managerial level. These practices form the foundation for the implementation of all frameworks. Only [9] conducted a comparison on practice level so far and identified eight common scaling practices by comparing LeSS and SAFe. If Scaling Agile Frameworks were compared directly in related work, the comparison was along characteristics of the frameworks [10,11,12]. [13] compared eight Scaling Agile Frameworks on how IT governance is covered. In this work, we aim to identify the commonalities of Scaling Agile Frameworks concerning their defined practices. We used the twelve Scaling Agile Frameworks from [12] and updated the visualization [12]. To be able to conduct a comparison on practice level, we first extracted and consolidated all practices from these twelve Scaling Agile Frameworks.

2 Overview Over Practices

We went through the descriptions of each practice given by the frameworks. Based on these descriptions, we divided the practices into three groups: (1) practices that are only used on team level (cf. Table 1 that only displays the Scrum practices), (2) practices that are only used to scale agile (c.f. Table 2), and (3) practices that can be used for both – scaling agile and on team level (c.f. Table 3). Based on this classification, we created three different tables that provide an overview of the categories, subcategories, and related practices. Scaling Agile frameworks do not only define scaling practices, but also demand practices on team level. These coordination mechanisms for each team help to better align multiple teams. Table 1 only shows the Scrum practices, since they also appear in the Subway Map. Scrum is the most commonly used method [1]. It describes the management practices without prescribing technical practices [14]. Most scaling frameworks base on Scrum on team level.

Table 1. Scrum practices used on team level
Full size table
Table 2. Scaling practices
Full size table
Table 3. Practices for both scaled and team level
Full size table

On a scaled level (cf. Table  2 ), many practices on team level are adapted on a scaled level. Team level practices like the Scrum events were adapted for a scaled environment, e.g. by changing the participants of the events. Many frameworks also demand team level mechanisms, such as a Kanban board, Burn Charts or Release Planning activities, to be used in scaled projects. In addition, dedicated scaling practices like the Architecture Release Train from SAFe help to align the work of teams.

With Table 3, we show that there are also practices that are demanded on team level, but are also demanded under scaling conditions. This does not necessarily mean that the same framework demands a practice in both environments; it could also be that one framework uses the practice on team level, whereas another framework uses the practice as a scaling mechanism. General concepts like Time Boxing, Estimation or Open Source can be used by a single team as well as by multiple teams. User Stories help to describe the functionality of a product, independent of how many teams are responsible for this product. Communities of Practice are independent from projects. There are also practices that gain importance in a scaled environment, like Architecture or Release Activities. A focus on such topics is essential due to the increased coordination effort of multiple teams and the complexity of larger products. Likewise, Strategic Activities that can also already be applied on team level, support alignment of teams and reduce risk related to larger complex products.

3 Comparison of Frameworks

We extended our “Subway Map” inspired visualization (similar to [15]) from [12] to show (1) which framework contains which practices as well as (2) which common practices are shared by multiple frameworks (cf. Figure 1). In the Subway Map (cf. Figure 1), each line represents a Scaling Agile Framework. The single subway stations illustrate the single practices that appear in those Scaling Agile Frameworks. We wanted the comparison to be easy to understand and visible at a glance. For the sake of simplicity, some subway stations represent only categories instead of single practices. The big stations symbolize practices that are used by many frameworks, e.g. Daily Stand-Up or Product Backlog.

Fig. 1.
figure 1

Subway map visualizing practices of Scaling Agile Frameworks

Full size image

The Subway Map shows that some frameworks share common Scaling Practices like the scaled form of the Scrum practices, namely: Scaled (Sprint) Goal, Scaled Retrospective, Scaled Planning, Scaled Review, Scrum of Scrums, and Scaled Backlog. Whereas, some more individual practices only occur in few frameworks, such as, Release Review, Program-/Portfolio Kanban Board, Agile Release Train, Beta Codex, and Architectural Runway. On a closer inspection, it can be seen that most of the widespread practices are based on Scrum. This can be explained by the fact that Scrum contains management practices that mainly serve to organize the process around the software development in a lightweight manner.

Technical practices like Pair Programming are rather seldom part of scaling frameworks, since they often do not scale beyond software development on team level. Furthermore, it can be seen that all Scaling Agile Frameworks include scaling practices, but also non-scaling practices, namely practices on team level. Table 4 lists the practices across the frameworks ordered by occurrence. With the help of Table 4 and our visualization, it also can be seen that the Scrum practices, which are only used on team level, are still applied by almost every framework. This obvious commonality across the frameworks was the reason to include the Scrum practices in the visualization, though they are team level practices. Sprints and sprint planning are the practices recommended by almost all frameworks.

Table 4. Practices and their occurrence over frameworks
Full size table

4 Implications

If practitioners have to decide on a suitable Scaling Agile Framework, they first need to know what frameworks exist. With the list of frameworks that are considered in our comparison, practitioners understand that there are more possibilities than the well-known frameworks that are typically presented by consultants. To identify the most suitable framework, we already presented a comparison of those frameworks in previous work [12] that compares criteria like the purpose, advantages or context of those frameworks. With an initial selection of a suitable framework, it can then be extended or adapted to the specific needs, leading to an individual approach.

When designing a scaling approach, practitioners might want to check for coverage of the suggested categories of practices (cf. Tables 1, 2 and 3). The practices from those categories might be important to consider since the authors of those scaling frameworks considered them. The Subway Map provides an overview over the existing Scaling Agile Frameworks, and shows the corresponding scaling practices. It can be seen that some frameworks are rather similar, sharing many practices, while others are rather individual and provide many practices that are not covered in other frameworks. We recommend considering the most commonly used practices (cf. Table 4) first, in order to implement the best practices of multiple frameworks. In addition, the individual practices can be evaluated to complement the base framework. Our comparison of frameworks shows that many frameworks are based on Scrum on team level. Practitioners that want to scale up their agile development should first consider their implementation of team level practices that support scaled agile development.

The categorization of scaling practices and the Subway map need to be validated by the respective framework experts. Due to lack of documentation, there is the risk that wrong categorizations were made or practices from frameworks are missing. Since we did not conduct a systematic literature review, it might be that some frameworks or some of their practices are missing. For the sake of simplicity of the categorization, sometimes practices were clustered without considering the detailed differences. The stations of the Subway map have different abstraction levels, since some stations are based on practices, others on categories.

5 Conclusion

Due to the need to adapt Agile beyond the context Agile methods were initially designed for, many frameworks to scale agile have been developed in recent years. In order to understand similarities between the frameworks, we extracted a list of their underlying practices. A visualization provides a high-level overview over Scaling Agile Frameworks and enables comparison of the frameworks concerning the use of their underlying practices. Additionally, practices common to many frameworks are identified. We discuss how the results help practitioners to build their individual scaling framework. Feedback from framework authors is needed before proceeding with an in-depth analysis and comparison of the similarities and differences of the considered frameworks.