Experience Report

What we learned from descaling 25 Scrum teams

About this Publication

What happens when you descale? We learned that some additional roles and events are needed to address cross-team and cross-organizational alignment and prioritization, when our organization went from a ‘Spotify-inspired” setup to a descaled setup with 25 stand-alone autonomous Scrum teams. These new roles and events have effectively proved capable of handling constantly changing dependencies between our 25 teams. However, based on our experience with descaling, we would still recommend adopting a more formal scaling model when a group of teams needs to coordinate closely for an extended period.

1.      INTRODUCTION

Any attempt to scale Scrum will struggle with how to strike the right balance between staying true to the values and rules of the Scrum framework and adding additional roles, events, and rules to ensure efficient coordination between teams and between teams and stakeholders. Adding too many structures may impede or even prohibit the organization from reaping the benefits offered by the Scrum framework. On the other hand, too little structure may lead to a lack of coordination in general, frustrating everyone and reducing value creation. So, what is the right balance? What is the minimal viable bureaucracy?

In this report, we will describe how Alm Brand[1]; a Danish financial institution went from a scaled setup with 9 Scrum teams divided into two Tribes in a Spotify-inspired setup [Kniberg and Ivarsson 2012] to a descaled setup with 25 stand-alone autonomous Scrum teams. We will tell the story from our perspective as Agile Coaches in Alm Brand.

We will describe what we gained, what we lost by descaling in terms of organizational agility, and what new scaling structures we introduced to compensate for the lack of cross-team and cross-organizational alignment, coordination, and prioritization that emerged because of descaling – and most importantly, what we (the authors[2]) learned as Agile Coaches (ACs).

2.      Background

Alm Brand was founded in 1792, by royal decree to provide fire insurances for ’ordinary’ people. Over the years, more products were added to the product portfolio including banking, leasing, and pension. In the following years different Agile methodologies were gradually introduced by us, including a light SAFe implementation.

In 2019 Kristian Hjort-Madsen joined Alm Brand as EVP[3] for Business Development and Digitization (BD&D). Our new EVP had mixed experiences with SAFe from two other financial institutions and wanted a more flexible and nimbler Scrum-based framework focused on business outcomes.

Hence, SAFe was abandoned and a group of Agile coaches was formed, including us, to implement a custom Agile setup using the Spotify terminology as described by Kniberg and Ivarsson. The setup would be based on Scrum teams and outcome focus would be ensured by combining Product Strategy, Lean Startup, Design Thinking, and Agile following “Agile Planning Circles” [Raaschou 2019a&b]. The new setup was called FAST>>[4] and our team was named the Fast-Team.

Initially, two Tribes were launched with 4 and 5 Scrum teams, respectively. In this setup, we had the three Scrum roles plus the Chapter Lead and the Tribe Lead roles. One Tribe Lead for each Tribe acting as Chief Product Owner for the Tribe. Team members were organized into Chapters based on skills and each Chapter was headed by a Chapter Lead being the people manager for all Chapter members (see figure) below. We implemented two other concepts: Teams were called Squads[5] and groups that had common professional interests formed Guilds[6] to share knowledge and improve ways of working.

spotify setup

Figure 1: Spotify setup

No scaling was introduced on the process side, though each Tribe was initially supported by a dedicated AC. Our team of Agile coaches focused on supporting the two Tribes, and the POs and SMs within. The Tribe Leads, Chapter Leads, Management, and (later) the Delivery Leads were to a large degree left to define their own roles.

3.      Descaling

After a year of running our Spotify setup, the Fast-Team was generally pleased with our Agile setup. Yes, people were still in the process of getting the hang of Agile and their new roles, but in general, Squads were progressing and maturing. Yet one role seemed hard to get right: the role of the Tribe Lead. Though defined in Alm Brand as being responsible for the overall value creation of their Tribe (i.e., being a Chief Product Owner), the Tribe Leads, as well as the organization around them, seemed to be struggling to understand, develop, and interact with the role. It seems in retrospect, that it was unclear whether the Tribe Lead should be a know-it-all line manager, a Product Manager/Chief PO focused on maximizing value creation, a people manager involved with the well-being of people within the Squads, or if they should get involved with impediment removal and Agile ways of working.

