Spotify Model (2)
ING는 Netherlands의 Amsterdam 에
본사를 둔 다국적 금융그룹입니다.
Fin-Tech, Big Data, internet의 발달 등
세상의 변화에 대응하며
경쟁력을 높이기 위하여
금융분야에서는 세계 최초로
2015년 경에 Agile 방식을 도입하였고
좋은 성과를 올렸습니다.
그 내용이 양 옆의 동영상에
잘 소개되어 있습니다.
그러한 Agile Tranformation의 활동이
McKinsey의 보고서 에 자세히 서술이 되어 있는데
기본적으로 “Spotify Model” 을 따르고 있음을 알 수 있습니다.
왼쪽 그림에서
“PO/CJE”는 “Product Owner / Customer Journey Expert”
“POCLAC”는 “Product Owner, Chapter Lead, Agile Coach”를
의미합니다.
각 Squad마다 Product Owner가 있는데
PO는 Product Backlog을 관리하고 우선순위를 결정하여
그 Squad이 무엇을 할 것인가에 대한 책임을 가지나
PO가 상급자 (boss)는 아니라는 걸 명확히 하고 있습니다.
그런데 이전의 Spotify Model (?)에서
언급하였듯이 그에 대하여
Failed #SquadGoals
이라는 지적이 있었습니다 (2020.4.).
Spotify에서 “Spotify model”을
실제로 사용하고 있지를 않고
이를 모방하려고
애쓰지 말라는 겁니다.
그리고 그 문제점들과
교훈들을 제시하고 있습니다.
2019년에 열린 LeSS Conference에서
ING가 “Spotify Model”을
운영하면서 겪은 문제점들을
어떻게 개선했는가 하는 발표가 있었습니다.
Squad들이 각각 Product Backlog을 가지고
독립적으로 운영을 함에 따라서
여러 Squad들이 전체 Product 관점에서
협력함에 있어 문제들이 발생했답니다.
500 여명으로 이루어진 그룹이
어떤 Product를 개발함에 있어서
3개월 만에 release를 했는데
통합 작업에 어려움을 겪으면서
오류 수정 등 안정화에 2개월이 걸렸답니다
(왼쪽 그림).
23개의 Squad으로 구성되어 있었고
각 Squad에는 각각의 PO와
Product Backlog이 있었습니다.
각 Squad들은 개별적인 목표를 가지고
각자의 Output 위주로 작업을 하게 되어
Product 전체적으로 가장 중요한
Outcome을 산출하지 못하는
결과가 되었습니다
(오른쪽 그림).
개선 방안 중의 하나는 각 Squad 마다의
PO 역할을 없애는 것이었는데
이 방안을 PO들 스스로가 자발적으로
제시했다는 점이 흥미롭습니다 (왼쪽 그림).
추가적 개선 사항들은
오른쪽 그림과 같습니다.
이러한 개선 사항들은 기본적으로
Scrum에서 권장하는 개념들과 일치하는 것으로
LeSS가 Scrum 개념의 자연적 확장이라는
점에서 당연하다고 하겠습니다.
하나의 Product를 개발함에 있어
여러 팀들이 협업을 할 경우에
팀마다 Product Owner가 있고
각각 Product Backlog을 가질 경우에 대하여는
Michael James가 경고하는 내용이
왼쪽의 동영상과
오른쪽의 문서에 잘 설명되어 있습니다.
각 팀의 Product Owner가
PO로서의 역할을 한다기보다는
“Team Output Owner”의 역할로
변질될 수 있으며,
그럴 경우는 제대로 된
“Scrum”이라고 할 수가 없고
Agile에 도움이 안 된다는 의미입니다.
