이 글은 공식 LeSS 사이트에 있는 Product Backlog, Product Backlog Refinement, Initial Product Backlog Refinement를 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 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)의 적용

제품 백로그

여러 팀이 한 제품을 만들 때에는, 그 제품에 필요한 모든 업무를 정의하는 하나의 제품 백로그(product backlog)를 사용한다. 각 팀 별로 제품 백로그를 따로 갖지 않는다. 또한, 제품 백로그 항목(product backlog items)을 각 팀에 사전에 나눠 갖지 않는다. 레스(LeSS)에서의 제품 백로그도 한 팀에서 스크럼을 하는 환경에서와 똑같다.

좋은 제품 백로그의 속성

좋은 제품 백로그에는 다음과 같은 속성이 있어야 한다.

  • 모든 항목은 크기가 추정되어 있다.
  • 윗쪽에 있는 항목은 크기가 더 잘게 나뉘어 있고, 아래로 갈수록 항목의 크기가 더 커진다.
  • 우선순위가 매겨져 있다.

제품 백로그 도구

제품 백로그를 관리하는 데에는 간단한 도구를 사용한다. (수천 명이 참여하는) 레스 휴즈(LeSS Huge) 프로젝트에서도 간단한 스프레드시트로 제품 백로그를 관리하는 모습을 보아왔다. 가능한 한 가장 간단한 도구를 제품 백로그 관리에 사용해서, 불필요하고 비용이 많이 드는 문제가 생기는 것을 피하자.

스크럼과 레스(LeSS)에서의 도구 사용에 대해 한 마디 덧붙이고자 한다. 도구가 문제의 원인인 경우는 거의 없음에도 불구하고, 조직에서는 자신들의 문제를 해결해줄 수 있는 도구를 찾아 헤멘다. 문제를 진정으로 깊이 이해하고 있고, 도구가 그 특정한 문제의 올바른 해결책이라는 확신이 없는 한, 도구로 문제를 해결하려고 하지 말자.

제품 백로그 개선 회의 (PBR)

향후에 다가올 스프린트를 준비하려면, 각 스프린트마다 제품 백로그 항목을 개선하는 제품 백로그 개선 회의(PBR, Product Backlog Refinement)를 지속적으로 해야 한다. PBR에서 하는 핵심 활동은 (1) 큰 항목을 분할하고, (2) 더 이상 “무엇”에 대한 질문이 나오지 않을 때까지 구현이 임박한 항목을 명확화하고, (3) 규모, “가치”, 위험 등을 추정하는 것이다. 요약하자면 분할(split), 명확화(clarify), 추정(estimate)을 한다. 경험적 프로세스 제어의 정신에 따라, 스크럼에서는 PBR을 어떻게 하는지에 대해 언급하지 않는다. 그렇지만 스크럼 가이드(Scrum Guide)를 보면 팀은 대개 스프린트 기간의 10%를 미만을 PBR에 사용한다고 말한다. PBR은 보통 “스프린트 중반”에 이루어진다.

주의 사항! 항목을 명확화하는 일은 제품 책임자(PO)나 비즈니스 분석팀이 따로 하는 일이 아니다. 그렇게 하면 린(Lean)에서 말하는 업무 이관(hand-off)에 의한 낭비가 늘어나고 정보가 뿔뿔이 흩어지게 된다. 그렇게 하는 것이 아니라, 이러한 명확화는 팀 전체가 한다. 팀의 일부가 하는 것이 아니라 팀 전체(whole team)가 하는 것이다. 스크럼 규칙을 보면 분석이나 테스트와 같은 특정 영역을 전담하는 하위 그룹을 금지하고 있다.

PBR 개요

레스(LeSS) PBR은 하면 좋은 “활동”이 아니라 반드시 해야 하는 공식 이벤트(워크숍 회의)이며, 다음과 같이 이루어진다.

  • 다중 팀 PBR (Multi-team PBR)
  • 전체 PBR (Overall PBR)
  • 단일 팀 PBR (Single-team PBR)

다중 팀 PBR

