이 글은 공식 LeSS 사이트에 있는 Sprint, Sprint Planning One, Sprint Planning Two, Sprint Backlog, Daily Scrum, Sprint Review, Retrospective, Overall Retrospective를 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 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)에서 스프린트 계획 회의 1(Sprint Planning One)은 모든 팀이 함께 하는 회의이며, 그 회의에서 어떤 팀이 어떤 항목을 담당하게 될지를 공동으로 결정한다. 스프린트 계획 회의 2(Sprint Planning Two)는 각 팀이 별도로 하는 회의이며, 스프린트 기간 동안 담당 항목들을 완료하기 위한 계획을 만든다.

스프린트 계획 회의 1

스프린트 계획 회의는 ‘무엇을’과 ‘어떻게’라는 두 부분으로 압축시킬 수 있다. 스프린트 계획 회의 1은 PO가 제시하는 아직 시작하지 않은 항목을 선택하고, 오랫동안 끌어온 질문들을 마무리하며, 스프린트 목표를 정의하는 데 초점을 맞춘다. 스프린트 계획 회의 2는 각 항목을 ‘완료’로 만들기 위한 업무 계획을 세우는 데 초점을 맞춘다. 스프린트 백로그(Sprint Backlog)에는 행동이나 작업에 대한 항목 및 계획으로 구성되어 있다.

스프린트 계획 회의 1을 위한 팁

스프린트 계획 회의 1은 비교적 간단하고 짧게 끝나는 경우가 많다. 다음은 이 회의를 제대로 하기 위한 팁이다.

  • 참가자 수를 제한한다. 두 팀 뿐이라면 전원이 참여할 수 있다. 두 팀 이상이라면 팀 당 한두 명의 대표자를 보낸다. (스크럼 마스터는 대표자가 될 수 없다.)
  • PO는 제품 백로그에서 우선순위가 가장 높은 항목을 팀에게 준다.
  • 팀은 자기들끼리 알아서 항목을 나누어 갖는다.
  • 항목과 관련이 있는 (제품 백로그 개선 회의에서 미리 해결하지 못한) 모든 미해결 질문에 대해 논의한다.
  • 스프린트 기간 동안 팀 간 조율이 필요한지 논의하고, 필요하다면 멀티팀 스프린트 계획회의 2를 계획한다.

스프린트 계획 회의 2

스프린트 계획 회의 2는 대부분 한 팀에서 하는 스크럼과 동일하다… 팀은 항목을 ‘완료’로 만들기 위한 계획을 세운다.

다중팀 스프린트 계획 회의 2

두 팀이 비슷한 관련 기능을 담당하거나 같은 컴포넌트에 영향을 미치는 다른 기능을 담당하는 것은 흔한 일이다. 그런 경우에는 멀티팀 스프린트 계획 회의 2를 갖는 것이 유용할 수 있다. 각 팀이 물리적으로 같은 공간에서 각자의 스프린트 계획 회의 2를 수행하면 된다. 이 방법을 통해 각 팀은 다음과 같은 장점을 얻을 수 있다.

  • 설계 시간을 공유할 수 있다.
  • 언제든지 서로에게 질문할 수 있다.
  • 공통의 업무를 조율할 수 있다.
  • 서로에게 함께 일하고 학습할 또 다른 기회를 찾을 수 있다. (팀 사이의 짝 프로그래밍 등)

스프린트 백로그

스프린트 백로그(Sprint Backlog)는 선택된 제품 백로그 항목을 완료하는 데 팀에 필요한 업무 목록이다. 스프린트 백로그는 팀마다 따로 만들며, 레스(LeSS) 스프린트 백로그와 스크럼 스프린트 백로그 사이에는 차이점이 없다.

일일 스크럼

레스(LeSS)에서 일일 스크럼(Daily Scrum)은 팀 별로 이루어지며 단일 팀에서 하는 스크럼과 다르지 않다.

팀은 15분 동안 함께 하며, 그 동안 각 팀원은 다음 세 가지 질문에 답한다.

  • 나는 어제 무엇을 했는가?
  • 나는 오늘 무엇을 할 것인가?
  • 내 앞을 가로막는 것은 무엇인가?

이것은 팀에게 스프린트 목표를 달성하기 위해 책임을 공유하고 스스로를 관리하는 데 필요한 정보를 준다. 일일 스크럼은 스크럼 마스터나 관리자를 위한 회의가 아니라 팀을 위한 회의다.

레스(LeSS)에서는 일일 스크럼에 다른 팀 사람들을 관찰자로 초대함으로써 팀 간 조율에 사용할 수 있다. 팀원들은 일일 스크럼에서 학습한 정보를 기반으로, 일일 스크럼이 끝난 이후에 후속 논의를 할 것인지 결정할 수 있다.

