인트로
스포티파이 조직 관리 모델이 있다. 왜 스포티파이 모델이냐? 이유는 스포티파이가 만들었기 때문.
‘프로덕트 매니저는 무슨 일을 하고 있을까’라는 책을 읽으면서 알게 된 방법론인데, 몇몇 스타트업에서 도입하고 있는 Guild, Chapter 등의 조직 구성 방법이 이 모델에 나오는 것과 유사한 것인가 궁금하기도 해서 이 모델을 찾아 정리해 보았다.
따라서 이 글은 스포티파이 모델에 대한 대략적인 내용과 현재의 평을 다룰 예정.
스포티파이 모델이란?
아틀란시안에서 말하는 스포티파이 모델은 문화와 네트워크의 중요성을 강조하면서 애자일을 확장하기 위한 사용자 중심의 자율적인 접근 방식이다.
스포티파이 모델은 제품 개발을 위한 조직에서 여러 팀을 조직하는 한 가지 예시라고 할 수 있으며 문화와 네트워크의 필요성을 강조한다. 또한 이 모델은 애자일을 지원할 수 있도록 조직을 구성하는 방법에 중점을 둔다.
스포티파이 모델은 2012년 Henrik Kniberg와 Anders Ivarsson이 Spotify가 애자일에 접근하는 혁신적으로 간단한 방법을 소개한 백서 Scaling Agile @ Spotify를 발표하며 세상에 알려졌다.
그 이후로 스포티파이 모델은 많은 화제를 불러일으켰고 애자일 하게 변화하는 조직에서 널리 사용되고 있다. 이 모델이 인기 있는 이유 중 하나는 특정 관행을 따르기보다는 작업을 중심으로 조직하는 데 중점을 둔다는 점이다. 기존 확장 프레임워크에서 특정 관행(예: 데일리 스탠드업)은 프레임워크를 실행하는 방식인 반면, 스포티파이 모델은 기업이 애자일을 활성화하기 위해 조직을 구성하는 방법에 중점을 둔다.
스포티파이 모델은 팀의 자율성을 중시하므로 각 팀(또는 스쿼드)이 각자 프레임워크(예: 스크럼, 칸반, Scrumban 등)를 선택한다. 또한 스쿼드는 트라이브와 길드로 조직되어 팀원들을 정렬하고 지식을 교차 분배하도록 돕는다.
스포티파이 모델의 구성 요소
스포티파이 모델의 핵심은 단순성이다. Spotify는 업무를 중심으로 팀을 조직하기 시작했을 때 팀원과 팀을 구성하는 방법에 대한 몇 가지 중요한 요소를 식별했다. 예시와 설명을 아틀라시안에서 잘 적어놨길래 이를 가져왔다.
1. 스쿼드
- 스크럼 팀과 마찬가지로 스쿼드는 하나의 기능 영역에 중점을 둔 자율적인 교차 기능 팀이다. (일반적으로 6~12명).
- 각 스쿼드에는 수행 업무, 고유 미션, 지원, 애자일 코치 등 관리를 위한 PO가 존재한다.
- 스쿼드에서는 어떤 애자일 방법론/프레임워크를 사용할지 결정한다.
- 요즘 몇몇 스타트업에서 사일로(silo)라고 부르는 조직 구성 방식이 이와 유사한 것 같다.
2. 트라이브
- 동일한 기능 영역 내에서 여러 스쿼드가 서로 조정하면 트라이브가 형성된다.
- 트라이브는 여러 스쿼드 간에 정렬을 구축하도록 돕고 일반적으로 정렬을 유지하기 위해 40~150명(던바의 수 활용)으로 구성된다.
- 각 트라이브에는 스쿼드 간 협업을 돕고 협업을 장려하는 일을 담당하는 트라이브 리더를 둔다.
3. 챕터
- 스쿼드는 자율적이지만 전문가(예: Javascript 개발자, DBA)는 모범 사례에 정렬하는 것이 중요하다.
- 그래서 챕터는 각 전문가가 소속한 패밀리(디자인 리더, 테크 리더, PO 등)로 구성되며, 한 분야에 걸쳐 엔지니어링 표준을 유지하는 데 도움이 된다.
- 일반적으로 챕터는 선임 기술 리더가 주도하며, 이들은 또한 해당 챕터의 팀원 관리자일 수도 있다.
4. 길드
- 주제에 대한 열정이 있는 팀원은 기본적으로 관심사가 같은 커뮤니티인 길드를 구성할 수 있다.
- 즉, 공통 관심사를 가지고 모인 팀원들이라고 말할 수 있다.
- 길드에는 누구나 완전히 자발적으로 가입할 수 있어야 하며, 챕터는 트라이브에 속하지만 길드는 여러 트라이브 간에 걸쳐 있을 수 있다.
- 보편적으로 길드의 공식 리더는 없으며, 누군가가 자발적으로 길드 코디네이터가 되어 참가자들을 하나로 모으는 역할을 수행한다.
5. 트리오
- 트리오(일명 TPD 트리오)는 트라이브 리더, 제품 리더 및 디자인 리더의 조합이다.
- 각 트라이브에는 기능 영역에서 작업할 때 이 세 가지 관점(조직, 제품, 디자인) 간에 지속적으로 정렬할 수 있도록 트리오가 존재한다.
6. 얼라이언스
- 조직이 확장됨에 따라 목표를 달성하기 위해 때때로 여러 트라이브가 긴밀하게 협력해야 한다.
- 얼라이언스는 어떤 한 개의 트라이브보다 큰 목표를 달성하도록 트라이브 협업을 지원하기 위해 협력하는 트라이브 트리오(일반적으로 세 개 이상)의 조합이다.
- 즉, 얼라이언스는 트라이브의 집합.
스포티파이 모델 참고 이미지
스포티파이 모델의 이점
스포티파이 모델은 아래 두 가지 이점을 말할 수 있다.
1. 공식적인 절차가 가벼움: 제품 개발하는 군들을 쪼개놓았기 때문에, 그들이 결정하고 일을 진행하게 되므로 의사결정의 절차가 짧아진다.
2. 자체 관리 및 자율성이 높음: 쪼개진 조직 별로 관리를 각자가 진행할 것이기 때문에 자체 관리가 될 것이며, 그만큼 자율성을 보장해 줄 수 있다.
스포티파이 모델은 실패였다?
해당 백서의 공동 저자와 Spotify의 Agile 코치들은, 예전부터 외부 사람들에게 따라 하지 말라고 얘기한 적이 있다고 한다. 애초에 Spotify에서 이 백서를 작성했던 시점에도 그들은 이 모델을 적용하지 않고 있었다는 것.
스포티파이 모델에서는 각 팀의 엔지니어를 담당하는 단일 관리자가 없고 이는 mini-CEO 역할을 했던 프로덕트 매니저에게 mini-CTO 같은 역할을 해줄 사람 또한 없다는 것을 의미한다. 즉, 기술팀의 지원에 대해 책임지거나, 우선순위를 협상할 사람이 없다. 기술팀 내부에서 의견 불일치가 일어나면 프로덕트 매니저가 모든 엔지니어와 협상하거나 적어도 3명 이상인 백엔드/웹/모바일 엔지니어링 매니저들하고 협상하 거는 등 부서의 엔지니어링 책임자에게 에스컬레이션(보통 상사에게 의사결정을 요청하는 일을 뜻함)하는 일이 일어남.
회사가 작을 때는 각 팀이 다양한 범위의 일을 하고, 종종 주도권을 가진 팀이 바뀌기도 한다. 회사가 커지면 각 팀의 중복된 기능들은 효율화를 위해서 새로운 팀으로 합쳐서 만들어진다. 팀이 많아지면 주도권이 변경될 일이 줄어들고, 자신들이 해결해야 할 문제에 대해 장기적으로 생각이 가능해지지만 각 팀이 자신들만의 방법으로 참여하니까 결국 전체 조직의 생산성이 떨어지게 된다.
각 팀(스쿼드 등)에게 Agile을 가르쳐주고, 프로세스를 코치해 줄 만한 여력이 떨어지게 된다. 조직이 성장할수록 점점 팀들은 세분화되고 많아질 것이기 때문인데 이것이 심화되면 2번의 문제가 발생한다.
그래서?
이처럼 팀이 여러 리더에게 보고하는 체계를 갖춘 Matrix 조직에 대해서 알아둘 필요가 있다고 생각한다. 의사결정이 하나의 방향으로만 이루어지면 좋겠지만, 요즘은 그렇지 않은 곳도 많으니까 말이다. 협업이 유기적으로, 많이, 잘 이루어져야하는 만큼 자연스럽게 스쿼드처럼 업무를 수행하는 그룹들이 형성되기 때문인 것도 있다.
PM의 경우에는 하나의 제품 그룹 외에도 다른 그룹과 섞여야 할 때가 많을 터이니 알아두면 좋은 개념이긴 하다. 하나씩 잘 읽어보고 나서 단 것은 먹고 쓴 것은 뱉자.
참고
ⓒ 327roy