In 2020, Alm Brand entered a strategic partnership with a major importer of German cars. For the partnership to be successful significant changes to existing IT systems and business processes throughout the organization were needed. Additionally, it was required to coordinate tightly with a non-agile external partner and integrate with partner IT systems delivered by a third-party supplier. The majority of the development effort of this Initiative[7] was expected to run for roughly 6 months. This presented us and the rest of the Fast-Team with the following questions: How to effectively execute the Initiative within our existing setup and who should manage the complex stakeholder landscape?

Two options seemed apparent at the time:

  • Execute within the existing Tribe structure.
  • Create a new Tribe centered around a partner value stream headed by a new Tribe Lead, who would engage in stakeholder management and coordination with the partner and business units.

Both options had some significant drawbacks: Creating a new Tribe with dedicated cross-functional Squads would require considerable reshuffling of team members in the existing Squads. The challenge was that these existing Squads had just started to gel and if we decided to move some team members from these Squads to a new Tribe then the existing Squads could end up as no longer being cross-functional. Since the Squads within the Tribes did not have a shared backlog and since Squads were already working almost independently of each other, the Fast-Team and senior management decided on a third option: Simply to descale by abandoning the Tribe structure altogether and make the POs entirely responsible for prioritization and stakeholder management. However, we still needed someone to take care of the complex tasks of coordination and stakeholder management of the partner Initiative, so we introduced the temporary role of the Delivery Lead [Schuyt 2020b].

A senior Project Manager was assigned to the role of Delivery Lead (DL) for the Initiative, supported by two ACs facilitating and guiding how to best interact with the Agile Squads. Minor adjustments to the Squads were needed to address obvious bottlenecks, so we facilitated a self-selection workshop. This process took one day only (and a couple of weeks to finalize), and then the development of the Initiative began.

Though not all deadlines were met, and some frustrations appeared along the way, in our experience the DL role served its purpose. However, some people did miss the Tribe setup, some POs complained that they were missing the Tribe Lead as an escalation point, and others were missing the sense of belonging to a Tribe both socially and professionally. Other frustrations were related to a shift in focus from value creation to predictability, which was a consequence of the many dependencies associated with the partner Initiative. However, to us in the Fast-Team, this descaled setup of autonomous Squads and the occasional use of a DL for larger Initiatives seemed to be a viable descaled setup. But could this simple setup stand the test of reality in a complex legacy organization like Alm Brand?

In the following sections, we will describe what challenges emerged over the following months, and the new (scaling) structures we introduced to ensure cross-team and cross-organizational alignment, coordination, and prioritization.

4.      Descaling meets reality

4.1      Coordination across major Initiatives

When we introduced the DL role, we expected the role to be applied occasionally and temporarily only. However, soon we had multiple larger Initiatives running in parallel. All of them shared the same characteristics as the partner Initiative, that is contributions from multiple Squads were needed for a limited period and a complex stakeholder landscape outside BD&D to engage with. Based on the success of the partner Initiative each of these Initiative was assigned a DL.

In general, DLs were mainly assigned based on their experience with the coordination of complex projects rather than on their experience with Scrum and Agile. In that sense, DLs were supposed to serve as adapters between the Agile Squads and non-Agile stakeholders. Some DLs handled the role well and worked closely with POs, whereas others merely dictated fixed scopes and deadlines to the Squads. At the same time, more teams, with varying degrees of Agile maturity, became part of the Agile setup, increasing the number of Squads that needed to coordinate to a total of 25.

Now, with multiple Initiatives running in parallel, we quickly noticed several issues:

  • Multiple Initiatives, often with fixed deadlines, having dependencies to the same Squads
  • Ambiguity regarding the prioritization of the Initiatives
  • Squads focus and capacity were drawn to the Initiatives, and as a consequence key stakeholders in the business units felt neglected

In the following sections, we will describe how these issues were addressed by introducing a couple of new events.

4.2      Obeya – Portfolio management

As the number of Initiatives grew, so did the need for portfolio overview, prioritization, and management.

To address high-level prioritization, a senior manager was appointed to be responsible for the portfolio. To get buy-in from the business units, she (and the top management group) established the Business Development Committee (BDC). The committee consisted of senior management people from the rest of the organization, as well as from BD&D. The primary role of the BDC was high-level prioritization and initiation of Initiatives.

