<img height="1" width="1" src="https://www.facebook.com/tr?id=2077527452260672&amp;ev=PageView &amp;noscript=1">

Scaling Agile@Spotify

What is Scaling Agile?
Scrum & XP were developed for small team environment where there was freedom to explore and innovate and most of the problems could be managed at team level. However, when we want to scale Agile to Enterprise level, Scrum and XP falls short, as usually teams are distributed, we need a bit of architecture, need more levels of planning, execution, demo, and retrospect, co-ordination across teams, more people (servant leaders) to solve enterprise level impediments, big room planning to accommodate all people across teams, frequent integration across teams, more product management as we need to deal with more requirements and need ‘Systems thinking’ kind for holistic approach.

Scrum shows the greatest promise, but was developed for small team. Hence for enterprise level of Agile, we need different framework, which is known as ‘Scaling framework’.


Popular Scaling Agile Framework

  • SAFe- Dean Leffingwell
  • Spotify with Squads, Tribes, Chapters & Guilds
  • LeSS- Craig Larman and Bas Vodde
  • DAD- Scott Ambler
  • Nexus- Ken Schwaber
  • Agility Scales- Jurgen Appelo

Spotify framework

Popularity of ‘Spotify’ Scaling framework is growing day-by-day, and lot of companies are implementing and enquiring about this framework.


How it started

Spotify is a Swedish music, podcast and video streaming company. When Spotify launched their first music play, Spotify were pretty much ‘Scrum’ company, and number of Agile teams were growing and they realized couple of scrum practices like ‘Sprint Planning’, ‘Task break down’, ‘Velocity’, ‘Estimation/Relative Estimation’ and Metrics like ‘Burndown chart’ was coming in their way. So, they decided these practices as ‘optional’. Every Squad can decide if these practices making sense to them.

Spotify framework is evolved from their continuous ‘Inspect and Adapt’. However now, ‘Spotify framework’ is among one of the most sought after ‘Scaling Agile framework’.


Let us deep dive Spotify framework


Squad:

  • (Similar to Agile Team)
  • Basic unit of development at Spotify is the ‘Squad’.  
  • Squad is small, co-located, self-organizing, cross-functional and ‘autonomous’. They do Design, Commit, Build, test, maintenance, operation and ‘release’ to production.
  • They use Scrum, Kanban, XP or mix of these approaches.
  • Squad size around 5, and less than 8 people
  • Each squad has long-term mission.
  • Squad decide what to build, how to build, and how to work together while building around the boundaries like Squad mission and product strategy.
  • Different squads take responsibility for different parts of the experience.
  • Squads are encouraged to apply ‘Lean Startup’ principles such as ‘MVP’ (minimum viable product), ‘Validated learning’ and A/B testing to find out what works and what not.

Squad Leader:

  • (Similar to Scrum Master)
  • Squad doesn’t have a formally appointed squad leader.
  • They believe having ‘Agile Coach’ makes more sense than ‘Scrum Master’.

Product Owner:

  • product owner is responsible for prioritizing the work to be done by the team, but is not involved with how they do their work.
  • Each product owner is responsible for maintaining a matching product backlog for their squad.
  • Product owners of different squads collaborate with each other to maintain a high-level roadmap document that shows where Spotify is heading.

Product Manager

  • Sets the Vision and Roadmap
  • Define and Prioritizes Features
  • Collaborates and sets expectations with Product Owners, stakeholders, Customers, architects
  • Accepts the Features as done

Agile Coach

  • A squad has access to an agile coach, who helps them evolve and improve their way of working. The coaches run Sprint Planning meetings, Retrospectives, one-to-one coaching.
  • Coaches are spread all over the organization, but share knowledge continuously and meet regularly to collaborate on the high level organizational improvement areas, which we track on an improvement board.


Tribe

  • (Similar to Agile Release Train in SAFe)
  • Tribe is a collection of squads that work in related areas.
  • Tribe is designed to be smaller than 100 people (based on ‘Dunbar number’)
  • The tribe can be seen as the “incubator” for the squad mini-startups, and have a fair degree of freedom and autonomy.
  • Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe.
  • The squads in a tribe are all physically in the same office, normally right next to each other, and the lounge areas nearby promote collaboration between the squads.

Tribe Lead

Each tribe has a ‘Tribe lead’, this is similar to ‘Release Train Engineer (RTE)’ role in SAFe


Chapter

Chapter is your small family of people having ‘similar skills’ and working within the same general ‘competency area’, (within the ‘same tribe’) 
Each chapter meets regularly to discuss their area of expertise and their specific challenges - for example the ‘testing chapter’, the ‘web developer chapter’ or the ‘backend chapter’.
chapter-1.png


Chapter Lead

  • Chapter lead is “Line manager” for his chapter members, with all the traditional responsibilities such as developing people, setting salaries, etc.
  • Chapter lead is also part of a squad and is involved in the day-to-day work, which helps him stay in touch with reality.

Guild

  • Guild is a more organic and wide-reaching “Community of Interest”, a group of people that want to share knowledge, tools, code, and practices. This is across ‘Tribes’.
  • Guild usually cuts across the whole organization.
  • A guild includes all the chapters working in that area and their members, for example the testing guild includes all the testers in all testing chapters, but anybody who is interested can join any guild.
    guild.png


Guild coordinator

Each guild has a “Guild Coordinator”.


Guild ‘Conference’

An open space event where all can discuss challenges and solutions within their field.


Definition of Done

Instead of ‘Definition of Done’, they have ‘Definition of Awesome’


