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

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

[설계]를 구성하는 방법에는 두 가지가 있다.
그 중 하나는 분명하게 결함이 없도록 단순하게 만드는 방법이고,
다른 하나는 분명한 결함이 없도록 복잡하게 만드는 방법이다.

토니 호어(C.A.R. Hoare)

한 팀에서 하는 스크럼

스크럼은 경험적으로 프로세스를 제어하는 개발 프레임워크이며, 여러 직군으로 구성된 자기 관리팀(Team)이 반복적이고 점진적인 방식으로 제품을 개발한다. 기한이 정해져 있는 반복 주기인 각 스프린트마다, 이상적으로는 그대로 출시할 수도 있는 잠재적으로 출시 가능한 제품 증분(potentially shippable product increment)을 내놓는다. 한 명의 제품 책임자(PO, Product Owner)는 제품의 가치를 극대화하고, 제품 백로그(Product Backlog)에 있는 항목(items)의 우선순위를 결정하며, 지속적인 피드백과 학습을 기반으로 각 스프린트의 목표를 상황에 따라 조정해서 결정할 책임이 있다. 팀(Team)은 작은 규모로 이루어져 있고, 스프린트 목표를 달성할 책임이 있으며, 팀 내에는 한 가지 일만 전문적으로 하는 역할이 없다. 스크럼 마스터(Scrum Master)는 스크럼을 통해 가치를 얻으려는 이유와 그 방법을 가르치고, 이를 적용하기 위해 PO, 팀, 조직을 코칭하며, 거울의 역할을 한다. 프로젝트 관리자나 팀 리더는 필요치 않다.

경험적으로 프로세스를 제어하려면 투명성(transparency)이 필요한데, 이는 짧은 주기의 개발과 출시 가능한 제품 증분의 리뷰로부터 얻는다. 경험적 프로세스 제어에서는 제품에 대한 지속적인 학습, 검토, 적응과 제품을 만들어내는 방법을 강조한다. 세부적이고 공식적인 프로세스를 정형화하는 것은 지나치게 복잡하고 동적이어서, 그것이 질문, 참여, 개선을 제한한다고 생각한다.

스크럼 가이드와 스크럼 프라이머에서는 한 팀에서 하는 스크럼을 강조하며, 여러 팀이 함께 일하는 것이 초점은 아니다. 그래서 대규모 스크럼(large-scale Scrum)에 대한 고민으로 자연스럽게 이어지게 된다.

레스(LeSS)

레스(LeSS)는 여러 팀이 하나의 제품을 함께 만들 때 적용하는 스크럼이다.

레스(LeSS)는 스크럼이다—대규모 스크럼(LeSS, Large-Scale Scrum)은 새로운 것도 아니고 스크럼을 개선한 것도 아니다. 그리고 밑바닥에 있는 각 팀에서는 스크럼을 하고(Scrum at the bottom for each team), 상부에는 다른 레이어가 덮여있는 무언가(something different layered on top)도 아니다. 레스(LeSS)는 대규모 상황에서 가능한 단순하게 스크럼의 원칙, 목적, 요소, 우아함을 적용하는 방법을 알아낸 것에 가깝다.

팀 수준에서만 스크럼을 하도록 되어 있는 특수한 확장 프레임워크를 확장 스크럼이라고 할 수 없다. 진정한 확장 스크럼(Scaled Scrum)이란 스크럼 자체를 확장시킨 것이다.

레스(LeSS)는 여러 팀에 적용한다—이 팀들은 항목을 완료하고 출시 가능한 제품을 만들어내기 위해, UX부터 코드, 비디오에 이르기까지 모든 일을 수행하는 3-9명의 인력으로 구성된 교차 기능, 교차 컴포넌트, 풀스택 피처팀이다.

레스(LeSS)는 함께 만들 때 적용한다—여러 팀은 공통의 스프린트가 끝날 때 하나의 출시 가능한 제품을 공통으로 내놓는 것이 공통의 목표이기 때문에 제품을 함께 만들며, 각 팀은 부분이 아니라 전체(whole)를 함께 책임지는 피처팀이기 때문에 여기에 관심을 기울인다.

레스(LeSS)는 하나의 제품에 적용한다—어떤 제품에 적용하는가? 실제 고객이 사용하는 폭넓고(broad) 완전한(complete) 종단(end-to-end) 고객 중심(customer-centric) 솔루션에 적용한다. 컴포넌트, 플랫폼, 레이어, 또는 라이브러리에 적용하는 것이 아니다.

• 배경 •

2002년에 크레이그가 Agile & Iterative Development라는 글을 썼을 때, 많은 이들이 애자일 개발은 작은 그룹에서만 가능한 것이라고 생각했다. 하지만, 우리 둘 다 (크레이그와 바스) 규모가 크고, 장소가 여러 군데이며, 개발이 해외에서 이루어지는 상황에 스크럼을 적용하는 데 관심을 갖게 되었고, 점점 더 많은 요청을 받았다. 그래서 2005년부터 우리는 스크럼을 확장시키기 위해 고객사들과 협력해왔다. 지금은 두 가지 레스(LeSS) 프레임워크(레스와 레스 휴즈)가 서로 다른 분야에 있는 전세계 대형 그룹에서 적용하고 있다.

  • 통신 장비 – Ericsson & Nokia Networks
  • 투자 및 일반 은행 — UBS
  • 거래 시스템 – ION Trading
  • 마케팅 플랫폼 및 브랜드 분석 – Vendasta
  • 화상 회의 — Cisco
  • 온라인 게임(카지노) — bwin.party
  • 해외 아웃소싱 — Valtech India

규모 관점에서 전형적인 레스(LeSS) 적용 사례는 무엇일까? 아마도 한 두 군데 장소에 있는 다섯 개 정도의 팀일 것 같다. 우리는 이 정도의 규모, 인원이 수백 명 정도인 규모, 천 명이 훨씬 넘어서 사무실이 여러 군데이고 수천만 라인의 C++ 코드가 있으며 커스텀 하드웨어를 보유하고 있는 레스 휴즈(LeSS Huge) 사례까지 참여해봤다.

레스(LeSS)에 대해 더 학습하기

사람들의 학습을 돕기 위해 고객사와의 경험을 바탕으로 2008년과 2010년에 두 권의 레스(LeSS) 프레임워크를 통한 대규모 애자일 개발 책을 출간했다.

  1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum — 이 책은 사고, 리더십, 조직 설계의 변화를 설명한다.
  2. Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum — 이 책은 고객사와의 경험을 기반으로 제품 관리, 아키텍처, 계획 수립, 분산 팀, 해외 개발, 계약 등 레스(LeSS)에 대한 수많은 구체적인 실험을 담고 있다.

Large-Scale Scrum: More with LeSS은 레스(LeSS) 시리즈의 세 번째 책으로 프리퀄이자 입문서이다. 이 책은 가장 중요한 내용을 종합하고, 명확히 하고, 강조한다.

이 책들 이외에도 less.works에서 (책, 글, 비디오 등) 온라인 학습 자료, 교육 과정, 코칭에 대해 찾아보자.