Organizations today are adopting new methodologies that span the gamut in hopes of finding the best competitive advantage for their business. Some look to mainstream Agile methodologies while others look to organizations like Spotify for inspiration.
With so many frameworks, models, terminologies, and opinions in the agile space, it is a challenge for business leaders and agile professionals to decide which approach will best suit their organization, or even where to get started.
In this article, we will shine a light on the relationship between two such approaches: Scrum@Scale®, and the so-called “Spotify Model.”
Some[i] currently classify the Spotify Model and Scrum@Scale as two separate frameworks for scaling Agile. Yet, In 2019, Registered Scrum@Scale Trainer™ and former Agile Coach at Spotify, Henrik Kniberg, released a Scrum@Scale case study titled, “Spotify – a Scrum@Scale Case Study” in which he explains that the “Spotify Model” is really just an early implementation of Scrum@Scale.[ii]
While modern interpretations of the two suggest nuances, the question stands: are Scrum@Scale and the Spotify Model two different approaches to scaling agile, or is the Spotify Model just an early instance of Scrum@Scale?
Before we jump in, it’s important to clarify the distinction between a “framework” and a “model.” According to the New Oxford American Dictionary, a Framework is “an essential supporting structure; a basic structure underlying a system, concept, or text,” and a Model is “a system or thing used as an example to follow or imitate; a particular design or version of a product.”[iii]
What is the Spotify Model?
The Spotify Model was first introduced in 2012 when Henrik Kniberg and Anders Ivarsson published the white paper, “Scaling Agile @ Spotify.” In the paper, Kniberg and Ivarsson detail Spotify’s approach to enabling agility. Since the publication of that paper, Henrik Kniberg has commented on numerous occasions that the Spotify Model isn’t a framework – but rather, represents Spotify’s view on scaling from a technical and cultural perspective.
In 2012, Kniberg & Ivarsson’s “Scaling Agile @ Spotify” paper detailed how Spotify utilized Squads, Tribes, Chapters, and Guilds to scale to over 30 teams.
As Henrik puts it, “I’ve spent a few years working with Spotify and published a few things…. This has come to be known as the “Spotify Model” in the agile world, although it wasn’t actually intended to be a generic framework or “model” at all. It’s just an example of how one company works.”[iv]
What is the Scrum@Scale Framework?
The Scrum@Scale framework, on the other hand, is an actual framework. Scrum@Scale naturally extends the core Scrum framework to deliver better results across any organization. It provides the scaffolding for systems and processes to grow organically, empowering organizations to achieve business agility and deliver greater impact. Rather than trying to apply a “one size fits all,” turnkey solution, Scrum@Scale provides a lightweight, adaptable framework that has the ability to adjust to your context, making it customizable across industries. Dr. Jeff Sutherland, co-creator of Scrum, spent years codifying the leading practices for scaling, with the earliest experiments for that framework in 1983. In early 2018, Sutherland formally introduced the Scrum@Scale Guide[v] to the agile community as “the framework for organizations to iteratively develop the best way for Scrum to work in their context.”
The Scrum@Scale Guide details the key components of the Scrum@Scale framework so that organizations can install an “Agile Operating System.” The Product Owner Cycle and the Scrum Master Cycle are critical to product increments, releases, and feedback.
‘From the Source: An Interview with Dr. Jeff Sutherland and Avi Schneier
The Spotify Model and Scrum@Scale are aligned; however the differences between the model and the framework are important. To provide more context and history, we asked Dr. Jeff Sutherland, co-creator of Scrum and inventor of Scrum@Scale, and Avi Schneier, Principal Consultant at Scrum Inc. and a contributor to the Scrum@Scale guide, to answer some of the most popular questions about the relationship between Scrum@Scale and the Spotify Model.
Q: When was Scrum@Scale invented and when was it first “released”?
Sutherland: “The first prototype of my thoughts around scaling that lead to the eventual synthesis of Scrum@Scale was implemented at Mid-Continent Computer Services in 1983. Several enhanced versions were implemented in multiple companies until the first Scrum team was formed in 1993. In 1995, Ken Schwaber and I wrote the first formal paper on Scrum. In 1996, we had implemented the first set of teams based on this formal paper on Scrum. This had in it all the key pieces of what we today know as Scrum@Scale, including a component-based architecture. This component-based architecture allowed companies to build their organization like they build their products. Prototypes of Scrum@Scale were in the market, evolving and adapting at hundreds of companies until Intel Agile Leadership asked me to create a formal Scrum@Scale Guide. Early iterations of the Scrum@Scale Guide were crafted in 2014 and codified from real market feedback, and Version 1.0 was formally released in 2018.”
Early prototypes of the Scrum@Scale framework were in the market, evolving and adapting. In the 2010s, Jeff Sutherland and Scrum Inc.™ began iterating on Scrum@Scale documentation.
Q: “Build your organization like you build your products.” What does this mean? Is every implementation of Scrum@Scale unique?
Sutherland: “Today, products need to have a scalable component model so any piece of a system can be upgraded daily without breaking other pieces of the system. This strategy is what Saab Technologies uses to build fighter aircraft, Tesla uses to build cars, and Apple uses to build iPads.
For an organization to successfully build such products and scale, their organizational model must parallel their technical implementation or they will not be able to make daily improvements in new features that are deployed to the market more than once a second, like at Amazon. This speed disrupts whole industries in weeks. For example, a few years ago Amazon rapidly took over much of the consumer loan market in Germany.”
Schneier: “This is actually the biggest challenge I see when organizations adopt Scrum@Scale. The common mistake is to take their existing hierarchy and try to map Scrum@Scale and the way the teams need to organize on top of it. This is problematic. The proper way is to, first, map out your value stream(s) and then map the people onto it second. We say that in order to be Agile at scale, you have to be willing to refactor the organization to optimize production. Resistance to that just creates waste.”
Q: At a Glance: What is the Spotify Model?
Sutherland: “When Henrik took over as Head Agile/Lean Coach at Spotify they were going through the motions of Scrum. However, Scrum Masters were not leading and teams were not performing, so Henrik made some changes. He changed the name of the team to “Squad”, called groups of teams “Tribes,” and enabled teams with Agile Coaches to improve performance. Managers were responsible for “Chapters,” which included hiring and training developers with specific skill sets across teams. Henrik and I were teaching Scrum@Scale together in Stockholm so there was mutual cross feed at this time. I was visiting Spotify when I was in Stockholm where Henrik and I would meet with the Agile Coaches to address critical issues.
For example, the Spotify CEO told Henrik that the teams had to deliver twice as fast to compete with Google and Amazon. In our Agile Coaches meeting at Spotify, we noted that all teams were delivering every sprint already, but the best way to double production was to coach the developers to deliver every single day, just like Google and Amazon. Within about six months we had about ⅓ of the teams delivering every day.”
Schneier: “What today is known as the “Spotify Model” actually has little to do with Spotify or how they were working. In most instances, companies and consultants have adopted the terminology while foregoing the key structures, practices and mindset that enabled Spotify to perform in the first place.”
Q: What problem does Scrum@Scale solve?
Sutherland: “Scrum@Scale is an operating system for all organizations that delivers twice the value at half the cost and enables them to deliver true business agility. It is based on working with some of the largest and most valuable companies in the world. Twice the value in half the time is demonstrated in a new paper in the IEEE Digital Library, “Rocket Mortgage Delivers Twice the Value in Half the Time at Scale.”[vi] This paper illustrates, step-by-step, how even a large and successful SAFe implementation can reduce cycle time by 400% by implementing Scrum@Scale.”
Q: Was the Spotify Model an early implementation of Scrum@Scale?
Sutherland: “Scrum@Scale clarifies the implementation of an Executive Action Team and a MetaScrum Forum which are critical to a company delivering higher value. This will typically be reflected in stock price or company valuation if the organization is privately owned. It also has a more rigorous implementation of Scrum and expects Scrum Masters to be ‘Leaders who Serve.’
What Henrik Kniberg implemented at Spotify was valuable to the company at that time. The implementation took Spotify to a public offering and was an inspiration to many agile developers. I was frequently invited by Henrik to visit Spotify to work with the Agile Coaches to solve their most difficult problems. As Henrik points out in his Scrum@Scale case study, it is a unique instance of Scrum@Scale suitable for its time and place. Spotify management says they no longer use it and none of the creators of the model are currently associated with Spotify.
As Marcin Floryan, Director of Engineering at Spotify puts it, “We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working – a journey in progress, not a journey complete. By the time you read this, things have already changed.”[vii]
Q: What goes wrong when a company “copies” what another company does? What risk does an organization assume by simply “doing” the Spotify Model?
Schneier: “We are often asked when we begin working with a new group of business leaders to implement “best practices”. This is often a foolhardy endeavor. First of all, there is no guarantee that adopting the way a different organization works, including Agile ways of working, will work in your context. While most of the problems companies face are common, each company is a unique compilation of products, ecosystem, and culture. That is why the “one-size-fits-all” approach is doomed. The best results are achieved when we begin by examining the underlying “why” a given practice or framework is successful and then experiment and iterate with how it works in your context and culture. This is why Scrum@Scale has proven itself across a multitude of organizations and domains.
Second, the concept of “best practices” implies there is no better way to do it, and it stops the organic search by the adopting organization to actually find what would work best for them. I prefer the terms, “leading practices’ or “better practices” to encourage adoption and continue the search. The main risk an organization assumes by adopting the Spotify Model is that they’re not Spotify so not only will it fail, but it prevents them from actually finding a better way for them to operate.”
Q: What Scaling Patterns emerged at Spotify? Did any of them end up in the Scrum@Scale framework?
Sutherland: “The patterns that created Scrum@Scale are documented in the patterns book (Scrum: The Spirit of the Game[viii]) and the patterns are developed from companies that existed decades before Spotify.
The main thing I would take from Spotify is that Agile Coaches are not enough, yet we need Scrum Masters to be Agile Coaches which is what we are doing at Scrum Inc. Henrik set a formal standard that Agile Coaches have a total focus on improving teams.
The second valuable thing at Spotify, in my view, is managers as Chapter Leaders. The managers hire, fire, train, and motivate people in specific skill areas across organizations. Additionally, they set standards for tools, quality, and performance across the organization. They do not do any direct day to day management of their employees.”
Schneier: “This pattern, while not formally part of S@S, is a beneficial practice which we have spread through the notions of Communities of Practice and Quality Circles.”
Q: What other early implementations of Scrum@Scale influenced the evolution of the Scrum@Scale framework?
Sutherland: “The first prototype at Mid-Continent Computer Services in 1983 had Sprints, Backlogs, Product Owners, self-organizing teams, Burndown Charts, etc. and made the ATM Business Unit the most profitable business unit within six months. This is what we hope to see in all Scrum@Scale implementations.
The first implementation of Scrum@Scale with the formal Scrum model published by Ken and me was done at an internet company that went public in 1996 (Individual Inc.). We were also working with large groups of teams at companies like Fidelity at the time.
The formal basics of Scrum@Scale were further fleshed out at IDX (now GE Healthcare) during 1996-2000. IDX is referenced repeatedly in the scaling patterns described in Scrum: The Spirit of the Game.
Scrum exploded with the release of the Agile Manifesto in 2001[ix]. By 2005, Ken asked me to train all the major companies in Silicon Valley. Yahoo, Google, Adobe and many other companies started Scrumming with large groups of teams at that time.
From 2000-2008, I was the CTO of PatientKeeper which had one of the highest performing Scrum@Scale set of teams ever documented.[x] The MetaScrum was refined further at PatientKeeper.
By 2009, I was implementing S@S at companies like Pegasystems which achieved similarly dramatic results as seen in the 1983 implementation at Mid-Continent Computer Services.
Formal documentation of Scrum@Scale was critical to Agile leadership at Intel and SAP and the work done since 2005 with thousands of teams at Microsoft and Amazon was influential. The agile leadership at SAP, with over 2000 Scrum teams, helped inform the first release of the Scrum@Scale Guide and was adamant about the need for an effective MetaScrum.”
Q: “The Main Connection to Scrum@Scale is Delivery”: How Does S@S Help Teams Deliver?
Sutherland: “As shown in detail in the paper mentioned earlier, “Rocket Mortgage Delivers Twice the Value at Half the Cost”, Scrum@Scale systematically analyzes both business and technology operations and implements improvements that have maximum cost/benefit impact.
The first step for Rocket Mortgage was to get a consistent Scrum implemented. They eliminated the 15 SAFe roles and cut it to the three roles in the Scrum Guide. All other roles were retrained as team members or moved to another area of the company. The second step was to implement a delivery focus in all roles and all meetings.
Product Owners needed to improve value delivery per point. Scrum Masters have to improve team performance. Those who could not do this effectively were moved to other roles in the company. Meetings were changed to totally focus on delivery. Their timing, agenda, and participants were changed to deliver a fully functional product in a shorter and shorter time frame until they achieved daily live product upgrades.
There are many other details in the paper that show companies how they can step by step use Scrum@Scale to ramp performance, impact market share, with any preexisting agile implementation or scaling framework.”
Schneier: “When you take a look at the earliest videos and papers on Spotify by Kniberg, you’ll see a lot of emphasis on releasing in a DevOps manner. This is how they are connected. Just as Scrum is delivery method agnostic, so is Scrum@Scale. That being said, if a Scrum team – and hence a group of Scrum Teams, or a Scrum of Scrums as we call it – is an independent path to production, then you can see why we would support a DevOps or DevSecOps type of delivery method. It’s simply the fastest way to get working product to your customers.”
Conclusion:
If you, like many business leaders, are looking for answers on how to structure your teams or scale Scrum to achieve better business outcomes and agility, don’t settle for adopting what others have tried and expect the same results. There is no magic turn-key solution. Each organization should examine its practices regularly, and continuously evolve and adapt them as their context, market and culture inevitably change.
Or, as Jeremiah Lee, former Product Manager at Spotify eloquently puts it, “You might have discovered the Spotify model because you were trying to figure out how to structure your teams. Don’t stop here. Keep researching… Turns out, Spotify in 2012 had not figured out how to maintain the speed and nimbleness of a small team in a large organization. The company evolved beyond its eponymous model and looked outside of itself to find better answers. You should too.”[xi]
This is what Scrum@Scale teaches and what Spotify instantiated. As a framework, Scrum@Scale provides structure through a minimum viable bureaucracy (MVB) which does not constrain growth in a particular way. Instead, Scrum@Scale allows for a network of teams to grow organically, based on the network’s unique needs, and at a sustainable pace of change that can be better accepted by the individuals involved and the organization at large.
References