Event/Ceremony

  • Iteration Planning: Optional, Squad can decide
  • Daily Standup: happens as mandatory ceremony
  • Retrospective: happens as mandatory ceremony, usually Agile Coach will facilitate
  • Demo: Tribes hold gatherings on a regular basis, an ‘informal’ get-together where they show the rest of the tribe (or whoever shows up) what they are working on, what they have delivered and what others can learn from what they are currently doing. This includes live demos of working software, new tools and techniques, cool hack-day projects,

Scrum of Scrum

  • Scrum of Scrums(SoS) is optional and happens on demand like Daily Sync-up

Daily Sync-up

If there are dependencies which require coordination of multiple squads, they had a ‘daily sync’ meeting where they identified and resolved dependencies between the squads, and used a board with sticky notes to keep track of unresolved dependencies.


Hack-days

  • To promote learning and innovation, each squad is encouraged to spend roughly 10% of their time on “hack days”.
  • During hack days people do whatever they want, typically trying out new ideas and sharing with their buddies.
  • Some teams do ‘one hack day’ every second week, others save up for a whole “hack week”.
  • Hack days are not only fun, they are also a great way to stay up-to-date with new tools and techniques and sometimes lead to important product innovations!

Work Space

  • Desk area- to sit together
  • Lounge area- collaboration
  • Huddle room- for quiet time
    workspace.png

Culture

  • Culture is all about people. ‘You’ are the culture. Culture equals Everyone’s Attitude and Actions. Believe in ‘Model the behavior, you want to see’.
  • Knowledge sharing, Cross-pollination
  • focus on Motivation, community and Trust, (trust@Scale)
  • Fail fast culture
  • Internal open-source model, (anyone can edit any code)
  • Instead of Celebrate failure or success, Celebrate Learning
  • No politics means no fear, Fear kills Innovation
  • Automate everything mindset
  • respect (‘’my colleague are awesome”); Ask for help
  • most effective communication is ‘informal’ communication
  • Minimum viable Bureaucracy, Least amount of structure
  • Good enough is not good enough, we need to keep improving
  • Story Telling’ is the powerful way of effective communication

Fail Fast

  • We aim to make mistakes faster than anyone else
  • Each failure is learning
  • ‘Fail fast, learn fast, improve fast’ is the strategy for long term success
  • We have fail-friendly environment
  • We celebrate Failure, we have ‘Fail Wall’
  • Instead of “Whose fault was it”, we focus on What did we learn? What will we change?
  • We do post mortem. Incident is closed only when we capture the “Learning”
  • If everything is under control, this meansyou are going too slow’

Experiment

  • Experiment friendly culture, Creative Freedom
  • Spend 10% on Hack days or/ Experiment
  • Believe in Knowledge gain and having Fun
  • Make ‘cool’ things real
  • Do whatever, with whoever, in whatever way
  • Demo and Party on Friday ☺
  • People are natural innovators, just get out of their way, and Let them try things out
  • Confusion about ‘Tool A or B?’, Let us try both and compare
  • What is hypothesis? What did we learn? What will we try next?

Lean Startup

  • Believe in ‘Think it, Build it, Ship it, Tweak it’
  • “Building the wrong things” could be the biggest problem. Need to think, whatever we are doing ‘Does it solve the real problems?’
  • Use Narrative like Elevator Pitch, hypothesis, version prototype
  • Focus on MVP, Intent-hypothesis-feedback loop

Release

  • Easy & Frequent Release, Release should be ‘routine not drama’
  • Test Automation, Continuous Delivery, Automated deployment
  • Decouple deployment from Release
  • Self-service model, Avoid hand-off
  • ‘Release Train’ is used to release stuff across Squads using ‘Feature toggle’ and ‘A/B testing’

Value @Spotify

  • Agile > Scrum
  • Principle > Practice
  • Agile Coach > Scrum Master
  • Servant Leader > Scrum Master
  • Squad > Team
  • Community >Structure
  • Cross-Pollination>Standardization
  • Failure Recovery > Failure avoidance
  • Impact > Velocity
  • Enable > Serve
  • Trust > Control
  • Innovation > Predictability, (100% Predictability == 0% Innovation )
  • Value Delivery > Plan fulfillment

Key principles

  • Be autonomous, but don’t sub-optimize
  • Loosely coupled, but tightly aligned squads
  • Alignment enable autonomy
    autonomy.png
  • Leader’s job: Communicating what problem need to be solved and why?
  • Squad’s job: Collaborate with each other to find the best solution.

Key Points:

  • Roles-Squad Leader, Agile Coach, Tribe Lead, Chapter Lead, Guild Coordinator, Product Owner, Product Manager, Product Lead, Tech Lead, Design Lead, Line Manager, System Owner, Chief Architect
  • Team Structure- Squad, Tribe, Release Train, Chapter, Guild
  • Events- Iteration Planning, SoS, Daily Sync, Weekly Demo, Retrospective, Hack-days, Conference

Optional in Spotify

  • Iteration Planning Meeting
  • Estimation
  • Velocity
  • Burn down chart
  • Task Break down

Conclusion
The Spotify model can help you to understand how things are done at Spotify, but you shouldn’t copy it in your own organization. It changes all the time as people at Spotify learn and discover new things. There is no one way in which software is developed at Spotify.

The way that Spotify develops software was first described by Henrik Kniberg and Anders Ivarsson in Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. I believe Spotify is one of best scaling model in current context, and it’s a great inspiration to start with.


Reference: Spotify engineering culture video from Henrik Kniberg and related docs.


Like this post? Share it with friends