해결책
2012년 Henrik Kniberg와 Anders Ivarsson은 Spotify가 세 도시에 걸쳐 30개 이상의 팀으로 애자일 작업을 확장한 방식을 설명했습니다. 눈에 띄는 발명은 새로운 프로세스 의례가 아니라, 전달 단위와 학습 네트워크를 분리하는 어휘였습니다.
스쿼드는 스크럼 팀과 유사한 자기 조직화 팀이었지만, 스크럼, 칸반 또는 혼합 방식을 자유롭게 사용할 수 있었습니다. 트라이브는 관련 스쿼드를 모았습니다. 챕터는 트라이브 내에서 유사한 기술을 가진 사람들을 연결했고, 길드는 더 넓은 조직 전반에 걸쳐 공유 지식, 도구, 관행을 전달했습니다.
이 메커니즘은 익숙한 확장의 함정을 해결했습니다. 모든 결정을 중앙 집중화하면 팀이 느려지고, 모든 팀이 모든 것을 혼자 발명하게 두면 재사용이 파괴됩니다. Spotify는 팀에게 방법에 대한 자율성을 부여하면서 챕터와 길드를 통해 전문성, 아키텍처, 관행이 옆으로 계속 움직이도록 했습니다.
달성한 것
팀이 어떻게 할지 선택하게 하고, 왜 하는지에 정렬시키기
스쿼드는 속도를 낼 수 있을 만큼 소유권을 작게 만들었습니다.
트라이브는 관련 스쿼드를 거대한 프로그램 오피스 없이도 조정할 수 있을 만큼 가까이 두었습니다.
챕터는 서로 다른 스쿼드에 속한 사람들의 전문성 개발을 유지했습니다.
길드는 유용한 관행이 의무적인 프로세스가 되지 않으면서 퍼지도록 했습니다.
자율성에는 지식과 표준을 위한 두 번째 구조가 필요합니다. 그렇지 않으면 독립적인 팀이 고립된 팀이 됩니다.
그 후
이 모델은 Spotify 훨씬 너머에서 영향력을 얻었습니다. 2020년 오픈 액세스 Springer 논문은 이를 다른 조직에서 사용되는 방법의 기반으로 설명하는 한편, 자율적인 스쿼드가 아키텍처 병목을 만들지 않도록 필요한 거버넌스 작업도 연구합니다.
근거 확인하기
출처
- Scaling Agile with Tribes, Squads, Chapters & Guilds Scrum Expert · scrumexpert.com ·
- Spotify Tailoring for Architectural Governance Springer Nature Link · link.springer.com ·