The Spotify Model for Scaling Agile

General
, ,
1

The Spotify model focuses on organizing around work and not necessarily processes and ceremonies. This gives an organization greater flexibility when it comes to how Squads work. Instead of requiring Squads to change how they do their work (“you must do scrum”), it focuses on aligning them with each other and driving towards individual team outcomes.

The Spotify model encourages autonomy and creativity by trusting people to complete the work they are doing in the way they see fit.

Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy. If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. If you simply rename teams to Squads, you’re just putting lipstick on a pig.

2
  • We renamed the “Scrum Master” to “Agile Coach” because we wanted servant leaders more than process masters.
  • A squad is a small, cross-functional, self-organizing team – usually less than 8 people.
  • Why is autonomy important? Well, because it’s motivating. Motivated people build better stuff. Autonomy makes us fast by letting decisions happen locally in the squad, instead of a bunch of managers, committees, and stuff. Helps us minimize hand-offs and waiting so we can scale without getting bogged down by dependencies and coordination.
  • Be autonomous, but don’t suboptimize!
  • Loosely coupled, Tightly aligned squads.
  • Alignment enables Autonomy.
  • Internal Open-source model and our culture is more about sharing than owning.
  • Anyone can edit any code, but we have a culture of peer code review.
  • We have a really strong culture of mutual respect. I keep hearing comments like “My colleagues are awesome!”. People often give credit to each other for great work, and seldom take credit for themselves. Considering how much talent we have here, there is surprisingly little ego.
  • Most organizational charts are an illusion, so our main focus is community, rather than hierarchical structures. We’ve found a strong enough community can get away with an informal, volatile structure. If you need to know exactly who is making decisions, you are in the wrong place.
  • Encourage small and frequent releases, and invest heavily in test automation and continuous delivery infrastructure. Release should be routine, not drama.
  • Regardless of the current structure, we always strive for a self-service model. Kind of like a buffet – the restaurant staff don’t serve you directly, they enable you to serve yourself. So we avoid hand-offs like the plague. For example, an operations squad, or client app squad, does not put code into production for people. Instead, their job is to make it easy for feature squads to put their own code into production.
  • Feature toggles – unmerged code hides problems and is a form of technical debt.
  • This may seem like a scary model letting each squad put their own stuff into production without any form of centralized control. And we do screw up sometimes. But, we’ve learned that trust is more important than control. Why would we hire someone who we don’t trust. Agile at scale requires trust at scale. And that means no politics. It also means no fear. Fear does not just kill trust, it kills innovation. Because if failure gets punished, people won’t dare try new things.
3
  • Internal OSS model
  • Since culture is all about the people, we focus on motivation, community, and trust, rather than structure and control.
  • Founder Daniel states: “We aim to make mistakes faster than anyone else.”
  • To build something cool, we will inevvitably make mistakes along the way, but each failure is also a learning.
  • Fail fast → Learn fast → Improve fast
  • Fail-friendly environment: Failure recovery > Failure avoidance
  • Failing without learning is … well, just failing.
  • Post mortem is not about who’s fault, but what did we learn, what will we change.
  • Ticket is not closed when problem solved, but when we have captured the learning, so we can avoid the same problem in the future. Fix the process, not just the product.
  • Continuous Improvement – Driven from below, Supported from above.
  • Limited Blast Radius
    • decouple architecture
    • problem only impacts a small part of the system, and not bring eveything down.
    • Gradual rollout
    • Gives squads courage to try stuff.
  • If everything is under control, you’re going too slow! – Mario Andretti (Formula 1 driver)
  • Lean Startup
    • Think it
    • Build it
    • Ship it
    • Tweak it
  • Idea/problem → Narrative & Prototype → MVP → Limited Release → Analyze Data → Full Release
  • Innovation > Predictability
    • 100% predictability = 0% innovation
  • 10% of time doing Hack Time
    • People are natural innovators, so just get out of their way and let them try things out.
  • Instead of arguing, lets try both and see what works.
    • more data-driven decisions and less opinion/ego/authority driven decisions.
  • Waste-repellent culture (lean)
    • If it works, keep it. Otherwise, dump it.
    • Keep
      • Reptrospectives
      • Daily standup
      • Google Docs
      • Git
      • Guild unconferences
    • Dump
      • Time reports
      • Handoffs
      • Separate test teams or test phases
      • Task estimates
      • Useless meetings
      • Corp BS
  • Big Projects (common form of waste)
    • Big project = Big risk
    • try hard to break big projects down into smaller efforts
    • Visual progress, Weekly Demo, Daily Sync
  • Key thing about reducing waste is to visualize it and talk about it often.
    • Improvement boards
  • Awesome is a direction, not a place.
  • Healthy culture heals broken process
  • Culture spreads through story telling.
    • Blog
    • Post-mortem
    • Demo
    • Lunch
  • Culture is the sum of everyone’s attitudes and actions.
    • Model the behavior you want to see.