Spotify의 Squad 팀 모델은 실패였다
(jeremiahlee.com)"스포티파이 자신들도 'the Spotify model'을 사용하지 않음. 여러분도 쓰지 마세요."
2012년 유명했던 스포티파이의 "Scaling Agile" 백서는 그들의 희망이었을 뿐 완전히 구현되지 않음.
백서는 현실과 달랐지만, 채용에 유용했으므로 그냥 뒀고, 글쓴이는 퇴사 후 이걸 바로잡기 위해 기록.
그 모델의 잘못된 점과 스포티파이의 실수에서 배울 점, 다른 추천 모델을 상세히 적은 글
해당 백서의 공동 저자와 Spotify의 Agile 코치들은, 예전부터 외부 사람들에게 이거 따라 하지 말라고 얘기한 적이 있음.
"우리가 백서를 작성했던 시점에도 우리는 그거 안 하고 있었음. 부분적인 야망이고 추정 이었을 뿐. 사람들은 실제로 존재하지 않는 것을 힘들게 따라 한 것"
왜 잘 동작 안 했을까?
1. 매트릭스 관리는 잘못된 문제(Wrong Problem)를 해결함
ㅤ풀 스택 애자일 팀은 잘 워킹함. 하지만 매트릭스 형태의 관리는 더 많은 문제점을 만듦
ㅤ→ 스포티파이의 팀들은 오래가는 구조여서, 다른 팀으로 변경 시 매니저를 변경할 필요가 없다는 이점은 매우 제한적이었음
ㅤ→ 엔지니어링 관리자가 경력개발 수준만 책임지고, 대인 관계 기법 등을 익히는 것은 도와주지 못함
ㅤ→ 각 팀의 엔지니어를 담당하는 단일 관리자가 없음. mini-CEO 역할을 했던 프로덕트 매니저에게 mini-CTO 같은 역할을 해줄 사람이 없음. 즉, 기술팀의 지원에 대해 책임지거나, 우선순위를 협상할 사람이 없었음. 기술팀 내부에서 의견 불일치가 일어나면 프로덕트 매니저가 모든 엔지니어와 협상 해야 함. 거기서 안되면 적어도 3명 이상인 백엔드/웹/모바일 엔지니어링 매니저들하고 협상하거나, 부서의 엔지니어링 책임자에게 에스컬레이션하는 일이 일어남.
[ 스포티파이의 실수에서 배울 점 ]
ㅤ→ 제품-디자인-기술 팀은 일반적으로 엔지니어들이 더 많으니까, 전체 엔지니어들을 담당하는 매니저가 있어야 팀 내의 의견충돌 시 에스컬레이션할 경로가 생김
ㅤ→ 프로덕트 매니저들은 기술에 대해 의논할 동등한 피어(CEO와 CTO처럼)를 가져야 함.
2. 팀의 자율성에 의존
ㅤ회사가 작을 때는 각 팀이 다양한 범위의 일을 하고, 종종 주도권을 가진 팀이 바뀌기도 함.
ㅤ회사가 커지면 각 팀의 중복된 기능들은 효율화를 위해서 새로운 팀으로 합쳐서 만들어짐.
ㅤ팀이 많아지면 주도권이 변경될 일이 줄어들고, 자신들이 해결해야 할 문제에 대해 장기적으로 생각이 가능.
ㅤ→ 스포티파이는 팀 간 협업에 대한 공통 프로세스를 정의하지 않았음. 각 팀이 자신들만의 방법으로 참여하니까 전체 조직의 생산성이 떨어짐.
ㅤ→ "스포티파이 모델"은 회사가 훨씬 작았을 때 정리된 것. 후속으로 정리된 것이 나와야 했지만, 그러지 못했음. 자율성까지만 얘기되고, 팀 간 협업에 대한 부분은 완료되지 않음.
[ 스포티파이의 실수에서 배울 점 ]
ㅤ→ 자율성은 얼라인이 필요함. 회사의 우선순위는 경영진에 의해 정해져야 함. 자율성은 팀들이 하고 싶은 것을 맘대로 하는 것이 아님.
ㅤ→ 팀 간 협업 프로세스는 무조건 필요함. 자율성은 각 팀이 모든 문제를 혼자 해결하도록 놔두는 것이 아님.
ㅤ→ 성공을 어떻게 평가하는지도 경영진이 정해놔야, 팀 간 협업 우선순위를 결정할 때 조율이 가능.
ㅤ→ 자율성은 책임을 요구함. Product Management는 제품 가치에 대해 책임져야 함. 각 팀은 추가되는 부분을 '완료'해야 하는 책임이 있음. 성숙한 팀은 비즈니스 가치, 위험, 학습 및 다음 단계를 위한 최적의 움직임을 보여주는 것으로 자신들의 독립성을 정당화 해야 함.
"내가 스포티파이에서 딱 하나만 고치고 싶었던 걸 고르라면, 자율성을 너무 강조하지 않았어야 한다는 것." - 스포티파이의 Agile Coach였던 Joakim Sunden
3. 협업은 가정된 역량이었을 뿐
ㅤ스포티파이가 각 팀이 작업방식을 제어할 수 있게 해줬지만, 많은 사람이 애자일에 대해 기본 이해를 가지고 있지 않았음.
ㅤ이로 인해 각 팀은 아웃풋을 개선하기 위해 프로세스 개선을 반복하면서 조합을 찾는 노력을 해야 했음.
ㅤ효율적으로 프로세스의 문제나 해결 방법, 성과 평가를 하기 위한 공통 언어가 없었음. 실제로는 애자일도 아니고, 그냥 "Not-Waterfall" 이었음.
ㅤ스포티파이는 각 팀에게 프로세스 개선을 가르치고 제안할 '애자일 코치'가 있었음. 의도는 좋았지만, 모든 팀을 도울 코치가 충분하지 않았음.
ㅤ각 코치가 팀에 할당하는 시간은 각 팀이 프로젝트를 완료하고 성과를 평가하는 데까지 도와주기엔 부족했음. 그래서 그들은 아무것도 책임을 지지 않음.
[ 스포티파이의 실수에서 배울 점 ]
ㅤ→ 협업은 지식과 연습이 필요한 기술임. 관리자는 사람들이 기존 애자일 프랙티스들을 이해하고 있다고 가정해서는 안 됨.
ㅤ→ 회사가 충분히 커지면 각 팀은 팀 내에서 계획을 세우고 팀 간의 협업을 가능케 하기 위한 서포트 조직이 필요함. Program Management가 플래닝 프로세스를 책임져야 함. 전담 Program Manager 들은 Product Manager 와 Engineering Manager가 각자의 역량을 수행하면서도 협업하는 것처럼 팀을 동작하게 해야 함.
4. 신화는 변경하기 어려움
ㅤAgile Scrum이 번다운/스프린트 같은 단어를 제시한 건 새로운 개념을 소개하면서 이름이 필요했기 때문이었음.
ㅤ스포티파이가 Missions, Tribe, Squads, Chapter Lead와 같은 새로운 단어들을 소개했는데, 이건 "뭔가 특별한 단어 선택을 해야만 하는 것을 만들었다는 환상"을 심어준 것.
ㅤ이런 불필요한 동의어들을 제거하면 스포티파이 모델은 너무 많은 자율성과 열약한 관리구조를 가진 "Cross-Functional Team"들의 모음일 뿐.
ㅤ만약 스포티파이가 이 모델에 대한 아이디어를 원래의 이름들로 불렀다면, 모델이 실패했을 때 그걸 문화적인 정체성을 바꾸는 것으로 생각하지 않고 더 잘 동작하는 내부 프로세스를 찾는 것이라고 평가했을 수도 있음.
[ 스포티파이의 실수에서 배울 점 ]
ㅤ→ 대부분의 비즈니스는 몇 개의 혁신 영역만 유지가 가능. 내부프로세스의 혁신이 시장에서 회사를 차별화하는 경우는 거의 없음. 과거를 연구하면 비즈니스가 혁신을 위한 좀 더 나은 영역을 찾을 수 있음.
ㅤ→ 이해를 최적화할 것. 조직의 생산성을 유지하기 위해서, 조직원이 배워야 하는 모든 새로운 것의 가치를 평가해야 함.
*** 대신 이렇게 하세요. ( 물론 빠른 방법은 없습니다. )
스포티파이 모델을 찾은 이유는 아마도 당신의 팀 구조를 만들기 위해서 일 겁니다. 여기서 멈추지 말고 더 알아보세요.
스포티파이보다 더 오랜 시간의 테스트를 견뎌낸 회사들이 더 많은 글을 작성해 두었습니다.
2012년의 스포티파이는 대규모 조직에서 소규모 팀의 속도와 민첩성을 유지하는 방법을 찾지 못했습니다.
그들은 이 시조 모델을 뛰어넘어 더 나은 답변을 찾기 위해 외부를 보았고, 당신도 그래야 합니다.
다른 일하는 방식에 대한 필자의 추천
- 제품-개발-디자인 조직에 200명 이상이 있으신가요? 제가 Fitbit에 있을 때 "Scaled Agile Framework" 가 잘 맞았습니다.
- 200명 이하에서는 "Shape Up By Basecamp" 를 추천합니다. 제 다음번 스타트업은 이런 구조로 할 예정이에요.
- "Essential Scrum" 과 "Team Topologies" 책을 읽어보세요.
좋은 글 감사합니다.
지금 회사에서도 2년전 쯤에 스포티파이의 squad팀 모델을 채용 했으나 글에 나와있는 단점들로 인해서 많은 부분이 강제로 개선되게 되더군요.
올해 초 부터 Basecamp에서 나온 Shape Up을 따르고있으며 결과적으로 더 나은 제품 퀄리티를 제공할수 있게 되었습니다.
저 이 "Scaling Agile" 백서 처음 공개되었을때 보고 놀라서 공유하고 블로그에도 적었는데.. 충격적인 글이네요 ㅠ
필자의 추천중 하나인 "Basecamp 의 Shape Up" 은 긱뉴스에 소개한바 있습니다. 작은 조직에서는 저도 이걸 추천합니다.
Shape Up - 작은 조직이 훌륭하게 일하는 법 [PDF] https://news.hada.io/topic?id=427
이 글에 대한 Spotify 직원들의 반응
나 6년 있었는데 100% 정확합니다. https://twitter.com/solomonjames/status/1258930064441425920
나 2019년에 그만뒀는데 그만든 큰 이유가 이 글에 있는 문제들 때문이었음 https://twitter.com/ayyyylo/status/1253658456621539328
따라했다 실패한 다른 사람들의 반응
Zalando 가 2016년에 따라 했는데, 이게 잘 동작안한다는 걸 금새 알수 있었음 https://twitter.com/chilicoder/status/1253429837185691656
Typeform 도 이거 따라해보려다가 실패했음 https://twitter.com/jharmn/status/1252229296522842121
스포티파이가 블로그에 적자마자 따라해봤는데 재앙이었음. https://twitter.com/braedon/status/1256122236424957953