A while back Henrik Kniberg published an excellent case study on Scaling Agile @ Spotify. Though the case study is specific to Agile scaling experiences at Spotify, I found some practices that are equally important for not so large teams. This post tries to capture those practices from a smaller team’s perspective.

Break Silos

A lot of organizations still work in functional silos. So for a bank IT system, there may be one team for web banking, another team for home-loans, and yet another one for mainframe-based core-banking. Business features however in general cut across all these teams.

For instance, if feature FA needs to be completed in the above picture, Team 1 to 3 take the related slice of the feature into their backlog. Product owners of each team drive the prioritization of these backlog items. So if Team 1 finishes its part of FA, it doesn’t mean Team 2 or 3 to finish their part as well with similar priority. Multiple hand-offs translate into waste and in the current case that waste is a delay. The feature may transcend to multiple releases just because of additional delay. Another important question, who is responsible for end to end testing?


Compare the above scenario with a feature team consisting of team members from each individual team. As priority and goal for all team member is same (finishing FA) and handoffs are reduced, the same feature gets delivered early.

Silos introduce delay and complexity. The idea of having a feature-driven cross-functional team (the idea of Spotify Squad) provides the desired solution. Together their focus is feature completion which is very delivered faster because of the absence of any delay.

The community of Interest for Knowledge Sharing

Cross-functional teams are good. However, if individual component (say web banking) members are scattered among multiple cross-functional teams and working on the same component code-base at the same time, how to coordinate the following:

  • Component architectural sanctity
  • Discuss the problems faced or design evolution with other component-mates
  • Innovation and knowledge sharing on the component

The first two points can be handled with component-based daily standup. So in Spotify, this component structure and related activities are handled in Chapter and Guild structures.

The third point is handled in form of the Community of Interest (COI) concept where Guild members present new ideas and share their challenges with other Guild members.

This COI concept can be used in organizations with smaller teams as well. In Squads for instance, a guild is created for people interested in Front-End engineering-related activities. This guild represents developers (working in small projects) interested in front-end activities.

Development vs Operations Relationship

One of the main bottlenecks in Continuous Delivery is the hand-off between the Development team to Operations. In many organizations Operations team focus on making the release for the development team, make infrastructure changes based on the inputs coming from the Release document. In Spotify the main job of the Operations team is to give the Squads the support they need to release code themselves; support in the form of infrastructure, scripts, and routines. So that’s real empowerment, helping in removing the knowledge and capacity bottleneck, focused towards delivering faster release. The operations team is, in a sense, “building the road to production”.

A similar thing can happen for teams in smaller organizations as well which could then help in Continuous Delivery.