일일 스크럼과 관련된 또 다른 조율 기법으로는 스크럼의 스크럼(Scrum of Scrums)이 있는데, 대개는 일주일에 세 번 한다. 스크럼의 스크럼에서는 각 팀 대표자(스크럼 마스터가 아닌 실제 업무에 참여하는 팀원)가 만나 팀 간에 어떤 조율이 필요한지 결정한다. 스크럼의 스크럼은 대개 단일 팀에서 하는 일일 스크럼과 비슷한 형식을 따른다. 다만 팀 간 상호작용에 관련된 것에만 초점을 맞춘다. 레스(LeSS)에서는 스크럼의 스크럼을 추천하지는 않지만, 효과가 있다면 유지하는 것도 나쁘지 않다.

스프린트 리뷰

스프린트 리뷰(Sprint Review)는 스프린트가 끝에 있는 검토-적응(inspect-adapt) 지점이다. 스프린트 리뷰에서는 고객과 이해관계자가 팀이 스프린트 동안 만든 것을 살펴보고 변경 사항과 새로운 아이디어를 논의한다. 팀, PO, 사용자/고객/이해관계자가 함께 제품의 방향을 결정한다.

스프린트 리뷰의 개요

스프린트 리뷰는 모든 팀이 ‘하나’의 잠재적으로 출시가능한 제품 증분을 함께 검토할 수 있는 기회다. 제품 전체에 초점을 맞춘다.

검토-승인(inspect-accept)이 아니라 검토-적응(inspect-adapt)을

스프린트 리뷰에서 하는 가장 흔한 실수는 팀이 작업한 항목을 PO가 승인하는 데 초점을 맞추는 것이다. 이것은 스프린트 리뷰의 목적을 오해한 것이며, 그 목적이 경험적 프로세스 제어에서 누군가를 탓하는 쪽으로 가버린다. 스프린트 리뷰는 모든 사람들이 제품에 대해 협력할 수 있는 기회다.

스프린트 리뷰 바자

스프린트 리뷰는 회의가 발산-수렴(diverge-converge) 패턴일 때 가장 효과적이다. 발산기에는 바자(bazaar)를 이용한다. 이것은 과학전람회와 유사하다. 큰 방안에 각 팀 대표자가 배치된 여러 구역이 있고, 거기에서 팀마다 개발한 항목을 보여주고 논의한다. 이해관계자는 관심있는 구역을 방문한다.

수렴기에는 이해관계자가 바자에 대한 자신의 의견을 요약한다. 이 시간에 항목 중 일부는 빔 프로젝터를 사용할 수도 있다.

발산기와 수렴기를 여러 차례 반복하기도 한다.

회고

스프린트가 끝날 때, 모든 팀이 개별적으로 회고(Retrospective) 시간을 갖는다. 한 팀에서 하는 스크럼 회고와 동일하다.

각 팀이 별도로 회고를 하는 동안, 이들은 자신들과 다른 모든 팀을 방해하는 더 큰 장애물에 대해 브레인스토밍 하고, 그것을 조직 개선 백로그에 올리는 활동도 해야 한다.

전체 회고

전체 회고(Overall Retrospective)는 레스(LeSS)에서 새로 만든 회의다. 그 목적은 조직 내에서 팀 간 문제, 조직 및 제도 문제를 논의하는 것이다.

탐색해야 할 질문들

전체 회고에서 탐색해야 할 제도 및 조직 이슈는 단일 팀에서 다룰 수 있는 수준을 넘어선다. 전체 회고에서 논의할 수 있는 주제는 다음과 같다.

  • 팀들은 얼마나 잘 협력하고 있는가?
  • 실천공동체는 얼마나 효과적인가?
  • 어떤 팀에게 공유해야 할 것이 있는가?
  • 팀들이 함께 학습하고 있는가?
  • 팀들은 고객과 가까운가?
  • 팀 운영 방식에 문제를 일으키는 제도적 조직적 이슈가 있는가?
  • PO는 잘 하고 있는가?
  • PO가 자신의 다섯 가지 관계를 유지하고 있는가?

참석자

전체 회고에는 PO, 스크럼 마스터, 팀 대표자, (만약에 있다면) 관리자가 참석한다.

시기

개념적으로 전체 회고는 팀 회고 바로 뒤에 이어서 한다. 그러나 실제로는 스프린트 마지막 날 끝무렵에 팀 회고를 하는 경우가 많기 때문에 문제가 생길 수 있다. 사람들이 지친 상태인 경우도 많고, 또 다른 회고 회의를 계속할 시간이 없는 경우도 있다.

이 문제를 해결하는 흔한 방법은 전체 회고를 다음 스프린트를 시작할 때 하는 것이다.

시스템 사고

전체 회고에서 중요한 도구는 인과 도표를 사용하는 것이다. 참석자들이 화이트보드 앞에서 이슈를 선택하고 여러 원인을 함께 탐색하도록 하면 큰 통찰과 실질적이고 유용한 변화로 이어질 수 있다.