SlideShare a Scribd company logo

Spotify Model

•
•
Ramanathan Yegyanarayanan
Ramanathan Yegyanarayanan

Spotify uses an agile framework called the Spotify model that focuses on autonomy, alignment, and frequent delivery. Key aspects include: - Organizing into autonomous Squads of 5-7 people that are cross-functional and self-organizing. - Squads have autonomy over what to build and how while being aligned to product goals. - Frequent releases in a continuous delivery model through decoupled architecture and gradual rollouts. - An emphasis on learning from failures through post-mortems and sharing lessons in "fail walls". - Continuous improvement through regular retrospectives and experimentation through "hack days".

1 of 48
Download to read offline
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
• 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
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.
Spotify Model
• Scrum framework weren’t work well for them • Made the Scrum roles, artifacts and events optional
• Renamed the Scrum Master to Agile Coach • Wanted “servant leaders” more than “process masters” • Renamed Scrum teams to Squads
Squads • Feel like a “Mini start-up” • Self-Organizing • Cross-Functional • 5-7 Engineers , less than 8-10 • Stable
• 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
Squad Area • Almost all walls at Spotify are a whiteboard. • Each Squad has their own space with a lounge and meeting room.
• 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
• The stronger alignment, the more autonomy we can afford to grant • “Autonomy with alignment increases motivation, quality and also fast releases.”
• Leader’s job: Communicate what problem needs to be solved, and why • Squad’s job: Collaborate with each squad to find the best solution
• 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
• 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
• Based on mutual respect and little ego
Spotify Model
• Culture that is focused on motivation • Helps them to build a very good reputation as a workplace
• 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.
• 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.
• 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
• 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.
• 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
• No fear, no politics! Keep experimenting Spotify!
Squad Health Check Model
Spotify Model
• 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
• 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?
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
• 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.
• 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
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
Product Development
Minimizing the need for predictability, Squads can focus on delivering value instead of being slaves of someone arbitrary plan.
• 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
Spotify Model
• quickly stop to do anything that doesn’t add value
• 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.
• 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
Spotify Model
• 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
Spotify Model
Spotify Model
Spotify Model
Spotify Model
Spotify Model
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
Spotify Model
Spotify Model

More Related Content

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!
  • 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
  • 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