We were asked to ideate and facilitate a working Agile portfolio function. Our assumption was that, if we could create transparency over the portfolio by facilitating an event for inspection, then the POs, Portfolio Management, and DLs would eventually adapt accordingly. Consequently, we set up and facilitated an event, every Monday. We were determined to incrementally and iteratively introduce new “artifacts” to gradually heighten the level of transparency, keeping in mind that POs are busy people.In particular, we wanted to draw attention to:

  • The need for overall prioritization as high-level guidance for POs
  • The amount of work in progress (WIP)
  • Expected outcome (value) rather than just output (deliverables)

Furthermore, we also wanted to give Squads the opportunity to bring up general risks and impediments.

In short, our ambition was to create an Obeya (Japanese for Big Room)[8] of transparency connecting the strategic level (prioritization and what the organization was trying to achieve) to the executing Squad level. As it turned out the event was quite popular and week after week POs would update information about their Squads. However, little visible action was taken, despite the obvious fact that many Squads were spread too thin over several Initiatives and/or were struggling with systemic impediments. Furthermore, at this point we did not succeed in finding the right form for communicating high level portfolio priorities. On one hand, we were asking for a clear prioritized list, on the other hand management was concerned that if such a list was produced, critical parts of low priority Initiatives would be postponed because these Initiatives were low priority when compared to other Initiatives. Consequently, no clear prioritization was provided at this point.

The important discussions and the transparency sparked in the beginning faded over time, as the discussions led to fewer actions, and eventually the meetings were canceled.

4.3      Cross-team alignment and dependencies

At the time, when we had little and ineffective portfolio management, our EVP of BD&D approached the Fast-Team, with a clear request: “I don’t see we are moving forward. Together. In sync. Show me!”

It was clear that more coordination and alignment across Squads and Initiatives were needed. We also had a notion that too much was going on in our organization at the same time. All of this resulted in a significant increase in the overall complexity and waste due to context switching.

Our response was a facilitated PO and DL sync that became known as “Big Room Planning” (BRP).

On top of our ambition to create transparency and alignment, we saw BRP as an opportunity for other purposes as well:

  • Create an opportunity in time and space for the POs and DLs to engage in conversations with senior management to address specific problems and clarify prioritization issues.
  • Create awareness of dependencies and fixed dates, to inform DLs of other fixed dates outside “your own” Initiative that should interest you as a DL.
  • Create awareness of risks and impediments. Since there was no longer any well-established process for escalating risks and impediments, we saw the BRPs as an opportunity for making senior management aware of these, so they could act on them. In our experience, management did indeed act on the risks and impediments raised at the BRPs.

In many ways, the BRP event resembled that of a PIPE[9] in SAFe, but there were and still are some distinct differences. First of all, the BRP is not focusing on predictability. Instead, we wanted to emphasize transparency and alignment. Furthermore, no developers are invited since planning takes place before the event.

At the first BRPs we planned 6 Sprints ahead. However, due to a constantly evolving Initiative portfolio, it soon became apparent that the 6-sprint planning horizon was wishful thinking, and now we plan 3 Sprints ahead only, with a BRP cadence of two Sprints. When you consider the time frame (3 Sprints) and the cadence (2 Sprints) you will see that the last Sprint of a BRP in June will be the first Sprint of the BRP in July. Some frustration arose from this fact: “We are planning the same sprint twice!”, but we maintained this “double planning”, because it gave us solid data on how good the participants were at foreseeing the near future. So, we started asking the participants how their predictions have fared, and out of that, came some interesting insights and learnings.

When we introduced the BRPs, our assumption was that over time, the BRP would become obsolete since POs and DLs, eventually would start to continuously coordinate by themselves. However, almost a year down the road the BRPs are still going on, although the time allocated has diminished considerably. All participants now know what is required of them and consequently, they are better prepared. Most content is made in advance and coordination and prioritization issues are addressed before the meetings. The time allocated has, therefore, gradually decreased from 6 hours in the beginning to a mere 2½ hours as we have continuously become better and better at addressing prioritization and coordination issues.

Hower, in the beginning the BRPs were close to suffer the same fate as the ill-fated portfolio meeting (as described in Paragraph 3.2) and for the very same reasons. Fortunately, something happened that completely changed the value of the BRPs; another SVP[10] took the steering wheel. With the Portfolio Manager, she participated in the BRP sessions all day. They were courageous enough to support the process and answer tough questions and dilemmas concerning prioritization, and even had the guts to admit that right now, she did not have a clear answer, but would pursue one. After a few of these events, she, the Fast-Team, and the Portfolio Manager drove the effort to break down the Initiatives into smaller work items (i.e., Features). Preferably we would have liked to see a Value-Based Breakdown, but not all were up for the challenge, so just one or two DLs managed to do so, and it required intense assistance from the Fast-Team. The effect was dramatic, suddenly management, POs, and DLs could discuss sequencing and prioritization in detail.

