SPO(Strategy Product Owner)가 필요한 이유

SPO가 필요한 이유는...

PO의 역할은 Scrum Guide에 정의되어 있습니다.

그리고 실리콘 밸리, 스타트업을 통해서 PO의 역할은 확장되고 있습니다.

이제 PO는 넓은 범위의 업무를 커버하는 의미가 되었으며 이로 인해 일부 PO는 많은 양의 업무를 힘들어하기도 합니다.

 

기업들은 PO의 업무를 분리하는 방식으로 업무 과부하를 해결합니다. 여러 방법이 있지만 가장 일반적인 방식은 그들의 역할을 SPO와 TPO로 분리하는 것입니다.

• SPO는 제품의 전략을 담당하는 Strategy PO이며
• TPO는 좀더 실무적인 부분을 담당하는 Tactical Product Owner을 의미합니다.

단순히 업무가 많다는 것 이외에도 Product의 전략을 담당하는 SPO가 필요한 이유는 더 있습니다.

 

Scrum Guide에서 설명하는 PO는 작은 애자일 팀의 업무에 집중합니다. PO는 개발해야할 제품의 기능을 찾아내고 구체화하지만 Scrum 의 Process는 그 방식에 대해서는 설명하지 않는다. Scrum이 집중하는 부분은 기능이 개발되는 부분이고 이를 위해 몇가지 미팅 방식, 산출물을 정의하고 있습니다.

 

 하지만 Strategy PO가 일하는 환경은 스크럼 가이드가 집중하는 영역과는 다릅니다. 규모가 있는 환경에서 일하는 SPO는 제품을 위해서 많은 팀을 조율해야 하며 제품의 기능을 정의하기 위해 가설을 만드는 것과 같은 여러가지 활동을 수행해야 합니다. 작은 애자일 팀을 넘어서는 큰 규모의 제품 기능 범위와 애자일 팀의 플래닝에서 리뷰까지의 흐름을 벗어나는 더 큰 가치 흐름을 관리하는 것이 Strategy PO의 역할입니다.

 거꾸로 설명하면 이 활동을 위해서 SPO라는 역할이 필요합니다.

 

SPO는 흐름 관리 도구는..

 SPO는 일감을 만들고 구체화하기위해 마켓리서치, 유저리서치, 디자인씽킹, 그로스해킹과 같은 많은 도구를 사용합니다. 이 도구들은 SPO가 참여하는 흐름의 여러 단계의 부분적으로 사용되는 도구입니다. 여러 애자일 프로세스에서 그러하듯이 SPO의 업무에도 전체 흐름을 관리할 수 있는 도구가 필요합니다.

 

 아래 이미지는 Scaled Agile Framework(SAFe)에서 정의하는 Product Management(PM)의 흐름 관리 도구인 Program Kanban입니다. 

 

출처 : https://www.scaledagileframework.com/program-and-solution-kanbans/

 SAFe의 PM은 SPO와 유사한 개념입니다.

 이 Program Kanban을 통해서 PM은 개발팀을 뛰어넘는 범위에서 Product 단위의 기능 흐름을 정의하고 관리할 수 있습니다. 

 각 단계가 의미하는 것을 소개합니다. 더 자세한 설명은 이미지 밑의 링크를 방문해주세요.

 

Funnel – 모든 새로운 아이디어가 들어갑니다. Analyzing – 비전과 일치하고 전략적 테마를 지원하는 새로운 아이디어는 사용 가능한 용량이 있을 때 Agile Teams에서 구체화합니다. 아이디어를 설명, 비즈니스 이점 가설, 수용 기준 및 표준화된 스토리 포인트의 크기가 포함된 Feature 단위로 만듭니다. Backlog – PM이 분석 및 승인한 최우선 순위 Feature가 구현을 기다립니다. Implementing – 프로그램 백로그에서 구현 상태로 이동합니다. PI Planning을 통해 스토리로 분할되고 PI 동안 구현합니다.  Validating on Staging – 피드백을 받을 준비가 된 기능이 이 상태로 전환됩니다.  Depolying to production – 기능이 프로덕션으로 이동됩니다. 배포와 릴리스를 분리하는 시스템에서 기능은 릴리스를 기다리기 위해 이 상태의 '준비' 부분으로 이동합니다.  Release - 충기능이 일부 또는 모든 고객에게 출시되어 혜택 가설의 평가가 발생합니다. 기능이 '완료' 상태로 이동하는 동안 기능에서 수집한 학습을 ​​기반으로 새 작업 항목이 생성될 수 있습니다.

 SPO가 가시적으로 흐름을 만들고 관리한다는 것은 애자일 방식이 애자일팀을 넘어 Product 단위로 확장된다는 것을 의미합니다. 그리고 SPO가 드디어 애자일 방식을 함께 한다는 것을 의미합니다.

 

 이를 통해 SPO는 Product 전체 흐름을 투명하게(Transparency) 공유하고 주기적으로 관찰하여(Inspect) 개선해(Adapt) 나갈 수 있게 됩니다. 여기까지 짧게 SPO의 필요성과 SPO의 흐름 관리 도구인 Program Kanban을 소개했습니다.

 디지털 트랜스포메이션을 시도하는 많은 기업들에서 애자일과 비애자일 문화의 충돌이 관찰되는 경우가 있습니다. 이 충돌은 애자일을 적용한 개발팀과 이전 방식으로 일하는 사업팀 간에 업무 방식이 차이, 문화의 충돌 때문에 발생합니다. 이를 극복하기 위해서 서로의 업무 방식을 투명하게 공유하여 신뢰의 기틀을 마련하는 것이 중요할텐데요.

 

 이 접점에 존재하는 것이 바로 SPO입니다. 그래서 SPO는 일의 시작에서 마지막 흐름까지를 보여주는 자신의 도구를 통해서 서로의 신뢰를 쌓아가도록 도울 수 있어야합니다. SPO와 SPO의 흐름도구를 통해서 애자일을 적용한 기업들이 신뢰를 쌓고 앞으로 나아가길 기원해 봅니다.