How Spotify Does Agile – A Look at The Spotify Engineering Culture

In this blog post, I‘ll present a case study showing the importance of a healthy culture to an agile organisation. The company in question is Spotify, a popular music streaming service headquartered in London and Stockholm, that is used by over 60 million users worldwide and employs over 1,200 team members.

The importance of company culture in an agile environment

According to Spotify consultant Henrik Kniberg, the Spotify engineering team originally adopted Scrum as their main agile methodology.

However, as the company started growing and splitting into various sub-teams, and their product became increasingly more complex, he says that they realised that certain Scrum principles actually prevented them from operating more effectively.

In the spirit of flexibility and experimentation which Agile encourages, Spotify’s engineering team decided to rewrite the rules and create their own agile methodology, which was heavily influenced by the values their company culture held dear.

How Spotify does it: 10 lessons for every agile organisation

#1 Agile coaches, squads and the importance of autonomy

One of the first changes they implemented was in the terminology used. The terms Scrum Master and teams were replaced with agile coach and squads, which consisted of no more than eight people who were given full autonomy to operate as a cross-functional and self-organising unit.

Each squad has end-to-end responsibility for the things they do, from design to deployment and beyond. Squads have both long-term missions that relate to the company as a whole, as well as internal goals which relate to the projects they’re working upon.

Autonomy in this context means having the freedom to decide:

What to build;
How to build it; and
How to work together while building it.

This autonomy isn’t absolute, however. The decisions a squad takes must naturally align with the squad’s long-term mission, their internal goals, overall product strategy and other short-term goals which are reviewed every quarter.

#2 Adjusting the outer environment to reflect what the company values

Squads work in an environment that is optimised to encourage collaboration. Members share the same work area and have access to shared lounges with white boards and so-called huddle rooms, for private meetings.

#3 Local decision-taking makes squads more productive

Autonomy is expressed in practice by giving squads the ability to bypass committees and layers of management and make and act upon the decisions the members reach together. This allows the company to scale easily without being held back by dependencies and coordination problems.

#4 High autonomy, high alignment

Spotify maps organisation cultures across a two-dimensional matrix that measures levels of autonomy on one axis and alignment on the other.

The ideal company culture falls in the top-right corner where both autonomy and alignment are high, meaning that the different squads all agree on a common challenge and will each pursue a solution to it to the best of their abilities.

The leaders job is to communicate the problem that needs to be solved. How that happens is entirely the squads’ hands.

#5 Cross-pollination of ideas and techniques

There can be as many work processes and tools used as there are Spotify squads. Each squad is free to experiment with any agile method they like, be it Scrum, Kanban or anything else, and there is no standard tools to speak of.

However, when a squad hits on a particularly effective system, this will tend to spread virally throughout the organisation and become adopted as a de facto standard for a period of time, much like a genetic mutation gradually appears in every member of a species as long as the environment makes it beneficial to have it.

#6 Mutual respect and sharing of credit

Kniberg notes how there people at Spotify show high levels of respect towards each other and freely and frequently praise their peers for their achievements. This helps keep the company maintain a positive atmosphere, one where each person feels like a valued member of the team.

#7 Constant motivation

Good enough is not good enough. Besides praising people, Spotify pushes them to achieve more and find ways to constantly improve not only the work process and environment as a whole, but also their unique contribution to it.

#8 Squads, Tribes, Chapters and Guilds

Spotify puts a premium on lightweight teams where people can easily migrate from one squad to another with the least inconvenience to all parties involved.

The company uses a fairly complex system whereby people are encouraged to align themselves in communities which share their same objectives (squads), work environment (tribes), skillsets (chapters), and interests (guilds).

#9 Community over hierarchy

Kniberg attributes Spotify’s success to its closely-knit community, where more importance is given to group autonomy over individual authority.

There is a place for leaders in their company structure, however he emphasises that this role is more accurately described by words like servant-leader, coach and mentor, rather than the more traditional boss or manager.

#10 Test automation and continuous delivery

In keeping with agile principles, Spotify believes that releasing new versions of a product should be routine and it encourages squads to be constantly adding new features to its product, no matter how small or incomplete they are.

The exact system they use is based on the concept of release trains and feature toggles. The former is a company-wide schedule which makes people aware of when the next batch of updates will be implemented, whereas the latter is a system which permits Spotify to partially or completely hide unfinished features so that they can observe how well it merges with other features in its current state.

Bonus Point: Set up a fail-friendly environment

We aim to make mistakes faster than everybody else. – Daniel Ek, Spotify Founder & CEO

Finally, Spotify encourages finding ways to ensure fast failure recovery rather than simply avoid failing at all. Some squads even use a fail wall where they publicly share their failures and whenever there is a failure, the squad conducts post-mortems and retrospectives which allows it to capture any learnings from the experience.

In order to remove the shame and stigma of failure and encourage experimentation, Spotify hosts several experimentation weeks, where people spend time building whatever strikes their fancy and then showcasing to their colleagues at the end of the event.

Besides removing fear, experimentation also promotes a data-driven approach to taking decisions, rather than having decisions taken on the basis of personal opinion, ego or authority.

In conclusion

As Spotify consultant Henrik Kniberg points out: there is a lot of variation in the process used by individual teams.

However, the specific workflow outlined above illustrated seems to apply to some degree or another to the majority of the teams at Spotify, proving the existence of a largely coherent and consistent engineering culture which is shared through the organisation.

There are volumes of resources out there about organisational cultures. People have studied them for years, trying to pinpoint the characteristics of a great culture, it’s contribution to productivity and success and how to build one in your office.

I’ve written a couple of blog posts about the subject as well. One article discusses the effects of agile on company culture and the other analyses the testers who take on the role of team leader.

The last word

Despite all the information about it, organisational culture is something which grows organically in a team and it is shaped by a host of external and internal factors, including the dynamics between team members.

While you can influence its development to a certain extent, mainly by modelling healthy communication in the team, it is the myriad unconscious decisions and actions that ultimately go on to create a company’s culture.

The information in this case study was adapted from a series of blog posts by Henrik Kniberg which originally appeared on Spotify’s official Engineering and Technology Blog. You can view the original posts here and here.