4.4      Serving stakeholders in the business units

At the time when the setup consisted of two Tribes and two Tribe Leads, it was easy for people in our business units to figure out who to go to with a problem or a need. Now with 25 Squads in a descaled setup, people in the business units were complaining that they no longer knew who to talk to. Furthermore, with a growing number of Initiatives with fixed deadlines, POs felt an increasing pressure to prioritize work on the Initiative over improvements to existing system. Consequently, stakeholders in our business unit felt neglected.

To bring POs and stakeholders closer together, the Fast-Team in agreement with management decided to introduce monthly mandatory meetings between key stakeholders from the business side and POs facilitated by two ACs (the authors). To do that, we divided our Squads into four groups, so Squads with common stakeholders were grouped together in what we called a Value Area (VA) as they resembled distinct parts of our value stream. These monthly meetings were named Value Area Meetings (VAM). Each VA was assigned a dedicated sponsor from senior management on the business side. The idea was not that the sponsor should replace ongoing stakeholder relations or that the VAMs should replace or compete with the Squads reviews. Instead, sponsors should give input to POs regarding business strategy for the VA and current pains so POs and their Squads could come up with solutions to address pains and business objectives. For instance, in one VA, which includes our call center, the sponsor told the POs that the most important issue for him was to reduce the number of calls to the call center by moving traffic to digital channels.

