How Spotify does Agile
Spotify’s famously engineered agile practices have become the stuff of lean legend. The company is growing at a rapid rate and continues to employ its unique brand of agile methodology, which is intricately linked to its organic organisational culture.
Spotify’s agile story first emerged around this time in 2012, when Henrik Kniberg and Anders Ivarsson published their ‘Scaling Agile @ Spotify’ treatise featuring tribes, squads, chapters and guilds. For those of you who didn’t read the original publication, we thought we’d put together a short digest of their methods and practices.
While the agile methodology is reserved for software development teams in the one place, Spotify have gone to the trouble of ensuring every development team within the organisation operates on an agile level, despite having approximately 30 of them in three separate locations around the world.
How they scale agile
Back in 2012, agile coaches Kniberg and Ivarsson presented Spotify’s methods with a disclaimer stating that by the time you read about them, they would likely change and evolve. For now, until a massive update is produced, we can assume that Spotify is still following the majority of the 2012 protocol, including the naming patterns of their ‘alternative’ agile framework.
Squads are what Spotify call each basic team reporting to a Product Owner (PO). The PO prioritises the team’s work, but is not meant to be involved with how they do their work. Different squads take responsibility for different parts of the user experience and have their own space to collaborate and work.
Michael Thomas has called Spotify’s squad process a way to organise for autonomy, as each team was able to choose what they’d work on. POs from each squad work together to “maintain a high-level roadmap document that shows where Spotify as a whole is heading”, on top of being responsible for each squad’s backlog.
SEE ALSO: The Arrow – An advanced Kanban board
As for tribes, they are designated collections of squads who work together in related areas of the product. They’re also described as having an ample amount of freedom and autonomy regarding their work. Tribes contain up to 100 people or less in light of the suggested cognitive limit around social relationships described in the Dunbar’s number concept.
The dependency problem
Dependencies between squads can be a barrier to the autonomous environment that Spotify are trying to cultivate, however, they work regularly to communicate what dependencies exist. The focus then falls on how they can reorganise or reprioritise work to eliminate blocking and cross-tribe dependencies.
The dependency problem between development and operations was highlighted specifically by Kniberg and Ivarsson – there’s no specific ‘handoff’ between dev and ops:
At Spotify there is a separate operations team, but their job is not to make releases for the squads – their job is to give the squads the support they need to release code themselves; support in the form of infrastructure, scripts, and routines. They are, in a sense, “building the road to production”.
“If each squad was fully autonomous and had no communication with other squads, then what is the point of having a company?” That’s where chapters and guilds come in, designed to group together team members who share certain skill-sets and interests, says Ulf Eriksson.
A chapter exists within a tribe, bringing together people with similar skills and working within the same general competency area. They also have a chapter lead and regular chapter meetings to discuss their area of expertise and recent challenges they’ve faced, thus linking to the idea of less dependency.
Guilds aren’t localised to tribes and can span across many of them in the company – their aim is to pull together people with similar interests, as opposed to skills. Agile coaches also have a guild of their own in the organisation, where their experiences across different types of teams are shared.
It’s all about organisational culture
The thing that sets apart Spotify’s agile practices from other companies, aside from their creative naming structure, is the organisational culture behind the framework. While a good amount of variation exists in the processes used by individual teams, Eriksson states that their specific workflow proves the existence of a largely coherent and consistent engineering culture which is shared throughout the organisation.
A positive organisational culture is something that “grows organically”, with the dynamics between team members also a contributing factor. In saying that, Kniberg was quick to point out after the publication of his work that he didn’t “invent” Spotify’s agile processes:
Everything I do at Spotify (and other clients) is collaborative. As coach and mentor I have no formal authority, so I have to work with and through other people. The Spotify model is the result of a lot of people collaborating and experimenting over time, and many aspects of the model were invented without my involvement at all. I certainly wouldn’t want to take credit from the people involved.
Not only that, but the precise methodology that each squad follows is varied, depending on what they think works best for their crew. Some are Kanban inspired, some straight-up agile, some Scrum-based – they all differ in certain aspects.
The main takeaway is attributed to Spotify’s commitment to goals and locally-grown culture. According to Trevir Nath, employees and management must remain committed to the organisational structure that is linked intricately to their overall goals for continued agile success.