이 글은 공식 Less 사이트에 있는 LeSS Rules (April 2018)를 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 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)의 규칙은 레스 프레임워크를 정의한 것이다. 그리고 우리가 반드시 고려해야하는 것들이다. 왜냐고? 그 이유는 왜 레스(LeSS)인가?에서 설명하고 있다.

레스 프레임워크(LeSS Framework)의 규칙

레스(LeSS) 프레임워크는 2-“8″팀이 함께 개발하는 제품에 적용한다.

Large Scale Scrum (LeSS) Framework

레스(LeSS)의 구조

  • 진짜 팀을 조직의 기본 구성 요소로 사용해서 조직을 구성한다.
  • 각 팀은 (1) 스스로 관리하고, (2) 여러 직군이 섞여 있으며, (3) 같은 자리에서 함께 일하고, (4) 오랫동안 유지되어야 한다.
  • 대부분의 팀은 고객 중심의 피처팀(feature team)이다.
  • 스크럼 마스터들에게는 레스(LeSS)를 훌륭하게 적용할 책임이 있다. 그들의 초점은 팀, 제품 책임자(PO), 조직, 개발 실천법을 향한다. 스크럼 마스터는 어느 한 팀이 아니라 전반적인 조직 체계에 초점을 맞춘다.
  • 스크럼 마스터는 풀타임 전담 역할이다.
  • 한 명의 스크럼 마스터는 1-3개 팀을 담당할 수 있다.
  • 레스(LeSS)에서 관리자가 반드시 필요한 역할은 아니지만, 만약 관리자가 존재한다면 그들의 역할은 기존과 다를 것이다. 관리자는 자신의 초점을 매일 매일 이루어지는 제품 관련 업무를 관리하는 것에서 제품 개발 체계의 가치 전달 능력을 향상시키는 것으로 옮긴다.
  • 관리자의 역할은 “가서 보기(Go See)”, “멈추고 고치기(Stop & Fix)”, “순응보다는 실험”을 통해 제품 개발 체계를 향상시키는 것이다.
  • 제품 그룹의 경우, “시작하는 시점”에 완전한 레스(LeSS) 구조를 구성한다. 레스(LeSS)를 적용할 때 이는 필수적이다.
  • 제품 그룹 이상의 더 큰 조직의 경우, 실험과 개선이 표준인 조직을 만들 수 있도록 “가서 보기”를 활용해 점진적으로 레스(LeSS)를 적용한다.

레스(LeSS)의 제품

  • 완전한 출시 가능 제품에는 한 명의 제품 책임자(PO)와 하나의 제품 백로그(Product Backlog)가 있다.
  • 제품 책임자(PO)는 제품 백로그 개선 작업을 혼자 해서는 안된다. 고객/사용자 및 기타 이해관계자들과 직접적으로 함께 일하는 여러 팀의 도움을 받는다.
  • 모든 우선순위 변경은 제품 책임자(PO)를 통해 이루어지지만, 그 의미를 명확히 하는 일은 팀과 고객/사용자 및 기타 이해관계자 사이에서 가능한 많이 직접적으로 이루어져야 한다.
  • 제품의 정의는 가능한 한 범위가 넓고 최종 사용자/고객 중심이어야 한다. 시간이 지남에 따라 제품의 정의는 확장될 수 있다. 더 넓은 정의가 더 좋다.
  • 모든 팀은 전체 제품에 하나의 완료의 정의(Definition of Done)를 공통으로 적용한다.
  • 각 팀은 공통의 완료의 정의를 확장해서 더욱 강력한 우리 팀만의 완료의 정의를 사용할 수 있다.
  • 완벽환 목표는 각 스프린트(Sprint)마다 (또는 더욱 자주) 출시 가능 제품이 될 수 있도록 완료의 정의를 개선하는 것이다.

