There is No Spotify Model for Scaling Agile

Anthony Mersino — February 17, 2020

Recently a client told me that they were adopting the Spotify Model. Which sounded great at first. Spotify has published some great articles and videos about how they have grown and transformed their organization to be agile. Then it occurred to me that what he was saying was completely wrong.

The “Spotify Model” is not an Agile Method

So everyone has fallen in love with the Spotify Model and the charismatic Henrik Kniberg, one of the early coaches at Spotify who provided a window into how Spotify uses agile. And somehow, they have come to see the “Spotify Model” as an agile method or framework.

Wrong, dead wrong.

In his own words, Kniberg has stated that Spotify was not intended to be a framework or model.

Spotify (and Kniberg) has made public a lot of information about how they organize with squads and tribes, the various technical practices they use and the culture of the organization. If you are not familiar, check out Kniberg’s blog posts at Crisp as well as these popular videos many people refer to Spotify Engineering Culture Part 1 and Part 2.

Though the blogs and video provide a lot of information about how Spotify organizes and gets work done, that does not make Spotify an agile method folks.

Nor is Spotify a Scaling Model

Worse, people have come to view Spotify as an approach to scaling. Though Spotify did scale-up with hundreds of agile teams, that doesn’t make their approach a scaling model.

But others would disagree with me. Take a look at the chart below which comes from the most recent CollabNet VersionOne Annual State of Agile Report. The chart shows that a full 5% of the people who are scaling agile claim to be using the “Spotify Model“. That is a lot of people! And it is a huge spike upwards from the previous years where no one mentioned the Spotify Model as a scaling method.

The Spotify Model is not an Agile Scaling Model. Not even close. Henrik Kniberg has even come out and said that rather than scaling agile, you should descale your organization.

Why have some many people come to see Spotify as a scaling method? Is it just the cute diagram of squads and tribes?

Mimicking the Spotify Agile Model is Lazy

Many organizations are simply taking the colorful org diagram below and using that to relabel or rename their existing teams. Without changing anything else. That is a pretty lazy approach to change and it isn’t likely to be transformative.

You see, mimicking someone else is not the same as adoption or agile transformation. Ever heard of cargo cult agile, where people imitate the actions of others without knowing what they are doing or why?

Here is the problem – These colorful charts are now nearly 10 years old. Who knows what Spotify is actually doing today?

A Bigger Problem – The Spotify model evolved over time as a result of experimentation at Spotify. You cannot lift some or part of what Spotify did and expect it to work at your company. You need to run your own experiments, LEARN what works, and keep trying things until you optimize your organization.

An Even Bigger Problem – It isn’t the name or label of the teams that matters. The name is irrelevant. You don’t get the “Spotify Model” by renaming your teams. If you could, we’d all be using squads and tribes.

What makes Spotify an inspirational and often copycatted company is the BEHAVIORS and PRINCIPLES that supported the organization. You get the Spotify Model by having a culture that is aligned to the agile principles, that supports safety, experimentation, learning, trust, and joy at work.

Kniberg himself stated that the agile principles are more important than specific practices. Most people implementing the so-called Spotify model are either unaware of, don’t understand or don’t care about the 12 Agile Principles.

Spotify Infatuation is Not a New Concept

I am far from being the first person to notice this infatuation with Spotify or the misapplication of any sort of model. Kniberg himself noted it in a 2015 blog post. I just don’t think people want to hear it.

This kind of thinking reminds me of the title of the 1968 article from Federick Herzberg, “One More Time How Do You Motivate Employees”. It was clear from the title of his article that Herzberg had given the answer before; if you want to motivate employees, give them challenging work and increasing responsibility. That is the correct response to how to motivate employees, but it is difficult, so people keep asking the question in hopes of finding an easier answer.

So those that want to “adopt the Spotify Model” are really just looking for a quick fix or silver bullet. They don’t really want to change much, they just want to tweak a few things.

What Can We Learn from the Spotify Model?

I don’t think you can really understand what it is like at Spotify without actually living it. You see, most of us are working from our own paradigm and belief system and we have a hard time imagining how it really works at Spotify. We probably gloss over all the things that made the Spotify culture worth emulating. Or we project on Spotify the things we believe even though we see no evidence that they exist. The visible things like Squads and Tribes are not as important as the mostly invisible cultural elements. And it is the culture that is the essence of the “Spotify Model”.

So let’s take a moment to reverse engineer and decode the culture based on the publicly available information. To do this, I’ve used various videos and articles and relied heavily on a Henrik Kniberg video from 2014. Note that this is at least 5 years old and may describe approaches that are no longer being used by Spotify.

Reading the articles and watching the videos, you can discern the following key elements of the Spotify Culture. As you review this list, do a gut check. Are you doing this today? Would these approaches even fly at your company? What would it take to implement them? That may be the best test of whether you are anywhere near the “Spotify model”.

