이 글은 공식 LeSS 사이트에 있는 Product Owner를 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 SAFe와 LeSS가 가장 인기있는 대규모 애자일 프레임워크라고 할 수 있다. 많은 이들이 애자일 트랜스포메이션에 관심을 갖고 있는 우리의 상황에서 비슷한 고민을 오래 전에 먼저 시작한 이들의 문제 인식과 통찰을 살펴보는 것은 흥미로운 일이다.

대규모 조직에 애자일을 적용하고자 하는 분들에게 도움이 되길 바란다.

0. 대규모 스크럼, 레스(LeSS)
1. 왜 레스(LeSS)인가?
2. 레스(LeSS)의 규칙
3. 피처 팀(Feature Teams)
4. 제품 책임자(Product Owner)
5. 스프린트(Sprint)
6. 제품 백로그(Product Backlog)
7. 제품 그리고 완료의 정의
8. 팀간 조율 및 통합
9. 스크럼 마스터(ScrumMaster)
10. 레스(LeSS)의 적용

레스(LeSS)에서 제품 책임자(Product Owner, 이하 PO)의 역할과 한 팀에 스크럼을 적용할 때 PO의 역할이 개념적으로는 같다. 하지만, 규모가 커지면 그 초점에 전체 관점을 유지하고 투자수익률(ROI)을 최대화하는 쪽으로 변화한다.

PO의 확대

대규모 제품 개발에서는 다양한 사람들이 서로 다른 방향을 향해 가고, 하위 그룹이 지역 부분최적화에 집중하는 모습을 흔히 볼 수 있다. 한 명의 PO와 하나의 제품 백로그(product backlog)를 유지하면 전체 제품에 초점을 맞추는 데 도움이 된다.

전통적인 대규모 제품 그룹에는 초점이 바깥쪽을 향하는 그룹(대부분 제품 관리자들)과 안쪽을 향하는 그룹(대개는 개발자들)이 있으며, 그 둘이 공존하기란 정말로 어려운 일이다. 레스(LeSS)에서는 한 명의 PO가 고객과 그들의 우선순위라는 바깥쪽에 초점을 맞추면서 많은 시간을 보내기도 하고, 팀이라는 안쪽을 들여다보는 데 시간을 쓰기도 한다. PO가 팀과 고객/사용자를 하나로 연결시키는 연결자 역할을 함으로써, 더욱 고객 중심적인 팀이 될 수 있다.

다른 대규모 스크럼 방식과는 달리, 레스(LeSS)에서 정의하는 역할과 담당은 많지 않아 덜 복잡하기 때문에, 한 사람만으로 PO 역할을 효과적으로 할 수 있다.

명확화(clarification)보다 우선순위화(prioritization)를

스크럼에는 PO와 관련한 핵심적인 정보의 흐름이 두 가지가 있다. (1) 제품 백로그에 있는 항목에 우선순위(순서)를 부여하는 것과 (2) 제품 백로그에 있는 항목을 보다 명확하게 만드는 것이다. 첫 번째 흐름(우선순위화)에서는 이익 동인, 전략적 고객, 비즈니스 위험 등 사업적 관심사와 관련된 정보를 찾고 분석한다. 두 번째 흐름(명확화)에서는 각 항목의 기능과 품질, 사용자 경험 등 기능 설계적 관심사를 상세하게 하기 위한 정보를 찾는다.

레스(LeSS) PO는 우선순위를 열심히 고민하는 데 집중하면서 동시에 명확화를 위해 팀과 협력한다. 더 나아가, 팀이 명확화를 위해 진짜 사용자 및 고객과 대화에 직접 뛰어들 수 있도록 권장하고 돕는다. PO는 중개인이 아니라 연결자다.

왜 팀과 고객/사용자 사이의 직접 상호작용을 강조하는 것일까? 그 이유는 (1) 전달에서 생기는 정보의 손실을 피하고, (2) 실제 고객 문제에 대한 해결책을 공동으로 만들도록 촉진하며, (3) 개발자들이 그들과 직접 협력함으로써 동기와 고객에 대한 공감을 향상시키기 위해서다.

각 팀이 명확화 업무의 대부분을 직접 수행하면, PO는 큰 그림에 집중하고, 지속적으로 우선순위를 조정하며, 새롭고 전략적인 기회를 탐색하는 데 더 많은 시간과 에너지를 쓰게 된다는 점에 주목할 필요가 있다.

개발 유형에 따른 PO 찾아내기

