(UPDATE: see Spotify Engineering Culture, two short animated videos showing how we work)
Dealing with multiple teams in a product development organization is always a challenge!
One of the most impressive examples I’ve seen so far is Spotify. I’ve had the pleasure of working with Spotify on and off ever since the company was founded, and it’s one of the few companies I’ve seen with a truly agile culture. Spotify has grown a lot lately and now has hundreds of developers divided into 30 agile teams spread over 4 cities in 3 timezones. So how is this managed?
Check out the article: Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. I wrote it together with Anders Ivarsson, one of the agile coaches that I’m working with (Spotify has a truly awesome group of coaches!).
149 responses on “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”
Very interesting reading. Thanks Henrik and Anders for publishing it .
How that snapshot of Spottify way of working emerged in the time, what forces where at work and who contributed ?
Are there differences in practices, way of working, organization among different squads or different tribes ? What caused them ?
great article. especially the idea of “a guild” as a crossteam entity. a cool name for a cool idea.
Very interesting reading…
I face similar challenges being responsible for the development of direct channels in a major Belgian Bank.
One question I’m still left with: how do you deal with maintainance on delivered software especially if this adds up to about 30% of all work. Separate it in a separate squad?
Squads do their own maintainance. There’s no handoff to another squad, that’s just expensive and breaks the learning loop. Programmers need to live with the consequences of their design decisions.
I work with an Indian start up and we are looking at creating an efficient Org structure. I’ve been reading your articles and wanted to reach out to you in this connection. Do let me know if we can catch up over mail or a call.
Great post! One thing I was surprised with is the “operation” squad which seems to be not a feature team. Also aren’t the members of this squad disappointed being a “servant” team and not producing the external features?
The people in ops do ops stuff because it is their job, because that is what they love doing, and that is why they came to Spotify to do it. The ops folks are heros, they enable everyone else to put stuff into production, and keep the systems running 24/7.
It is a very interesting article. I have translated it into french :
Agilité à grande échelle chez Spotify
Wow, thanks! I added a link to your translation.
Your article mentioned that user experience decisions were left to the squad, and I was curious how you’ve gone about staffing that need for each squad. That’s something that my organization has grappled with since adopting Scrum in 2004. We’ve waffled back-and-forth between putting user experience/design members on the teams and creating a central team composed entirely of functional design and user experience. Does every squad have a dedicated member for these functions? If not, how many squads do they typically get split across? Have any of your squad members taken on UX/design responsibilities with little or no prior experience? Do you encourage that?
We’re still waffling around with this, will have to get back on this topic later :o)
Oh, good, it’s not just us 🙂
Do you have any updated insights on how Spotify incorporates UX into the squads? Currently, I manage a UX team and have UX functional members working within each scrum team and am curious how Spotify handles functional UX and ensures a cohesive user experience across all of the separate squads/tribes.
It’s been a while since you posted a response to this, Henrik. Any updates?
I would love to have an update to this as well, it’s been a while!
Great post! I really like the clearity both in the vertical(Sqaud, tribes) and horizontal(Guild, Chapter). Have some what the same type of setup in my organization but not that clear…
I really like the idea of “quarterly survey with each squad” a good tool help the team to be high performing.
Now to my question:
How is the process for a squad to take a new feature from customer requirement to production?
At what sync points do sqaud and stakeholders meet up?
Great post and article, thanks for posting!! Could you share some information about any tooling is used to help facilitate/manage Spotify’s process(s)?
Great article. I translated it to Spanish:
Agilidad en Spotify
I like this article!
I notice that the idea of “guilds” is spreading. Maybe you want to have a look at Jurgen’s post about that: http://www.noop.nl/2012/11/business-guilds.html
I practice this idea having cross-team (knowledge-) “domains” with experienced “domain owners” guiding and leading it.
This is link to Russian translation:
Масштабирование Agile в Spotify
Thanks Askhat! I added it to the list of translations above.
Great article thanks you. I love being a Scrum Master/Iteration Manager and I want to work for a company that has a true Agile Culture. Can you get my resume in front of them. 😉
Try http://www.spotify.com/jobs/ 🙂
P.S. Happy New Year!
Interesting article. My question is how you support this process electronically? I like JIRA + green-hopper, but I am not sure it is the right one to support the full process.
Completely love it! This is the type of org I am constantly guiding companies toward but not always with success. 🙁 Thanks for providing a case study I can use to fuel my efforts.
Question: Can you share a sketch of a typical squad area floor plan? How is the desk area, lounge area, and a personal “huddle” room configured?
Here’s a sketch of a typical squad floorplan:
Thanks! That’s great. We have something similar. We have tables instead of desks and the tables face each other in an type of island.
One other question:
The quarterly survey – do you have an Excel template for that or do you just hand make all the arrow selection each quarter?
There’s a Portuguese version at http://www.infoq.com/br/articles/spotify-escalando-agile but the link doesn’t seem to be here yet.
Thanks, I added the link now.
Awesome! That’s a fantastic approach, Henrik! Thanks so much for sharing.
I’m curious how the rest of the company (Management, Sales, Marketing,..) is organized?
Are they structured in Squads and tribes as well or are they organized in a classic way?
A further point that interests me: Is the a kind of PO lead who coordinates or even leads the POs? (Deciding on the high level road map) Or are the POs organizing themselves collaborately?
And a last one:
Has the tribe lead any influence or saying on the road map or is she “only” responsible for the squads container?
Happy about your answers.
I am an Agile Coach in a large IT department of an even larger organization. I have read this article with great interest. Our organization started a full department transformation to Scrum last winter and we continue to look for ways to improve this ongoing transformation to make our organization more Agile. I’ve discussed this article with a number of people in my organization and I get 2 consistent pieces of feedback on the topic of Chapters Leads as line managers (I also get lots of feedback on other pieces of the article, but that’s another story)
1. Many in our organization still have a higher affinity for their functional role relationships than team membership, re: still lots of functional silo thinking. Having Chapter Leads could entrench that behavior further.
2. If a person’s line manager is on a different team, then they aren’t involved in the day to day with that person. The concern is around the ability of the Chapter Lead to evaluate the individual’s performance and/or know them well enough to help them with personal/career development.
My response to this feedback has generally followed these concepts…
1. Leadership and Agile Coaches need to a better job of breaking down functional silos whether we try something like this or not. If we do a great job of it, then this becomes much less of an issue (or a non issue).
2. If we change our focus from “evaluate and develop individuals” to “evaluate teams and develop the individual” then this concept might actually be a strength. Since the person developing an individual still has the same type of responsibilities as the individual, as opposed to someone that used to (maybe) have that same job in the past.
I believe that are a number of benefits to this approach that outweigh these concerns. However, I was wondering if you (or any of your readers) have additional feedback on ways to minimize these concerns.
Hi Jason, thanks for the detailed and insightful feedback. The short answer is that we sometimes see the problems that you mention, but so far the advantages of this model seem to outweigh the disadvantages. We also compensate for the disadvantages by making sure that the chapter lead is physically close to his chapter members, although they are spread across different squads, and that each chapter is quite small. The chapter lead does not oversee or judge the day-to-day work of the chapter members, instead he focuses on things like craftmanship, personal development and motivation.
Thank you Henrik for your speedy response. I can definitely see how small chapters with squads being adjacently (or at least very close) can help minimize these concerns.
As a Scrum Trainer once told me, evaluate teams and have the team evaluate the members of the team. With these two points of reference you get a more accurate and agile compatible appraisal of an individual compared to just a manager judging a team member completely outside the team context.
Your comment about chapter leads developing competencies of but not judging an individual is another data point in favor of separating (to some degree) development from evaluation. Your feedback is greatly appreciated.
I’ve just published “Scaling agile @ spotify” Japanese version. http://lean-trenches.com/scaling-agile-at-spotify-ja/ It’s very interesting article. Thanks, Henrik.
Thanks for translating! I added a link above.
Chinese version for scaling agile of Spotify is ready on my blog, http://bobjiang.com/2014/02/07/scaling-agile-spotify-with-tribes-squads-chapters-guilds/ , could you add a link here? Thanks a lot 🙂
Thanks for translating! I’ve added the link.
Italian version here: https://www.dropbox.com/s/b9urjkxsgq2zbe8/ScalingSpotifyIta.pdf
Thanks, I’ve added a link to your translation!
Thanks for every other informative website.
The place else may just I get that type of info written in such an ideal approach?
I’ve a undertaking that I am simply now running on, and I
have been at the glance out for such information.
So what happens when a major incident occurs? Who does the user call and how does whoever responds link back to this structure? How do you address data or security audit issues?
I love the article and the organizational model.
Are the tribe leaders mainly focused on engineering, architecture, and organizational health? Or do they also own the tribe’s part of the overarching product roadmap?
Hello Mr. Kniberg,
I have a few questions regarding the Squad Health Check model you used at Spotify, specifically; how did you develop the 11 health areas identified in model (support, teamwork, pawns or players, mission, health of codebase, suitable process, delivering value, learning, speed, easy to release, fun)?
Do you have any published literature reviews to validate your mythology?
I are very interested in utilizing a team health check program and would like to implement your model. Please let me know if you can provide any further information with your health check model.
Hi, is there any type of online tool you could share that could help to visually organize tribes and squads? Thanks!
We have embarked on the transition to the SAFe framework and introduced the tribe concept as well. Tribe lead roles were created, my question is what should the main responsibilities be for the tribe leads ?
I don’t can access the article Scaling Agile @ Spotify. I recive a 404 error from Dropbox. You have another link? I search on google but, dont found.
Link is fixed now: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
The English version has been removed from Dropbox. Where is the file now available?
Link is fixed now: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
The tribe-squad concept is fantastic and a kind of evolution in Agile. We partially used a similar idea where squads were known as feature teams and a solution team comprised of multiple features. Also, the scrum masters led the features whereas the managers owned the whole solution.
What methodology was used to introduce these concepts, gain buy-in from component teams, and measure acceptance and buy-in to these concepts? The end-state or snap-shot in time is a beautiful thing. But understanding what mechanisms were used to influence entrenched personalities and the steps and iterations to get there is where the magic happens.
Thank you for the consideration.
Very interesting and informative reading. Thanks, for publishing it.
Great article, thanks for sharing! You touched on how Ops teams fit in, but is there any more info on how you marry this kind of agile approach with a team that is purely Operational?
Is there an updated version? I see this says Oct 2012.
Hi Henrik, I have 2 questions, and ask for your advice, Thank you!
1. After you published the Scaling Agile @ Spotify in 2012, is there any major differences up to now, 7 years later? Would you still revisit Spotify now?
2. We’re Agile consulting company from China. We’ve referred to the Spotify model and implemented the tribe/squad in some banks, seems the chapter/guild is a bit difficult for local implementation. But we use CoP(Community of Practice) to do sharing across tribes/squads, and keep the line managers to evaluate the people’s performance. Do you have any suggestions on this?
Thank you again, and have a nice day!
Very nice article. keep it up Henrik.
Thanks for sharing nice Article . It is very valuable information.
Great learning , Please add some more info on Agile implementaiton
thank you ..such a great post