Spotify Model

1. Ramanathan Yegyanarayanan
• Agile Enthusiast, Change Agent, Life Coach , Agile Coach
• Harvard ManageMentor® | ICP-ACC| ICP-TST| KSD|
KMP | CSP-SM ™ | CSP-PO ™ | CSM® | CSPO® | PSM I™
| CDA |SAFe® Agilist | CLB
Ramanathan Yegyanarayanan
@Ramanathan1989

2. • Spotify is a music streaming service
• Developed by Swedish company Spotify Technology
• Founded on 23 April 2006
• The service was launched on 7 October 2008
• 3000+ employees
• Available in 65 regions
• Headquartered in Stockholm, Sweden
• 180 Million users out of which 83 Million is paying
• Founders – Daniel Ek, Martin Lorentzon

3. Scaling @ Spotify
• Henrik Kniberg & Anders Ivarsson
https://www.linkedin.com/in/aivarsson/
https://www.linkedin.com/in/hkniberg/
@henrikkniberg
@anders_ivarsson
Disclaimer: We didn’t invent this model. Spotify is (like any good agile
company) evolving fast. This is only a snapshot of our current way of
working - a journey in progress, not a journey completed. By the time
you read this, things have already changed.

5. • Scrum framework weren’t work well for them
• Made the Scrum roles, artifacts and events optional

6. • Renamed the Scrum Master to Agile Coach
• Wanted “servant leaders” more than “process masters”
• Renamed Scrum teams to Squads

7. Squads
• Feel like a “Mini start-up”
• Self-Organizing
• Cross-Functional
• 5-7 Engineers , less than 8-10
• Stable

8. • Squad has autonomy to decide
• what to build,
• how to build it,
• how to work together while building it
• aligned with the Squad mission, product strategy, and short-term goals

9. Squad Area
• Almost all walls at Spotify are a whiteboard.
• Each Squad has their own space with a lounge and meeting room.

10. • Autonomy provides a sense of collective ownership
• People work with autonomy, mastery, and purpose
• Autonomy is motivating, and motivated
• People build things better and faster
• Autonomy makes us work better and faster
• Decisions are made locally instead of up the chain

11. • The stronger alignment, the more autonomy we can afford to
grant
• “Autonomy with alignment increases motivation, quality and
also fast releases.”

12. • Leader’s job: Communicate what problem needs to be solved, and
why
• Squad’s job: Collaborate with each squad to find the best solution

13. • Squads use a specific tool
• Tool becomes a path of less resistance
• Others Squads tend to choose the same tool
• After other Squads use the same tool, test it and collaborate
• The tool became a default standard

14. • Their culture is more sharing than owning
• Has a peer code review where anyone can add any code anytime.
• Peer can review the code and also make adjustments
• Everybody collaborates together and spread the knowledge

15. • Based on mutual respect and little ego

17. • Culture that is focused on motivation
• Helps them to build a very good reputation as a workplace

18. • Squad is grouped into Tribes that have Chapters
• Can switch your Squad without changing your manager
• Gathered by mailing list or another informal type of communication
• Tribe: Little weight matrix - primary dimension is focused on product delivery
and quality.
• Chapter: Competency areas such as quality assistance, Agile coaching or
web development.
• Guild: A lightweight community of interest where people across the whole
company gather and share knowledge of a specific area.
• Anyone can join or leave a Guild anytime.

19. • The main goal is to have a small and frequent release
• Invest in automation and continuous release infrastructure
• If releasing is hard, the release will be difficult.
• Although if releasing is easy, they can release often
• Instead of creating rules to manage the releasing process,
• Simplified it to encouraging small and frequent releases that became
routine.

20. • Changed the architecture to enable decoupled releases using the
encoded embedded framework
• Each section of the web browser is like a frame of a website where
each Squad can release their own stuff directly

21. • Three different Squads based on the self-service model
• Feature Squad: Focused on one feature area.
• Client App Squad: Focused on making the release easy in one
specific area platform.
• Infrastructure Squad: Focused on making other Squads more
effective providing tools and routines for Squads.

