A while back Henrik Kniberg published an excellent case study on Scaling Agile @ Spotify. Though 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 smaller team’s perspective.
A lot of organizations still works 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 above picture, Team 1 to 3 take the related slice of the feature into their backlog. Product owners of each team drive the prioritisation 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 current case that waste is 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 above scenario with feature team consisting 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 absence of any delay.
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
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.
Third point is handled in form of 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 StarterSquad 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 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 Release document. In Spotify the main job of 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 a real empowerment, helping in removing the knowledge and capacity bottleneck, focused towards delivering faster release. Operations team are, in a sense, “building the road to production”.
Similar thing can happen for teams in smaller organizatios as well which could then help in Continuous Delivery.