A Practical Application of Agile Tribes for Software Development

Last week we provided an overview of Tribes, a recent innovation in the world of Agile software development methodologies. In a nutshell, Tribes organizes a development shop into teams of employees known as Squads, Tribes, Chapters, and Guilds by either the projects they work on, as well as their role in the company. Squads and Tribes relate more to specific project work, while Chapters and Guilds focus on their profession (developers, testers, etc.).

If all these different groups seem a bit confusing, check out last week’s article for a more detailed explanation. This time out, we are going to look at a practical example of how a software development shop uses this organizational structure to build applications in a more efficient manner.

How Spotify made Agile Work

Spotify, the music streaming company, is one of the first enterprises where the Agile Tribes structure saw a successful implementation. Alistair Cockburn, one of the original developers of the Agile idea, was reportedly impressed with Spotify’s Tribes matrix implementation.  “Nice. I’ve been looking for someone to implement this matrix format since 1992, so it is really welcome to see,” said Cockburn.

A matrix-like structure isn’t completely new when it comes to structuring a software development organization. Spotify’s innovation comes by grouping people with different skill sets into Squads, so software engineers, QA professionals, and business analysts all work on the same team reporting to a Product Owner. The focus is on product delivery as opposed to organizing workers by their function. Instead, the Chapter structure organizes employees in this manner.

At Spotify, technical professionals are typically in all four groups; this means they essentially have two bosses. The Product Owner of their squad is focused on the building a top notch product, while the Chapter Lead encourages everyone in their Chapter to strive for technical excellence.

Spotify realizes that clashes sometimes occur within this organizational structure. Maybe a Product Owner wants to speed up a development cycle against the wishes of the Chapter Lead responsible for the developers on that PO’s Squad? The company feels this is a healthy kind of tension that ultimately results in a better product for consumers. 

The System Owner is responsible for the Overall Architecture

With a host of Squads all working on their own specific projects, there can be difficulty in enforcing standards and a common technical architecture across the entire department. Spotify felt there was a need for a System Owner role responsible for the overall architecture of their music streaming product. The System Owner includes two professionals following the DevOps principle: one is typically a developer Chapter Lead, while the other works in a systems role.

The System Owner role essentially serves as a traffic cop, ensuring the various Squads don’t clash when working on common parts of the overall application. The release process, documentation, stability, and scalability are some of the other areas of responsibility. Finally, the System Owner works with Spotify’s Chief Architect who handles architectural standards across all applications released by the organization.

Hopefully, this look at Agile Tribes in actions offers some insights for organizing your own company’s software development process. Stay tuned to the Betica Blog for additional news and ideas from the world of software development.