다중 팀 PBR(Multi-team PBR)은 레스(LeSS)에서 정렬, 조율, 적응이 훌륭한 팀이 효과적으로 스프린트를 추진하는데 가장 중요한 이벤트일 것이다. 다중 팀 PBR은 (문자 그대로) 여러 팀이 같은 공간 안에서 같은 시간에 PBR을 하는 것을 말한다. (서로 다른 장소에서 하는 응용밥법은 레스(LeSS) 책에서 다룬다.) 모든 팀의 모든 팀원이 참석하며, 주제 전문가, 사용자, 고객, 제품 책임자(PO)를 포함시킬 수도 있다. 대규모 워크숍에는 숙련된 퍼실리테이터가 있는 편이 좋은데, 이것은 스크럼 마스터가 해야 할 중요한 부수적인 역할이다.

다중 팀 PBR을 하는 이유는 공동의 이해를 높이고, 조율의 기회를 활용하며, 추정값을 서로 맞추고, 팀 간에 적응성을 증가시키기 위해서다.

대개는 제품 그룹 안의 모든 팀(레스 휴즈의 경우라면 한 제품 영역 안의 모든 팀)이 함께 한다. 따라서 모든 팀원이 참석한다. “모든 팀”이 있어야 전체 그룹을 개선하는 데 도움이 되기 때문에 그렇게 하기를 권장하지만, 최소 2개 팀의 참여로도 다중 팀 PBR을 할 수 있다.

다중 팀 PBR에서는 다음과 같은 일을 한다.

  • 규모가 큰 항목을 분할한다.
  • 더 이상 “무엇”에 대한 질문이 나오지 않을 때까지 구현이 “임박”한 항목의 세부 사항을 명확화한다.
  • 규모, “가치”, 위험, 그 밖의 적절한 요소 측면에서 항목을 추정한다.
  • 함께 해야 하는 업무, 공통 기반 업무, 조율이 필요한 연관성이 높은 항목을 찾아낸다.

다중 팀 PBR 이벤트 동안 팀 간 학습, 팀 간 대화 및 사회적 연결을 증가시키고 팀 간 조율 기회를 더 많이 찾아내려면 다음과 같은 혼합 그룹 개선 회의(mixed-up group refinement)를 시도해 본다.

  1. N개 팀의 사람들을 N개의 그룹으로 섞는다. 각 그룹에는 여러 팀에서 온 사람들을 함께 구성한다.
  2. 섞인 각 그룹은 동시에 일정 시간 동안 서로 다른 항목을 명확화한다.
  3. 시간이 지나면서 모든 그룹이 모든(또는 대부분의) 항목을 개선할 수 있도록, 그룹 간에 항목을 서로 바꾼다.

전체 PBR

모든 팀과 제품 책임자(PO)가 참여하는 다중 팀 PBR이 더 좋다. 그렇게 할 수 있다면 전체 PBR(overall PBR)에는 관심을 갖지 않아도 된다. 그렇다면 전체 PBR은 언제 하는 것이 좋을까?

전체 PBR을 하는 일반적인 동기는, 그룹이 관련 항목을 두 개의 주요 부분 집합으로 나누어, 네 팀이 한 부분 집합을 담당하고 다른 네 팀이 나머지 부분 집합을 담당하고 싶을 때를 예로 들 수 있다. 이 경우, 모든 팀에서 온 대표자들과 제품 책임자(PO)가 전체 PBR 워크숍을 열어서 (1) 구현이 임박한 모든 항목에 대해 함께 간략하고 가벼운 학습 및 조율을 하고, (2) 연관성이 높은 항목으로 이루어진 주요 부분 집합을 찾고, 나중에 다른 다중 팀 PBR 세션에서 그 부분을 담당하게 될 관련 하위 그룹을 확인한다.

예를 들어, 한 제품 그룹 안에 8개 팀이 있다고 가정해보자. 공통의 전체 PBR 세션에서, 3개 팀이 함께 모여 다중 팀 PBR에서 관련 항목을 논의하기로 하고, 나머지 5개 팀도 따로 모여서 별도의 다중 팀 PBR을 갖기로 결정하는 것이다.