To quickly address the perception that Squads` focus was misaligned with business needs, we asked sponsors to present the top 3 key areas they believed Squads should be focusing on. Similarly, we asked the POs to present what functionality was recently completed, what they were currently working on, and what was in the pipeline in terms of improvements for the business units and larger company-wide strategic Initiatives. In general (and to our relief), the Squads were not far from the mark and when their main scope of work was not serving the business units, they were focusing on important strategic Initiatives that the sponsors were well aware of.

5.      Alm Brand’s Descaled setup

The activities described above took place over a period of approximately one and a half years and included two lockdown periods where everybody was working remotely for months. After that, our descaled setup consisted of 5 elements as summarized in the figure below:

  1. 25 autonomous cross-functional Scrum teams.
  2. Squads with shared stakeholders are organized in 4 Value Areas.
  3. A Delivery Lead is accountable for stakeholder management and cross-team coordination for larger strategic Initiatives.
  4. Cross-Squad dependencies, tradeoffs, general impediments and risks are addressed at Big-room planning once a month.
  5. The Business Development Committee makes all high-level decisions regarding prioritization of Initiatives.

Alm Brands descaled Agile SetupFigure 2 Alm Brands descaled Agile Setup

6.      What We Learned

So, looking back, was abandoning scaling the right choice? We still believe it was, but we also learned that some additional roles and events are needed to support One-Team-Scrum as soon as the dependencies across teams reach a certain level, particularly to address cross-team and cross-organizational coordination and prioritization. We have found the Delivery Lead role to be a lightweight and flexible scaling structure to deal with temporary coordination needs, especially when combined with some structures to ensure overall prioritization and coordination as described in this report. On the other hand, if more teams need to coordinate closely for a longer period, we recommend putting in the effort to adopt a more formal scaling framework.

So, what would we do differently? Well, we still believe that it is impossible to predict every issue or need that may occur, and we do believe it is better to start out as lightweight as possible and then add the necessary structure as needed rather than starting out with a heavy framework believing it can solve all your problems. However, there is one thing that we, in hindsight, should have given a higher priority: Training and support of key roles from Squads to DLs. We believe that more training and support for DLs would have caused less friction with Squads and resulted in a more Agile approach to slicing and refinement of larger Initiatives.

Somewhat related, we would also have put more effort into ensuring more consistency in the ways of working across Squads. Since Squads have been working independently from each other for some time, consistency across Squads regarding Agile practices has been lacking which have caused frustration for DLs when they are trying to coordinate work between Squads and report to their stakeholders.

We have also learned, that when you descale, you should be aware that all escalations from the Squads will go to the next management level, which in our case is the CLs, who must be prepared to deal with escalation issues spanning both people, process, product, and technology.

We have been asking ourselves whether these additional structures were needed. Had we been smarter or better ACs could we then have succeeded with a pure Scrum setup without adding any additional roles and events? Perhaps, but in our humble opinion, this would require an almost ideal Agile organization with very few dependencies between Squads, stakeholders with sound understanding and experience with Agile, and very mature Squads, DLs, and POs.

On a personal level, we have learned that to succeed with Agile, you should focus less on reading the very latest book or blog post on Agile and focus more on understanding what Agile techniques will benefit the organization now and which will merely cause frustration and confusion at this stage. The Danish philosopher, Søren Kirkegaard expressed our point and perhaps the very essence of Agile Coaching more than 150 years ago: “That if one is to truly succeed in leading someone to a particular place, one must first and foremost take care to find him where he is and begin there. This is the secret of all coaching. He who is not capable of that is merely being arrogant, when he thinks he can help someone else.”

7.      Acknowledgements

First and foremost, we would like to extend our gratitude to our colleagues at Alm Brand, who laughed, cried, and worked hard with us in an atmosphere of trust and mutual respect. A special thanks to EVP Kristian Hjort-Madsen and SVP Line Sofie Vad Østergaard, for trusting us and empowering us to experiment and learn with the rest of the organization, and thanks to Lundbeck and Alm Brand Group for allowing us to work on this and participate in the conference.

Thanks to the rest of the Fast-Team, the best LACE on the planet, and a special recognition to Søren Raaschou, who gave our FAST>> model a theoretical form.

For valuable feedback, we give thanks to Stine Nørgaard Olsen (CL) and Dirk Bucka-Lassen (AC).

Lots of love and gratitude to our families. This article would not have seen the light of day without your support and understanding.

Also great thanks to Frank Olsen for encouraging us to submit a report about our experiences with descaling.

And finally, we would like to thank our brilliant shepherd Dr. Jutta Eckstein, for keen insights and thought-provoking questions that led to new discussions and insights. Thanks, Jutta, we couldn’t have done this without your support and valuable feedback.

 

8.      REFERENCES

Kniberg, Henrik and Anders Ivarsson “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”, 2012, https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Quartel, Ron “There’s a New Kid on the Agile Block — FAST Agile” Medium 2021,

https://medium.com/fluid-scaling-technology/theres-a-new-kid-on-the-Agile-block-fast-Agile-b568bef3245c#:~:text=Fluid%20Scaling%20Technology%20or%20FAST,turn%20of%20the%20millennium%20also

Raaschou, Søren “Agile Planning Circles” Manage Complexity”, 2019a,

http://www.managecomplexity.dk/blog/2019/05/23/agile-planning-circles/

Raaschou, Søren “Agile Planning Circles – the Artefacts” Manage Complexity”, 2019b, http://www.managecomplexity.dk/blog/2019/05/24/agile-planning-circles-the-artifacts

Schuyt, Ian “What is a Delivery Lead?” Medium 2020a,

https://ishoot.medium.com/what-is-a-delivery-lead-df47ced19da7

Schuyt, Ian “Delivery Lead”, Medium 2020b,

https://medium.com/swlh/delivery-lead-f28eb8c5d7e9

Wiegel, Tim, 2020

https://leadingwithobeya.com/product/leading-with-obeya-the-book/

[1] Alm. Brand Group since May 2022

[2] The experience in this article is from the author’s perspective, and we are solely responsible for the statements and the conclusions that can be drawn from this. “We” in this story means us, the authors. However, we sometimes mention our LACE which we are / were an integral part of.

[3] Executive Vice President

[4] “FAST>>” is not an abbreviation. It means: “Fast forward – creating value to the customer…”. The FAST>> method is totally unrelated to the Fluid Scaling Technology (FAST Agile) method [Quartel 2021]

[5] Squads: To underline the cross functionality and autonomy of a special forces squad of the armed forces.

[6] Essentially a CoP – Community of Practice in SAFe terms.

[7] Following [Schuyt 2020a] we deliberately use the term Initiative rather than project to emphasize full life cycle focus i.e., Initiatives are built, run, and owned by the Squads.

[8] The Obeya connects strategy to execution by “visualizations of the work to get a clear picture of where we are and where we want to go and find problems that come our way” (Wiegel, 2020)

[9] PIPE: Program Increment Planning Event is normally a two-day event with everyone in the ART participating and the output is a 5 sprint plan teams are committed to.

[10] Senior Vice President (refers to EVP)

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
XP 2022

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now