1 단계: 개발 유형 파악

현재 진행 중인 개발의 유형을 잘 파악해야 올바른 PO를 찾을 수 있다.

  • 제품 개발—외부 고객 또는 시장이 그 대상이다.
  • 내부(제품) 개발—회사 내 한 명 이상의 사용자가 그 대상이다. 개발 그룹을 대개는 IT 또는 시스템 개발이라는 이름으로 부른다.
  • 프로젝트 개발—보통은 하나의 외부 고객이 그 대상이다. 일은 프로젝트 형태로 이루어지고 계약된다. 그러나 프로젝트 계약의 범위/일정/비용이 반드시 고정되어 있는 것은 아닐 수도 있다. 개발 회사는 대개 외주 또는 SI 업체다. 고객, 즉 의뢰한 회사는 계약 주체와 사용자 둘 다를 포함하며, 그들이 같은 부서가 아닌 경우도 있다.

2 단계: 올바른 PO 찾기

제품 개발—회사에는 (1) 제품 계획을 주도하는 사업부(예를 들어, 소매 금융) 또는 (2) 계획을 주도하는 제품 관리 부서가 있을 것이다. 전통적인 제품 관리 부서는 고객 및 경쟁사 분석, 제품 비전, 대략적인 기능 선정 및 우선순위 부여, 제품 로드맵 등 비기술 활동을 담당한다. 전통적인 제품 개발 그룹의 업무는 관리하지 않는다.

레스(LeSS)를 적용하는 그룹의 PO는 어디에서 찾을 수 있을까? 제품 관리 부서가 있다면 제품 관리자(product manager)를 선택하는 것이 좋을 수 있다. 그렇지 않다면 그 계획을 주도하는 사업부에서 사람을 찾는다. 명심해야 할 중요한 사항은 제품을 개발하는 PO는 비즈니스 쪽에서 나와야 한다는 점이다.

내부(제품) 개발—레스(LeSS)에서 내부 제품 개발에 좋은 PO란 (1) 그 시스템을 사용할 그룹 내에서 (2) 그 시스템이 지원하게 될 실제 업무와 관련이 깊고 경험이 풍부한 사람이다. 실제 사용자와 매우 가까운 사람들이라고 할 수 있다.

프로젝트 개발—PO는 시스템을 전달받는 회사 사람이고, 내부 개발과 마찬가지로 관련이 있으며 실전 업무 경험이 풍부한 사용자와 가까운 사람이어야 한다는 것이 핵심이다.

내부 개발 및 프로젝트 개발 둘 다에 해당하는 이야기인데, 여러 부서에서 그 시스템을 사용하는 경우라면 주요한 사용자 부서 중 하나로부터 PO 역할에 관심이 있고 정치적 요령이 있으며 경험이 많은 한 명을 선택하는 것이 좋다.

다음 그림은 서로 다른 조직에서의 PO를 보여주고 있다.

어떠한 경우에도 훌륭한 PO에게는 제품에 대한 열정이 있다.

올바른 PO를 금방 찾아낼 수 없는 상황이라면, 비즈니스 쪽에서 오지는 않았지만 상황을 이해하고 있고 PO 역할을 할 수 있는 임시 PO와 함께 레스(LeSS) 적용을 일단 빨리 시작할 수 있다. 팀은 주요 문제가 해결될 때까지 임시 PO 아래에서 여러 번의 스프린트를 완료하도록 하고, 이게 중요한데, 개발팀은 스프린트마다 진짜 ‘완료’, 출시 가능한 증분(또는 비슷한 무언가)을 내놓을 수 있다. 그 이유는 무엇일까? 제품팀이 비즈니스에 실질적인 이익을 제공하는 강력한 새로운 능력을 보여줄 수 있다면, 올바른 장기적 PO를 찾고 고무시킬 가능성이 높을 것이다. 모든 이들이 임시 PO가 정말로 임시일 뿐이라는 사실을 이해하는 것이 매우 중요하다. 종종 “가짜 PO”라는 용어를 사용해서 이 임시 PO가 얼마나 해를 끼칠 수 있는지를 강조하기도 한다. 가짜 PO는 최선의 제품 책임자가 아닐 뿐만 아니라 자신에게 적합하지 않은 역할을 차지하려는 피해를 줄 수 있기 때문이다. 삼류 제품을 만드는 위험을 피하고 싶다면 반드시 가능한 한 빨리 올바른 PO로 교체해야 한다.