레스(LeSS)의 스프린트

  • 각 팀이 따로 스프린트를 하는 것이 아니라 제품 수준의 스프린트 하나만 있다. 각 팀은 스프린트를 동시에 시작하고 동시에 종료한다. 스프린트가 끝날 때마다 통합된 전체 제품이 나온다.
  • 스프린트 계획 회의(Sprint Planning)는 두 파트로 이루어진다. 스프린트 계획 파트1은 모든 팀이 함께 모이고 스프린트 계획 파트2는 대개 각 팀이 별도로 한다. 스프린트 계획 파트2는 밀접한 관련이 있는 항목들을 다루기 위해 여러 팀이 같은 공간에서 진행한다.
  • 스프린트 계획 파트1에는 제품 책임자(PO)와 팀 또는 팀 대표자가 참석한다. 그들은 함께 각 팀이 해당 스프린트에서 진행할 항목을 잠정적으로 선택한다. 팀은 함께 일할 기회를 찾아내고 최종 질문을 명확히 한다.
  • 각 팀마다 별도의 스프린트 백로그(Sprint Backlog)가 있다.
  • 팀은 스프린트 계획 파트2에서 선택된 항목을 어떻게 할지 결정한다. 여기에는 보통 설계 및 스프린트 백로그 생성을 수반한다.
  • 각 팀마다 별도로 일일 스크럼(Daily Scrum)을 진행한다.
  • 팀 간 조율은 각 팀에 의해 결정된다. 중앙 집중식 조율보다는 분권화되고 비공식적인 조율을 선호한다. 그냥 만나서 대화(Just Talk)하거나 코드, 팀 간 회의, 컴포넌트 멘토(component mentor), 트래블러(traveler), 스카우트(scout), 열린 공간에서의 소통을 통한 비공식 네트워크를 강조한다.
  • 제품 백로그 개선(PBR, Product Backlog Refinement)은 공동 학습을 늘리고 조율의 기회로 활용하도록 가급적이면 여러 팀과 함께 하는 것이 바람직하다.
  • 스프린트 리뷰(Sprint Review)는 제품에 하나만 있다. 모든 팀이 함께 한다. 효과적인 검토 및 적응에 필요한 정보를 줄 수 있는 적절한 이해관계자들이 참여할 수 있도록 한다.
  • 스프린트 회고(Sprint Retrospective)는 각 팀마다 별도로 한다.
  • 팀 간 그리고 시스템 전반의 이슈를 논의하고 개선 실험을 만들기 위한 전체 회고(Overall Retrospective)는 팀 회고 이후에 이루어진다. 이 자리에는 제품 책임자(PO), 스크럼 마스터, 팀 대표자, (만약에 있다면) 관리자가 참석한다.

레스 휴즈 프레임워크(LeSS Huge Framework)의 규칙

레스 휴즈(LeSS Huge)는 “8+” 팀이 함께 개발하는 제품에 적용한다. 더 작은 제품 그룹에 레스 휴즈(LeSS Huge)를 적용하지 말자. 그렇게 하면 비용이 더 늘고 지역 최적화가 발생하게 될 것이다.

특별한 언급이 없다면 모든 레스(LeSS) 규칙이 레스 휴즈(LeSS Huge)에 적용된다. 각 요구 영역(Requirement Area)은 마치 기본 레스 프레임워크와 같은 역할을 한다.

Large Scale Scrum (LeSS) Huge Framework

레스 휴즈(LeSS Huge)의 구조

  • 고객 관점에서 봤을 때 관련이 깊은 고객 요구사항들을 요구 영역(Requirement Area)으로 묶는다.
  • 각 팀이 하나의 요구 영역을 전담한다. 팀은 한 영역을 오랫동안 담당한다. 다른 영역이 더 중요해지면 요구 영역을 바꿀 수도 있다.
  • 각 요구 영역마다 한 명의 영역 제품 책임자(APO, Area Product Owner)가 있다.
  • 각 요구 영역에는 “4-8″개의 팀이 있다. 이 범위는 반드시 지키도록 한다.
  • 구조적 변화를 포함하는 레스 휴즈(LeSS Huge) 적용은 점진적으로 확대하는 방식으로 이루어진다.
  • 날마다 기억하자. 레스 휴즈(LeSS Huge) 적용에는 수 개월 또는 수 년이 걸리고, 무한한 인내심 그리고 유머 감각이 필요하다.

레스 휴즈(LeSS Huge)의 제품

  • 한 명의 (전체) 제품 책임자(PO)에게는 제품 전반의 우선순위 그리고 어떤 팀이 어떤 영역을 담당할지 결정할 책임이 있다. 제품 책임자(PO)는 영역 제품 책임자(APO)들과 긴밀하게 협력한다.
  • 영역 제품 책임자(APO)들은 자신의 팀에서 제품 책임자(PO)의 역할을 한다.
  • 제품 백로그는 하나다. 제품 백로그에 있는 모든 항목은 정확히 하나의 요구 영역에 속한다.
  • 요구 영역마다 하나의 영역 제품 백로그(Area Product Backlog)가 존재한다. 이 백로그는 개념적으로 제품 백로그를 보다 세분화 한 것이다.

레스 휴즈(LeSS Huge)의 스프린트

  • 각 요구 영역이 따로 스프린트를 하는 것이 아니라 제품 수준의 스프린트 하나만 있다. 스프린트가 끝나면 통합된 전체 제품이 나온다.
  • 제품 책임자(PO)와 영역 제품 책임자(APO)들은 자주 만나 상황을 공유한다. 스프린트 계획 회의 전에는 팀들이 가장 중요항 항목을 작업하고 있는지 확인한다. 스프린트 리뷰 후에는 제품 수준의 적응이 더 잘 이루어질 수 있도록 한다.