What is Scaling Agile?
Scrum and XP were developed for a small team environment where there was freedom to explore and innovate, and most of the problems can be managed at the team level. When we want to scale Agile to Enterprise level, Scrum and XP fall short, as usually teams are distributed. We need a bit of architecture, need more levels of planning, execution, demo, and retrospect, coordination across teams, more people (servant leaders) to solve enterprise level impediments, big room planning to accommodate all people across organizations, 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 most significant promise which was developed for a small team. Hence for an enterprise level of Agile, we need a different framework, which is known as the ‘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
The popularity of the ‘Spotify’ Scaling framework is growing day-by-day, and a lot of companies are implementing and enquiring about this framework.
How it started?
Spotify is a Swedish music, podcasts, and video streaming company. When Spotify launched their first music play, Spotify was pretty much ‘Scrum’ company, and number of Agile teams were growing and they realized a couple of scrum practices like ‘Sprint Planning’, ‘Task breakdown’, ‘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 were 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 into the Spotify framework.
Squad:
(Similar to Agile Team)
- The basic unit of development at Spotify is the ‘Squad.’
- The 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 a mix of these approaches.
- Squad size around 5, and less than eight people
- Each Squad has a long-term mission.
- Squad decides 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)
- The Squad doesn’t have a formally appointed squad leader.
- They believe having ‘Agile Coach’ makes more sense than ‘Scrum Master.’
Product Owner:
- The product owner is responsible for prioritizing the work to be done by the team but is not involved with how they do their job.
- Each product owner is responsible for maintaining a matching product backlog for their Squad.
- Product owners of different squads collaborate 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)
- The tribe is a collection of squads that work in related areas.
- A 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, usually 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
The 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 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
- A 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 interested can join any guild.
Guild coordinator
Each guild has a “Guild Coordinator.”
Guild ‘Conference’
It is 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 a mandatory ceremony
- Retrospective: happens as necessary ceremony, usually Agile Coach will facilitate
- Demo: Tribes hold gatherings regularly, 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 that 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, and others save up for a whole “hack week.”
- Hack days are not only fun, but they are also a great way to stay up-to-date with new tools and techniques and sometimes lead to essential product innovations!
Work Space
- Desk area- to sit together
- Lounge area- collaboration
- Huddle room- for quiet time
Culture
- Culture is all about people. ‘You’ are the culture. Culture equals Everyone’s Attitude and Actions. Believe in ‘Model the behavior, and 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, and 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
- ‘Storytelling’ is the dominant 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 a strategy for long term success
- We have a fail-friendly environment
- We celebrate Failure and have ‘Fail Wall.’
- Instead of “Whose fault was it,” we focus on What did we learn? What will we change?
- We do post mortem. The incident is closed when we capture “Learning.”
- If everything is under control, this means ‘you 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, 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 the 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 enables autonomy
- Leader’s job: Communicating what problem need to be solved and why?
- Squad’s job: Collaborate 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 Breakdown
Conclusion
The Spotify model can help you to understand how things are done at Spotify, but you shouldn’t copy it in your 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 and Guilds. I believe Spotify is one of the best scaling models in the current context, and it’s a great inspiration to start with.
Reference: Spotify engineering culture video from Henrik Kniberg and related docs.
All frameworks don’t work well like Agile- a story that proves the same:
One of the most impressive business growth stories in the past few years has been Spotify’s. From a niche product for music aficionados to a company valued at $50 billion, it’s been quite the ride for the audio streaming giant.
But in the process, they made one mis-step which offers lessons to anyone interested in Scaling Agile. For at one point, Spotify made scrum optional to their operations. They even created their own framework to aid development. It was called the Spotify Squad Framework.
In this approach, a squad is made of eight or lesser number of people, each having a specific objective to meet or product to build. They mostly had short-term goals and were given the power to make local decisions; all these in the pursuit of one goal- to thrive in a rapidly changing socio-technological environment.
But something went wrong. So much so that the company has now abandoned the framework entirely. This puts the power of Agile framework in perspective, and points at the difficulty in devising such frameworks.
Learn more about the rise and fall of Spotify Squad Framework here from our friend Jean Inovejas at TryChameleon:
“Last week we published Why Spotify Squads Are a Popular Failure for Product Teams – we spoke to product leaders at Atlassian and Nasko's Growth Design Studio to learn more about how they applied the Spotify Squad Framework and share their top tips.”
Editor’s note: Original blog was published on Sep 7, 2017
Please Visit Remote Training Calendar