Back in November, Spotify released a paper titled Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. I recently had a chance to chat with Henrik Kniberg, one of the coaches on site, to ask him some questions about the paper and to get an update on where they are today.
Infoq: What were the initial signs that what you were doing wasn't going to scale? What were some of the pain points?
Henrik Kniberg: We couldn’t get the productivity we wanted, and people in the organization were generally frustrated. For example, chapter leads were getting way too many direct-reports, so it was hard to find time to do 1:1 meetings, active mentoring, or coaching.
InfoQ: Who was involved in the early decision making on how you were going to scale and what were their roles in the organization?
Henrik Kniberg: Basically the senior leaders within Technology and Product worked together to figure things out. We then went to the organization for feedback and inspiration. It wasn’t a big re-make, more like a continuous stream of small iterative improvements to our organization and process. We have been growing for 3 years, and the way we work today has evolved naturally over time.
InfoQ: What led you to adopt this approach as opposed to using an existing scaling approach like Scaled Agile Framework or Disciplined Agile Delivery, etc.
Henrik Kniberg: We are huge fans of the agile & lean principles and fundamentals, but we are not closely attached to any specific set of practices or methods. We just want to work in a way that fits our culture and environment really well.
Autonomy is one of our guiding principles. We aim for independent squads that can each build and release products on their own without having to be tightly coordinated in a big agile framework. We try to avoid big projects altogether (when we can), and thereby minimize the need to coordinate work across many squads.
InfoQ: You mentioned that you have 30 squads over 3 cities. Are all the squads co-located or are there squads with members in separate cities?
Henrik Kniberg: Squads and tribes are co-located in the vast majority of cases. That is, all members of a squad are usually in the same room, and all squads in a tribe are usually next to each other in the same office. We have deliberately organized for this. We are particularly keen on making sure that the product owner is in the same location and room as the squad. Right now I can only think of one squad that isn’t co-located.
InfoQ: I noticed that the only tools shown were stickies and spreadsheets. Is Spotify using an existing Agile tool to co-ordinate their work? If not, why not?
Henrik Kniberg: We use a mix of tools, and are constantly experimenting with this. The most common coordination tools right now are stickies on the wall, google spreadsheets, and Jira. We also have a bit of Trello and LeanKit Kanban.
We encourage knowledge sharing and the spreading of best practices, but it is up to each squad and tribe to choose whatever tools make them happy and effective. By avoiding big projects, we also minimize the need to standardize our choice of tools.
InfoQ: You also show that several "squads" may own individual parts of the product (diagram on page 2), how is that handled and how is overall cohesion of the product handled (and code ownership).
Henrik Kniberg: The technical architecture is hugely important for the way we are organized. The organizational structure must play in harmony with the technical architecture. Many companies can’t use our way of working because their architecture won’t allow it.
We have invested a lot into getting an architecture that supports how we want to work (not the other way around); this has resulted in a tight ecosystem of components and apps, each running and evolving independently. The overall evolution of the ecosystem is guided by a powerful architectural vision.
We keep the product design cohesive by having senior product managers work tightly with squads, product owners, and designers. This coordination is tricky sometimes, and is one of our key challenges. Designers work directly with squads, but also spend at least 20% of their time working together with other designers to keep the overall product design consistent.
InfoQ: The image on page six seems to indicate a lot of dependencies, including UX as a separate team. How are those dependencies handled?
Henrik Kniberg: Dependencies are one of our challenges; the more dependencies we have, the less effective we become.
For example, UX used to be mostly separate, which caused dependency problems (as shown in our dependency visualization spreadsheet above). Now design and UX is mostly integrated into the squads, which has reduced the problem. This is one example of a dependency reduction strategy.
Here are some other dependency reduction strategies we use:
-
Decide where to put dependencies. For example, we have an intentional dependency from feature squads to infrastructure squads. This is managable, since infrastructure squads generally have more predictable delivery times. Instead of trying to eliminate that dependency, we try to become good at managing it.
-
Don’t wait for stuff that isn’t ready.Solve the problem yourself instead. We adopt an open source model, so a squad is allowed to make the changes they need in another squad’s code, usually combined with conversations and code reviews.
-
Knowledge sharing.Sometimes a dependency is caused by lack of knowledge. This is solved by internal tech talks, doing “internships” in another squad to learn from them, or shifting responsibilities between squads where it makes sense.
-
Persistent dependency problems are sometimes resolved by splitting, combining, or rearranging squads.
InfoQ: Any significant changes or updates since the paper was published?
Henrik Kniberg: We keep growing, so change is continuous.
One big step is that we’ve started becoming more clear about our product development process, see How Spotify builds products and the Think It, Build It, Ship It, Tweak It framework. We have also become more intentional about applying lean-startup principles, such as delivering an MVP (Minimum Viable Product) early, and using measurable hypotheses to drive product development. We are much better now at releasing the MVP to a small population of users to start learning from actual usage metrics. Hence, while building the product, we also get real user feedback and can adapt our priorities based on that.
InfoQ: What would you say is your biggest challenge now?
Henrik Kniberg: Some of our current challenges are:
-
Squad dependencies - how to minimize unnecessary dependencies, and optimize the necessary dependencies. This is always a challenge as the company grows.
-
How to balance between organizational focus (squads running in the same direction), and squad autonomy (squads getting to choose their own direction).
-
How to integrate design and development more tightly
-
How to avoid bottlenecking operations as the company grows, and enable squads to continuously deploy and experiment in production.
-
How to deal with “big projects” that involve the coordination of dozens of squads.
-
How to keep the product design cohesive while having many different squads working on it independently.