3 단계: PO에게 실제 권한과 책임 부여

PO는 계약한 범위를 정해진 날짜에 전달하는 전통적인 프로젝트 관리자에게 붙이는 새로운 이름이 아니다. 오히려 PO에게는 내용, 릴리스 일정, 우선순위, 비전 등을 선택하고 바꿀 수 있는 독립적인 권한이 있어야 한다. 물론 이해관계자와 협력해야 하지만, 진정한 PO에게는 최종 의사결정 권한이 있다.

다섯 가지 관계

PO는 레스(LeSS) 적용의 영향을 받는 다섯 가지 핵심 관계를 이해하고 개선하기 위해 노력해야 한다.

  • PO<–>팀
    팀은 PO가 고객에게 가장 적합한 제품을 만드는 데 도움을 주려고 존재한다. 팀은 다음에 무엇을 개발할지, 이미 개발했던 것이 목적을 이루었는지 알아야 한다. PO는 팀에게 무엇이 필요하고, 어떻게 하면 팀을 도울 수 있는지 알아야 한다.
  • PO<–>고객
    PO 및 팀은 고객에게 가장 적합한 제품을 만들려고 노력하고 있다. 고객은 관심있는 기능을 언제 얻게 될지, 그리고 우선순위 이면의 이유를 알아야 할 것이다. 가능한 투명하게 해서 고객을 참여시키자. PO는 고객의 진짜 목표와 문제(또는 그 비전을 넘어서 상상하는 무언가)를 알고 우선순위를 잘 정하는 데 도움이 될 정보를 모아야 한다.
  • 팀<–>고객
    팀은 고객에게 가장 적합한 제품을 만들려고 노력하고 있다. 팀은 기능의 맥락을 알고 세부적인 도메인 지식을 알아야 한다. 고객의 (피상적인 목표가 아니라) 필수 목표와 문제를 파악하여 직접 고객과 함께 해결책을 만드는 것이 이상적이다. 팀은 그들이 공동으로 명확화한 요구사항을, 자신들이 완전히 이해하고 있다는 것을 고객에게 확실하게 보여주어야 한다.
  • PO<–>고위 경영진
    제품 그룹 위쪽의 고위 경영진(포트폴리오 관리자, C-레벨 임원 등)은 PO를 제품 성공에 대한 최종적인 책임과 의무가 있는 사람으로 보아야 한다. PO에게는 개발 상태를 가시화하고 바람직한 영향(예를 들어, ROI 및 시장 점유율)을 최적화하기 위한 고위 경영진의 (아마도 암묵적인) 지시 사항을 실현시킬 책임이 있다. PO는 스크럼 마스터의 지원을 받아 조직 설계를 개선할 수 있도록 고위 경영진의 도움을 끌어낸다.
  • PO<->스크럼 마스터
    위 관계들은 “제품 책임(product ownership)”과 직접적인 관련이 있지만, 이번 관계는 다르다. PO의 지식 및 행동과 관련이 있다. 스크럼 마스터는 PO를 도울 수 있도록 그들의 관심, 질문, 장애물을 알아야 한다. 좋은 스크럼 마스터는 이야기를 잘 들어주는 귀가 될 수도 있고, 기대어 울 어깨가 되어줄 수도 있다. 스크럼 마스터는 PO가 적응할 수 있도록 가르치고 피드백을 준다.

LeSS 회의

우리가 레스(LeSS)를 도입할 때 자주 듣는 질문이 있다. “어떻게 한 명의 PO가 그 모든 팀과 하는 회의를 전부 감당할 수 있죠?” 다행히 그 질문에 담긴 걱정은 오해에서 비롯된 것이다. 레스(LeSS)에서 한 명의 PO는 여러 팀이 있어도 회의는 한 군데만 참석한다. 그리고 그 한 회의에 참석하는 팀원 수는 관리할 수 있다. 두 팀만 있다면 누구나 효과적으로 참석하고 참여할 수 있다. 팀이 많다면 각 팀에서 두 명의 대표자만 참석한다.

PO는 어떤 레스(LeSS) 회의에 참석하며, 일반적인 2주 스프린트에서 그 회의의 평균 시간을 얼마나 될까?

따라서 레스(LeSS) 이벤트에 소요되는 총 시간은 2주 스프린트일 때 평균적으로 대략 8시간이다.

PO는 스프린트 계획 파트2, 일일 스크럼, 팀 PBR, 팀 회고 등 특정 팀의 회의에는 참석하지 않는다.