22. • Each client app has a release train
• Departs on regular schedule,
• Typically every week or every three weeks, depending on the client.
• The trains depart frequently and reliable
• Don’t need much upfront planning
• Interesting part of it is that Spotify releases hidden features
• A feature that isn’t 100% done was released and then hide this
feature. Why?
• Releasing unfinished features and hiding them exposed integration
problems early and minimized the need for code branching

23. • No fear, no politics! Keep experimenting Spotify!

24. Squad Health Check Model

26. • The idea behind the product development cycle
• Making mistakes and this is inevitable
• So, why not fail faster when we do fail?
• Each failure is also an opportunity to learn
• Validate our learnings!
• It’s a strategy for long-term success
• Interested in fast failure recovery than failure avoidance

27. • Failure without learning is just failure
• Squads have a “Fail Wall” to share their failures
• Gives everyone the opportunity to learn from other failures
• Fail fast > Learn fast > Improve fast!
• Fail-friendly Environment
• It’s never about who’s fault is it; it’s about what happened.
• What did we learn?
• It’s about what will we change?

28. Post Mortem
• It’s a process, usually performed at the conclusion of a project
• To determine and analyze elements of the project that were successful or
unsuccessful
• It’s a process of lessons learned and improvements which mitigate future risks
• “Fix the process not just the product”
• The ticket is not closed when the problem is solved. It’s really just closed when
they capture the learnings to avoid having the same problem in the future
Continuous Improvement
• Squads have retrospectives every few weeks to talk about what went well and
what to improve next
• The continuous improvement is driven from below and supported from above

29. • Gives Squads courage to do lots of small experiments and learn fast
from them, instead of wasting time predicting and controlling all risks in
advance.

30. • If any Squad makes a mistake, the only area impacted will be a small
part of the system.
• It won’t break everything down.
• Since every Squad has end-to-end responsibility for their stuff without
handouts, they can fix the problem very fast.
Via decoupled architecture

31. Via gradual rollout
• Most of the new features are rolled out gradually
• It starts with a tiny percent of users and is closely monitored
• Once the feature proves to be stable, Spotify will gradually roll it out to the
rest of the world.
• So if something goes wrong, it normally affects very few end-users for very
short periods of time

32. Product Development

33. Minimizing the need for predictability, Squads can focus on delivering value instead of
being slaves of someone arbitrary plan.

34. • An amazing product idea starts with a person and an inspiration
• Encourages everyone to spend 10% of their time doing hack days or hack
weeks playing around and experimenting
• The knowledge is worth more than the hack itself
• Demo + Party on Fridays

36. • quickly stop to do anything that doesn’t add value

37. • Big projects also mean big risks, break into smaller efforts.
• Practices to minimize the risks and waste of a big project.
• Visual progress in a physical or electronic board like Kanban;
• Daily sync meeting with all Squads involved meeting up to resolve
dependencies;
• Weekly demo where all the pieces come together to evaluate
integrated product together with stakeholders.
• Collaboration in a short feedback loop.

38. • Minimal viable bureaucracy
• Goal is to get the least structure and bureaucracy in place to get away from
total chaos
• Both sides, bureaucracy and chaos, cause waste in different ways
• The waste repels culture, and Agile mindset helps them to stay balanced

40. • Being awesome helps improve focus, efforts and track progress
• Each Squad has a definition of awesome that can be built, tested, and
shipped quickly, sometimes within a week
• It doesn’t have to be realistic,
• It can be what they agree awesome looks like

46. References
• https://medium.com/project-management-learnings/spotify-squad-
framework-part-i-8f74bcfcd761
• https://medium.com/project-management-learnings/spotify-squad-
framework-part-ii-c5d4b9398c30
• https://medium.com/the-ready/how-to-build-your-own-spotify-model-
dce98025d32f
• https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
• https://www.infoq.com/news/2016/10/no-spotify-model
• https://www.agilealliance.org/wp-content/uploads/2016/10/An-Outsider-
Assessment-of-Spotify-Engineering-Culture-by-an-Insider.pdf
• http://www.agilecio.net/blog/2018/2/18/how-to-build-your-own-spotify-model
• https://agilestrides.com/2016/06/13/i-dont-want-to-implement-the-spotify-
model/
• https://www.quora.com/What-is-the-Spotify-model-in-Agile
• http://www.full-stackagile.com/2016/02/14/team-organisation-squads-
chapters-tribes-and-guilds/
• https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf