The most important inventions of Spotify

Spotify’s published principles are intriguing to many. Probably a major factor in why agility just works at Spotify.

I add my own interpretation. I also only know Henrik Kniberg’s public presentation at various conferences, hence my insert: it’s another interpretation.

For me, the success can be traced back to one key reason: Agile Mindset is a matter for the boss and is consistently lived out, e.g. in a rigorous focus on employee satisfaction. This has probably led to a very mature and responsible organization.

Beyond that, there are two key inventions that impressed me: Radical Loose Coupling and Scaling Trust.

Loose coupling

Teams (yes, they’re not called teams anymore, but still) can work very autonomously because Spotify has developed a policy to minimize code dependencies. In addition, one can clone and further edit another team’s code. A synchronous dependency, and thus a potential blocker, becomes an asynchronous task of regularly reconsolidating. As I said, a solution of a mature Organsiation.

Scaling trust

What is the source of credibility and trust? From proven competence, transparency, common goals and regular exchange. With the guilds and tribes, Spotify has the structures to live such an exchange and to regularly question the competence and transparency.

Full-time scrum master?

At Spotify, not every team has a full-time Scrum Master anymore – instead, they can call on coaches if they feel they need one. An example for me would be conflict mediation, or addressing an external issue that needs to be escalated.

This also corresponds to my experience in many teams: they need someone to keep the exchange going on a regular basis, an experienced team can handle most other tasks themselves.

Aligned Autonomy

Alignment is a prerequisite for autonomy – that’s one of the phrases that has come out of the Spotify environment. Yes, true – I agree and still put the context of focus. More on this in an earlier blog post.

Distribution

There are now several agile implementations that draw on the Spotify model. I have my problems with this: first, the authors deny that there is a general and well-defined Spotify framework. Second, I see a tendency to adopt only the nomenclature and overlook the mindset part. I don’t care if someone renames teams – but I dare to doubt whether a new choice of words is really purposeful.