{"id":21789,"date":"2019-11-20T12:51:55","date_gmt":"2019-11-20T12:51:55","guid":{"rendered":"https:\/\/www.devopsonline.co.uk\/?p=21789"},"modified":"2019-11-20T12:51:55","modified_gmt":"2019-11-20T12:51:55","slug":"team-topology-beyond-the-spotify-model-an-experts-view","status":"publish","type":"post","link":"https:\/\/devopsnews.online\/team-topology-beyond-the-spotify-model-an-experts-view\/","title":{"rendered":"Team topology beyond the Spotify Model-an expert’s view"},"content":{"rendered":"
Key takeaways<\/em><\/p>\n At DevTest North 2019 I gave a keynote talk called <\/a>Beyond the Spotify Model<\/em><\/a> based on material and ideas from my new book Team Topologies: Organizing Business and Technology Teams for Fast Flow<\/em><\/a>, co-authored with Manuel Pais. In this article, I share the key ideas from the talk.<\/p>\n For effective, modern, cloud-connected software systems<\/a> we need to organise our teams in certain ways. Taking account of Conway\u2019s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes.<\/p>\n In 2012 people at music streaming service Spotify published a well-known article describing how they organized their teams<\/a> for a rapid flow of change using semi-autonomous Squads, Chapters of similar-skilled people, Tribes of related Squads working on similar product areas, and Guilds that act as cross-tribe communities. This model helps to emphasize a rapid flow of change because each Squad has a mix of skills – engineers, testers, business analysts, ops people, etc. – that allows the Squad to own a slice of the Spotify product and take an idea from concept through coding to Production. The software architecture also benefits because different business domain concepts are neatly separated into bounded contexts mapped to different Squads, which helps with a fast flow of change.<\/p>\n Many organisations have tried to copy the Spotify model but often with mixed results and limited success. Why could that be? There are several limitations which we\u2019ll explore next.<\/p>\n Although the Spotify model is a useful starting point, it does not directly address several key aspects of modern software development, including:<\/p>\n In fact, the authors of the original article, Henrik Kniberg and Anders Iversson, themselves warned against copying the model: \u201c…by the time you read this, things [will] have already changed.\u201d<\/p>\n\n
The Spotify model for organisation design<\/h4>\n
Limitations of the Spotify model<\/h4>\n
\n
How the ideas in Team Topologies can help<\/h4>\n