NEXUS vs Spotify Squads, Chapters, Tribes and Guilds
Hello, as we know Scrum is part of Agile, and empiric approach which is based on adaptation and learning from expiense
In a past years Spotify has successfully adapted Scrum using their own way of scaling Scrum, particularly the system of Squads, Chapters, Tribes and Guilds which is much less rigid compared to NEXUS, and is allowing higher profits
System is not going against actual Scrum guide, dealing with dependencies between team in its own unique way.
Would be interesting to see the discussion about practitioners who used both practices and also tried to combine them.
Hi Nicholas,
I listened to Lenny's podcast the other day. It was an interview with the Spotify CTO. One of the topics was about moving away from the Spotify Model to a more 'structured' command and control model. The overriding reasoning is that self-organising teams at scale were not working for Spotify.
See:
https://www.lennyspodcast.com/lessons-from-scaling-spotify-the-science-…
Kind of an irony that Spotify is moving away from the Spotify model.
Cheers - Ash
I have never used Spotify scaling but I also couldn't find a good description of it. Probably haven't searched well enough. Can you refer any?
As far as Nexus, I like that it is very minimal in terms of adding on top of Scrum. I also like the Nexus Integration Team has daily meetings and it consists of Scrum Teams delegates. In extreme cases, you may even have everybody attending Nexus daily if needed.
Regardless of the framework, the huge impact for me was always in the product itself and the technical solutions. If the code is poorly structured, the CI is not well established, the regression test is minimally automated or not at all, no matter the framework it is going to be very very hard. You may need to stick to the component teams and there is no way to have feature teams able to deliver value independently any time soon.
With Nexus, even if you need to stick to component teams, they can cooperate very closely and inspect and adapt through the Nexus integration team on a daily basis. Also, the Nexus integration team can be in charge of fixing the product problems which are holding them from restructuring to feature teams.
I am guessing that in the case of Spotify, the product is well structured, the CI/CD is well maintained the feature teams can deliver value independently etc...
Here is a very good article about the Spotify Scrum scaling
https://achardypm.medium.com/agile-team-organisation-squads-chapters-tribes-and-guilds-80932ace0fdc
There is also an article on the website of Atlassian about this
Actually, Spotify never successfully implemented their model. There have been a few articles published about how it never worked for them. Here is one written by a former Product Owner at Spotify that quotes some of the Agile Coaches that were part of the creation of that model. (https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model). You also search for "does spotify still use the spotify model" in your favorite search engine and find others. Based upon your posts in this forum, I think this will resonate to you.
I have used some of the concepts from the Spotify theoretical model. I used their "tribe" concept and created communities of interest where people with interest in specific topics would share ideas and come up with some standards that would be used across teams. Think of UX designs or search algorithms as examples.
I have also worked at more than one company as an Engineering Manager where I had the personnel management responsibilities across multiple Scrum Teams. As we all know, self-organization and self-management can be successful for the work that is done. But because almost every company has a hierarchy of job titles, there is still need for that type of management work. At a couple of the companies I had responsibility for the Quality Assurance practices and had employees imbedded in multiple Scrum teams. At others I had the responsibility for all of the different disciplines within specific teams.
I worked for one company that wanted to use the Spotify model. I was the "most knowledgeable agile person" (actual quote from one of the C-staff) at the company so they asked me to help the transition. That is when I started questioning the viability of the model. I could see it working in a early stage startup or very small (less than 50 people) but even then I felt it would need some modifications. We never implemented the model but we did use parts of it combined with some of Scrum, KANBAN, eXtreme Programming, LEAN to build our own way of operating.
The scaling methods of Nexus, SAFe, Scrum at Scale take into account the challenges of larger companies. I still suggest that people learn about the Spotify Model but I encourage them to read about why it didn't work for Spotify. After all, in order to have agility you have to be able to learn. Sometimes you can learn a lot from other's mistakes.