Suppose the company you work in has requested one of the big consultancies to roll out their favourite scaled agile framework to you with a big bang? It most often is a version of the so-called “Spotify model”. Here is a curated selection of background, readings and videos you want to be familiar with if you find yourself in such a situation.

A part of the so-called Spotify model from Kniberg and Ivarsson’s 2012 article

“I know what I wouldn’t have done, and that is outsourcing the problem to [a big consultancy]… and have them find a solution. The research results are clear. The solutions must come from within the organization.” – John Kotter

What is nowadays called the “Spotify model” is a snapshot of how Spotify in 2011 envisioned to work in the future. Its origins can be traced back to this 2012 article, written by Henrik Kniberg and the former engineering lead and agile coach from Spotify Anders Ivarsson.

Based on that article, and a great series of videos by Henrik Kniberg on the Spotify engineering culture (part 1 here, you can find the rest quite easily), people coined the presented way of organizing as the “Spotify Model”.

 Never mind that even Spotify doesn’t use the spotify model, and just maybe, neither should you.

Comparing the “Spotify Model” to SAFe and LeSS

SAFe and “Spotify Model” contain a lot of the same genetic material. Squads are Teams, Tribes are Trains, Chapters are the line organization of the dual operating model proposed by Kotter and later on adopted by SAFe, and Guilds are communities of practice. The rest of the roles in the original 2012 article map quite directly to similar roles in SAFe. 

There are videos out there which compare Spotify and SAFe, this one by Joakim Sunden, a former agile coach from Spotify and the person who coined the term Tribe. Furthermore in the “Spotify Model” teams are supposed to have an entrepreneurial attitude (similar to that of Marty Cagan’s empowered product teams) and figure out by themselves what to do. In SAFe, the teams are more akin to a delivery organization.

Comparing to LeSS, the key differences are that teams in the “Spotify model” have their own backlogs and there is a product owner per team. These are both something LeSS advises against. Further, emphasising team entrepreneurship doesn’t encourage the cross-functional learning which needed to constantly shift to work on the most important things. 

Rather, it can limit teams to their own areas, hindering collaboration and overall product success. Also, the Team PO role hinders the teams to handle coordination by themselves at the developer level, which leads to increasing the wastes of delay, inventory (via intermediate artifacts such as requirement specs) and coordination bloat.

Why do big consultancies favor the “Spotify Model”?

In my opinion there are four main reasons, which work together:

1. The “Spotify model” is very similar to SAFe. With the difference that you don’t have to deal out part of the profits to Dean Leffingwell & the folks at Scaled Agile. As a consultancy, you can invent your own jargon and practices (which can most often be directly mapped to SAFe) to fill in the gaps of the “Spotify model” and get the client hooked on your version. 
   
   And just like with SAFe, these additional details provide the legacy organization a scaffolding with places to hide in, so you really don’t have to change all that much. Departments can call themselves tribes, component teams become squads, and system owners can remain system owners – you don’t even have to change the term. Finally, with the team product owners handling the brunt of coordination, the inefficiencies of “low-cost” outsourcing remain out of sight.
   
2. Spotify conveniently has team product owners. If the client company wishes to stick to the “cost-saving” outsourcing model of the 90s, where the rest of the team is far off and programmers change constantly, you don’t have to make the hard decision of starting to insource developers.

3. Transformation as a big bang project. In the “Spotify model” you don’t have the notion of Kotter’s (and SAFe’s) dual operating system and is no recommendation of doing the change by moving people group by group into a “parallel organization” which operates in the new way.

From the perspective of the business model of the big consultancies, the above mentioned factors play well together. Further, as it’s not good business to sell a small incremental solution,- big consultancies invariably provide a big solution. The job then is to get in, do a quick transformation project with a big of a bang as possible, with as many consultants as possible (who possibly change constantly), with a clear beginning and an end from an internal resource and pipeline management perspective. 

Then, the consultants can celebrate the success with those who paid the bill, publish a sugar-coated case study, get out, and then return to help out and draw more profit as the client discovers that the success actually wasn’t a success to the people in the trenches. 

Indeed, most of the advice out there seems to point against a big bang or considering the transformation as a project. The intent of changing the way of working should concern and be clearly communicated to everyone, but rolling out the actual change (in other words, “moving to the parallel organization” as Kotter and subsequently Larman put it) should be done group by group, preferably starting with real, not fake volunteers. And you get real volunteers by educating everyone – something which is hard to do with a big bang.

Then, the fourth reason:

Why Spotify instead of LeSS? Big clients and big consultancies both favour big solutions, and LeSS certainly doesn’t look like one. It also doesn’t help that folks versed in LeSS do not typically work for a big consultancy, and instead quite clearly argue that such method vendors should be avoided.

Instead, LeSS folks strongly state that the solutions should come from inside the company.

Resources to help you on your way

As these things go, if you are still reading this, chances are you may not be one of the people who get to call the shots whether to “adopt Spotify” or not. 

So, I’ve collected some curated materials below to help you on your way. I’ve listed them in the order of importance:

1. A reality check in the form of a video: not even Spotify uses the Spotify model – particularly not outside of R&D which I’ve heard being touted as an upside of “the spotify model” by the big consultancies. The linked video is by another co-author of the Spotify model, Joakim Sunden. An interesting detail is that Spotify nowadays has one manager per every five people.

2. Jurgen Appelo does an excellent job of both describing and analysing the Spotify model, as well as providing an updated version of it. The article is also endorsed by former mentioned Anders Ivarsson, a co-author of the spotify model.

3. This article by Alexey Krivitzky does a good job in analysing the Spotify model from the perspective of optimising for adaptiveness (in other words, agility), and thus, points ways forward to heights not directly supported by the model itself. 

4. Joakim Sunden talks about his and “the model’s” journey at Spotify from 2011 to 2017 and shares lessons from helping with transformations in other companies since then.

5. An article by Rowan Bunning explains the pitfalls in implementing “the Spotify model” at ING” – the emphasis on the entrepreneurship of trains and tribes may lead to a new set of siloes.

6. This video (Death of the Spotify Model) by Girjs Meijer and Marcin Pakulnici) seems to talk about the same story as the above article by Rowan Bunning. Essentially, the moral of the story seems to be dismantling the “entrepreneurship” and shifting all of the teams as general-purpose teams striving to work on the highest value.

7. As the final resource, a video comparing SAFe to Spotify by Joakim Sunden. It’s worth listening to, but some points regarding SAFe are a bit (but not too drastically) off. 

If you have more great material on the topic, do let me know, and I’ll include it with an endorsement to you finding it.