25 Cultural Elements You Can Divine about the “Spotify Model” of Agility

1. “Don’t scale agile…descale your organization.” Henrik starts with this quote which directly conflicts with the 5% of people who claim to be scaling agile using Spotify. It isn’t about changing agile to fit your company, it is changing your organization to achieve business agility. Q: Have you considered descaling your organization before scaling agile?
2. Your Company <> Spotify. Spotify was born agile in 2006 so it is not even 20 years old. And Spotify is small at roughly 1,500 people. Q: Is your company new, do you have thousands of people and a rich history of success doing things a certain way? Do you have layers and layers of rules and bureaucracy for the right way to do things, as well as plenty of checks and balances?
3. Spotify was on a Mission – The stated Spotify mission is to turn the music business upside down. Q: Does your company have a compelling purpose that aligns and motivates people?
4. Squad is equivalent to Scrum Team – Like Scrum teams, squads are cross-functional and self-organizing and they are responsible for end-to-end delivery of a complete project. Q: Are your “squads” self-organizing? Are they capable of end to end delivery or do you have handoffs to other teams or departments?
5. Squads are Autonomous – Autonomy is the key to the company. It includes not just what to work on next or how to complete their work. Autonomy helps to scale because they don’t need as much central function. Autonomy is fun and motivating. Q: Are the squads you created autonomous?
6. Motivation is Essential for Productivity – Kniberg talks about how important employee motivation is to resolving the inevitable environmental issues (see for example, Richard Sheridan’s Joy at Work). Motivation has a higher impact on productivity than any other factor. Kniberg has a simple formula showing that Productivity = Effort X Competence X Environment X Motivation^2. Q: Is your company focused on increasing the motivation of each employee?
7. Balance alignment and autonomy. Spotify strives to strike a balance between alignment (central direction) and autonomy (team self-organization). Managers paint the big picture but don’t tell people how to solve it. This is probably one of the biggest sticking points for most organizations – managers are directly involved in telling people how to solve problems. Q: Who makes decisions in your organization? What is the balance of power between team members and managers?
8. Shape the Environment – Physical space supports informal collaboration and coordination. At Spotify, Squads sit and work together. Tribes sit near each other and there are plenty of spaces for informal meetings without having to schedule a conference room. Q: Has your company made an effort to co-locate people working together on the same team or tribe? Does your physical space support informal meetings without going to the trouble to schedule a conference room?
9. No Magic in the terms Squads and Tribes – Henrik said he wasn’t sure why they used weird words like Squads and Tribes. The label itself means nothing. Each tribe is a cross-functional team that is vertically aligned for delivery. Q: Did you change your existing team to a squad without changing anything else?
10. Guilds are cross-cutting areas of Expertise – Guilds are the equivalent of Communities of Practice. They are not functional departments, they are volunteer-led communities based around a particular expertise. Q: Are your guilds communities based on expertise, or are they organized around key managers or existing functional departments?
11. Emphasis on face 2 face communications. That is the purpose of the structure of Tribes, Squads, and Guilds. They were formed based on the need to coordinate and collaborate. Tribes and Squads were organized so that they can sit together. Q: Does your organization put a priority on face to face communications?
12. Boring Releases – Long release cycles are scary and risky. Frequent releases are less scary, less risky and easy. They become routine and boring. Q: How often are you releasing to Production? Are your releases scary or are they boring?
13. Decoupled Releases and CI/CD Reduces Cycle Time – Spotify focused on changing the architecture to decouple dependencies and make releases easier. Dependencies are reduced and teams can release to production independent of each other. Spotify has also invested heavily in continuous delivery to automate getting code to production in minutes, not days or weeks. Q: On average, how long does it take to get from a changed line of code to that code live in production? Do you measure and track this?
14. Trust and the Self-Service Model – Spotify empowers and trusts people so that where possible, teams make decisions that involve risks. Kniberg uses the example of the difference in control between a roundabout and a typical traffic light. Where possible, Spotify trusts and supports people and doesn’t try to control them because they believe that most people are doing what is best for the organization. Q: What is the level of trust you place on your employees and teams? Are they empowered with opportunities for self-service (e.g. setting up new environments), or are there checks and balances and delays due to waiting for decisions/approvals that slow them down?
15. Transparency & short feedback loops – Transparency is one of the pillars of Scrum and essential for all agility. Transparency is also an enabler for self-organization. Similarly, short feedback loops provide opportunities for inspection and adaptation and they ensure teams are building the most valuable features. Q: How long are your sprints? What is the time between when a team builds something and when a real customer uses or provides feedback on that feature?
16. Managers are Servant Leaders – Spotify believes that managers are servant leaders, focused on serving the highest needs of the team. They think it is better for managers to ask teams how then can help, rather than asking people what they are working on or when they will be done. Q: What is the posture of your managers to your teams? Do they serve the teams, or do they think that the teams serve them?
17. Lean Startup – The Spotify mantra seems to be Think it, Build it, Tweak it, Ship it based on Eric Ries and the Lean Startup approach. Teams establish a hypothesis and then run experiments and A/B tests and measure the results. They strive to get lots of feedback, tweak what they implement and maximize the value. They know the difference between maximizing value and not just output (i.e. more user stories completed). Q: Are you set up to run small experiments? Or are your products/projects the result of a long list of requirements that are all built before deploying to production in a big bang?
18. Spotify Hack Week – Twice a year Spotify hosts a hack week where they let everyone work for a week on whatever they want. The approach unleashes creativity and improves cross-organizational collaboration They celebrate with a party on Friday. Q: How comfortable would your company be with a one-week hackathon that allows people to do whatever they want? What controls do you think your leaders would demand for that week (e.g. assigned work, time reporting, must show results, etc).
19. Experiment-friendly Culture – More data-driven decisions, not decisions made by the highest paid person. Teams are encouraged to develop a hypothesis and run an experiment. Teams establish “Keep List” which may include things like: Retros, daily standups, Google Drives, GIT, and Guild UnConferences. They also have a “Dump List”: Time Reports, Handoffs, Separate Test Teams or Test Phases, Task Estimates, Useless Meeting. Q: Do you allow teams the freedom to really change how they work? Which on the dump list above do you require your teams to do and why?
20. Healthy Cultures Heals Broken Process – Process breaks left and right but a healthy culture will lead to people fixing those problems. Q: How heavy is your process? Are teams allowed to change process or is the process dictated by a central Agile CoE or standards group?
21. Balance between Chaos and Bureaucracy – Like the balance between autonomy and alignment, Spotify is striking a balance between chaos and bureaucracy. Of the two, Kniberg believes it is easier to fix chaos than bureaucracy. Similar to Alistair Cockburn’s “barely sufficient” process guidance, Spotify came up with the concept of “minimum viable bureaucracy” or MVB. It is the smallest amount of bureaucracy that an organization can have without chaos. Q: What is the level of bureaucracy in your organization? Do your managers actively work to reduce or eliminate overhead so that teams can focus on being productive?
22. Team Definition of Awesome – Spotify encourages teams to talk about and decide what would make them awesome. After all, without a vision for awesomeness, you likely won’t get there. Spotify teams use regular team health checks and they track improvements over time. Q: Do your teams have a definition of awesome? Do you track team health and strive for continuous improvement?
23. Culture Beats Process – As we have outlined in this post, the obvious and observable processes you have are not nearly as important as the culture which may be nearly invisible. Culture is the behavior that is rewarded or what succeeds. Culture cannot be delegated by managers and leaders. Leaders need to model the behavior they want to see in an organization. Q: What are the behaviors that are rewarded in your organization? What are the behaviors that are modeled?
24. Employee Satisfaction – In the Spotify Engineering Culture video, Kniberg tells the amusing story of an email from the head of people operations about the results of a recent employee satisfaction survey. The head claimed that 91% of employees enjoyed working at Spotify, which he said was “of course not satisfactory”. Q: Do your leaders ask if people enjoy working at your company? What % satisfaction do you think your leadership and HR department consider acceptable?
25. Mistakes are OK – How mistakes are treated may be one of the best indicators of your culture. Mistakes are expected when you are pushing for innovation. Punishing mistakes leads to people hiding their mistakes. Daniel Ek (Spotify founder) said:

“We aim to make mistakes faster than anyone else”.

— Daniel Ek, Founder of Spotify

Spotify focuses on recovery from failure vs. avoiding failure. Learning is about making a mistake and learning from it. This Kniberg diagram illustrates it well:

Kniberg also refers to a number of advanced concepts related to failure recovery that are also explained in detail in the DevOps Handbook including:

• Failure friendly culture
• Fail Wall
• Blameless post mortems that lead to continuous improvement
• Skillful retrospective vs. blame sessions
• Limited blast radius – limiting the impact that any one failure could have on the entire system.

Q: How are mistakes treated in your organization? Do people get punished or are mistakes looked at as opportunities for learning and improvement? Are you set up to allow small mistakes?

Spotify is Not Agile Nirvana

I hope by now you have seen that agility at Spotify is a great deal more than just squads and tribes. In fact, the Spotify Model is the culture, and you could get there without squads and tribes. But you cannot get the so-called Spotify Model with just squads and tribes.

“In articles or talks like this it may come across that Spotify is some sort of agile nirvana where everything just works and that is simply not true.”

– Henrik Kniberg

Take Action

You can use the 25 elements mentioned above as a quick checklist. This is especially important if you believe you are already using the Spotify Model.

How many of the 25 cultural elements have you achieved in your organization? What would need to change to increase the number of YES’s you could claim?

This article originally appeared on Vitality Chicago’s Blog and has been republished with permission.

Business & Finance Articles on Business 2 Community

(69)