Spotify started as a Scrum company but as they grew the Scrum practices got in the way. They began to break the rules to fit their company’s growth. First Scrum Masters became Agile Coaches. Then they changed their Scrum teams to squads that own the process from start to finish. Each squad has a long-term mission along with autonomy on how to go about that. The squad has boundaries they must adhere to around their mission and product strategy as well as short-term goals.
Offices are optimized for productivity with a close working space as well as a lounge for fun and meeting space. They have found that giving people more autonomy gives people greater enjoyment and makes the company faster to respond to change. Decisions are handled locally so the squadron can respond quickly. There is an overall mission for all teams to move toward. They use the analogy of a jazz band in which the players listen to each other but make their own music.
“Loosely coupled, but tightly aligned” is how they describe how the squadrons work together. The work at Spotify is highly aligned and highly autonomous, wherein each squadron can choose how to meet their overall objective.
Cross pollination > Standardization
Spotify does not have formal standards on how they do development. Each team has their own way of doing things. Ideas may pass from team to team via cross-pollination as the squadrons communicate with each other.
The overall architecture is composed of small services that each team owns from front to back. If a team need something from another team they can ask the other team if they have the time or edit the code themselves.
Community > Structure
Each employee is a member of a Squadron; many Squadrons make up a Tribe. Overall the corporate groupings are very fluid and can change often. They strive to build a strong community instead of a rigid corporate structure.
Small Frequent Releases
They focus on making releasing code easier and do it more often. This is the opposite of the typical Waterfall environment where releases are big, seldom happen, and can be painful. They want releases to be common and routine, not rare and dramatic.
Release Trains and Feature Toggles
Each application at Spotify has a release train that happens at a regular interval. If a feature is not complete when the train leaves, the feature is used to shut it off. The feature toggles work to hide code in testing and production environments. This also helps alleviate issues with merging code as it is always checked in one place.
Failure is important
At Spotify, they talk about how the founder, Daniel Ek, has said, “We aim to make mistakes faster than anyone else.” They want to fail fast to learn fast and improve fast. Spotify tries to create a fail-friendly atmosphere where they put emphasis on failure recovery rather than failure avoidance. By conducting a post-mortem after each failure, they try to capture all lessons learned.
The Spotify applications are architected with decoupled components to use the “Limited Blast Radius” method. If something blows up it does not affect other components. They also use gradual rollouts to allow only a few people to see a new feature. This contains failure and is measured with monitoring and metrics. Each team performs small experiments constantly and reacts to them.
Before they build a new feature they start with an idea or problem and develop the narrative around it. Then they ask questions such as, “Would anyone want this?” and “Does this provide value?” From their using Lean Startup principles, they build the Minimum Viable Product or MVP. Releasing it to a small number of people, they test it out. By analyzing data and tweaking the prototype, they may eventually roll the feature out completely.
One interesting thing that Spotify values is Innovation over Predictability. They do very little planning to allow for more experiments and innovation. The squads have more freedom this way to achieve overall objectives and create new value.