전체 PBR에는 제품 책임자(PO) 그리고 모든 팀의 전체 팀원이나 각 팀에서 온 몇 명의 대표자가 참석한다. 대표자가 참석하는 이유는 회의를 작게 하고 또 다른 회의에 모두를 초대하지 않기 위해서지만, 그 과정에서 정보가 훼손되고 흩어지는 비용이 발생한다.

핵심: 전체 PBR은 짧게 한다. 하는 일은 다중 팀 PBR과 비슷하지만, (시간이 오래 걸리는) 세부적인 명확화를 하는 것이 아니라, 기본적인 이해를 위한 빠르고 가벼운 항목 명확화를 한다.

발생하지 않는 것이 바람직한 두 번째 전체 PBR 사례는 (짧게 해야 하는 것과 관련이 있는데) 안타깝게도 제품 책임자(PO)가 어려운 제약 조건 때문에 다중 팀 PBR 이벤트에 (오래 그리고 깊숙이) 참여할 수 없을 때다. (“휴가로 하와이에 갈 예정이에요.”) 이런 일이 자주 생겨서는 안된다. 보통 때는 제품 책임자(PO)가 다중 팀 PBR에 참여해야 한다. 그러나 해결하기 복잡한 상황이 생기면, 전체 PBR 이벤트에서 구현이 임박한 모든 항목에 대해 제품 책임자(PO)와 최소한의 상호작용을 할 수 있어야 한다.

단일 팀 PBR

단일 팀 PBR(single-team PBR)은 그룹 학습을 억제하고, 조율과 정렬을 약화시키며, 적응성을 감소시키기 때문에 자주 일어나서는 안된다. 단일 팀 PBR이 필요한 한 가지 상황은, 초기 단계에서 리딩 팀(Leading Team)을 활용할 때다. 리딩 팀은 엄청나게 큰 항목이 있을 때 활용하게 되는데 (“새로운 연방 세법 개정안에 대한 추가 지원”), 결국에는 많은 팀에 참여하게 되겠지만, 리딩 팀은 아직 혼란스러운 초기 단계에서 그 거대한 항목을 이해하는 역할을 담당한다. 이 경우, 한 리팅 팀이 먼저 조사하고 그들끼리 여러 스프린트 동안 점진적으로 그 거대 항목에 대한 코드를 만든다. 핵심: 이 단계 동안에는 단일 팀 PBR을 할 수도 있다. 리딩 팀이 그 거대한 항목을 둘러싼 안개를 걷고 나면, 더 많은 팀이 이 노력에 동참하게 되고 리딩 팀은 다른 팀과 함께 다중 팀 PBR로 전환한다.

초기 제품 백로그 개선

첫 번째 스프린트를 시작하기 전에 (1) 준비가 완료된 몇 가지 항목을 포함하는 제품 백로그와 (2) 완료의 정의가 필요하다. 스크럼에서는 이를 위한 활동에 특별한 이름을 붙여 놓지 않았지만, 우리는 초기 제품 백로그 개선(initial PBR, IPBR)이라는 용어를 사용할 것이다. 각 스프린트에서 하는 일반 PBR과 비슷하기 때문이다.

대표적인 활동으로는 비전 정의, 제품 백로그 항목 발굴, 크기가 큰 항목의 분할, 준비 완료 상태가 될 때까지 항목 개선, 위험 식별, “완료” 정의, 추정이 있다.

초기 PBR은 한 제품에서 딱 한 번만 (처음 스크럼으로 전환할 때, 또는 신규 제품을 시작할 때) 수행한다. 이후의 개선은 일반 PBR에서 이루어진다.

공동의 이해 만들기

전체 비전과 특정 항목에 대한 공동의 이해는 팀 간의(다른 사람들과의) 협력을 강화하고, 끊임 없이 변화하는 최우선 항목을 받아들이도록 팀 유연성을 강화하는 데 중요하다. 공동의 이해가 없다면 “요구사항을 모르기 때문에 그렇게 할 수 없어요.”라고 말할 것이기 때문이다.

완료의 정의 만들기

이 워크숍은 대개 초기 완료의 정의를 만드는 곳이다. 이 작업을 수행하는 방법은 완료의 정의에서 확인해보자.