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.
4.
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
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
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
39.
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
