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

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

아래 그림에서 볼 수 있는 것처럼, 피처팀(feature team)은 오랫동안 유지되고, 여러 직군이 섞여 있으며, 컴포넌트를 넘나들며 개발하며, 여러 고객 기능(feature)을 처음부터 끝까지 하나씩 완성하는 팀이다.

피처 팀의 특징은 다음과 같다.

  • 오랫동안 유지된다(long-lived) – 팀은 더 높은 성과를 위해 ‘뭉칠(jell)’ 수 있도록 함께 지낸다. 시간이 지나면서 새로운 기능을 맡게 된다.
  • 여러 직군이 섞여 있으며(cross-functional), 컴포넌트를 넘나들며(cross-component) 개발한다.
  • 같은 자리에서 함께 일한다.(co-located)
  • 모든 컴포넌트와 분야(분석, 프로그래밍, 테스트 등)에 걸쳐서 완전한 고객 중심 기능(customer-centric feature)을 담당한다.
  • T자형 인재(generalizing specialist)들로 구성되어 있다.
  • 스크럼에서는 보통 7 ± 2명의 인원으로 되어 있다.

피처팀을 채택할 때에는 현대적인 공학 실천법 (특히 지속적인 통합) 적용이 필수적이다. 지속적인 통합(CI, continuous integration)은 코드 공동 소유를 촉진하는데, 이것은 여러 팀이 같은 컴포넌트에서 동시에 업무를 진행할 때 꼭 필요하다.

피처 팀의 모든 팀원이 시스템 전체를 알아야 한다고 흔히들 오해한다. 하지만 그렇지 않다. 그 이유는 다음과 같다.

  • (각 개인이 아니라) 팀 전체에 고객 중심 기능을 전부 구현할 수 있는 기술이 필요하다. 여기에는 테스트, 상호작용 설계, 프로그래밍과 같은 요소적 지식과 기능적 기술을 포함한다. 그러나 팀 내에서 사람들은 여전히 (가능하자면 여러 분야에서) 전문화되어 있다.
  • 어떤 기능이 어떤 피처팀에게 무작위적으로 할당되는 것은 아니다. 팀의 현재 지식과 기술을 반영해서 어떤 팀이 어떤 기능을 담당할지 결정한다.

피처팀 조직 안에서는 전문화가 제약 조건이 되면… 학습이 일어난다.

요구사항이 팀 보유 기술과 관련이 있다면, 피처팀 조직은 전문화에서 얻을 수 있는 속도의 장점을 활용한다.
그러나 요구사항이 팀 보유 기술과 관련이 없다면, 학습이 ‘강제화’ 되고, 지나친 전문화라는 제약 조건이 허물어지게 된다.
피처팀은 전문화와 유연성 사이에서 균형을 잡는다.

컴포넌트 팀 vs. 피처 팀

아래에 있는 표과 그림은 피처 팀과 전통적인 컴포넌트 팀 간의 차이점을 보여준다.

컴포넌트 팀 (Component Team)피처 팀 (Feature Team)
가능한 많은 코드 라인 수를 전달하도록 최적화되어 있음가능한 많은 고객 가치를 전달하도록 최적화되어 있음
‘쉽고’ 가치가 낮은 기능을 구현해서 개인의 생산성을 높이는 데 집중함가치가 높은 기능과 시스템 생산성에 집중함 (가치 처리량)
고객 중심 기능의 일부에만 책임이 있음고객 중심 기능의 전체에 책임이 있음
전통적인 방법으로 팀을 구성함 (콘웨이의 법칙을 따름)‘현대적’인 방법으로 팀을 구성함 (콘웨이의 법칙을 피함)
‘일을 위한 일’과 영원히 성장하는 조직으로 이어짐고객에게 집중하고, 가시성이 있고, 보다 작은 조직으로 이어짐
팀 간의 의존성이 추가 계획 수립으로 이어짐유연성을 높이기 위해 팀 간의 의존성을 최소화함
한 가지의 전문화에 집중함여러 가지의 전문화에 집중함
코드는 개인/팀 소유코드는 제품 전체가 소유
명확한 개인 책임팀 공동의 책임
결과적으로 ‘폭포수’ 개발이 됨반복 개발을 뒷받침함
기존 전문성을 활용하며, 새로운 기술을 학습하는 수준이 낮음유연성을 활용하며, 지속적이고 광범위하게 학습함
허술한 공학 실천법을 사용함 (효과가 지역적임)숙련된 공학 실천법이 필요함 (효과를 폭넓게 확인할 수 있음)
생각과는 달리 컴포넌트 내 품질 낮은 코드로 이어지는 경우가 많음코드를 쉽게 유지보수하고 테스트하기 위한 동기를 제공함
실행하기 쉬워 보임실행하기 어려워 보임

아래 표는 피처 팀과 전통적인 프로젝트 그룹 또는 피처 그룹 간의 차이를 요약한 것이다.

피처 팀 (Feature Team)피처 그룹 또는 피처 프로젝트 (Feature Group / Feature Project)
수년 동안 함께하며 여러 기능을 개발한 안정적인 팀하나의 기능 또는 프로젝트를 위해 만들어진 임시 그룹
모든 업무에 팀이 함께 책임을 지님전문성을 근거로 ‘담당’ 부분에 개인적인 책임을 지님
스스로 관리하는 팀프로젝트 관리자가 통제함
결과적으로 단순한 단일 라인 조직이 됨 (매트릭스 아님!)결과적으로 리소스 풀로 된 매트릭스 조직이 됨
팀원은 팀에 100% 헌신함전문화 때문에 구성원들은 여러 프로젝트에 파트 타임으로 참여

다음 그림은 Scaling Lean & Agile Development의 “Feature Teams” 챕터에서 살펴본 컴포넌트 팀의 가장 큰 단점을 요약한 것이다.

컴포넌트 팀 구조는 크기가 천차만별인 업무 덩어리로 인한 많은 대기열, 높은 WIP, 많은 핸드오프, 멀티태스킹 및 부분 할당의 증가가 특징인 순차 개발(‘폭포수’ 또는 V 모델)을 강화한다는 점이 때로는 보이지 않는다.

컴포넌트 팀을 선택해야 할까, 피처 팀을 선택해야 할까?

순수한 피처팀 조직은 가치 전달 및 조직 유연성 관점에서 이상적이다. 하지만, 가치와 유연성만이 조직 설계의 유일한 기준은 아니며, 따라서 많은 조직이 하이브리드 형태로 마무리하게 된다. (특히 컴포넌트 팀에서 피처 팀으로 전환하는 동안) 하이브리드 모델은 양쪽의 단점을 모두 갖고 있으며… 고통스러울 수 있다.

가장 자주 볼 수 있는 하이브리드 조직을 지지하는 이유는 인프라를 구축하고, 재사용 가능한 컴포넌트를 구성하고, 코드를 정리하는 (전통적으로 컴포넌트 팀 안에서 이루어지는) 일이 필요하기 때문이다. 그러나 이러한 활동은 순수한 피처 팀 조직 안에서도 (영구적인 컴포넌트 팀을 만들지 않고도) 이루어질 수 있다. 어떻게 할 수 있을까? 제품 백로그에 인프라, 재사용 가능 컴포넌트, 정리 업무를 추가하고 (마치 고객 중심 기능이었던 것처럼) 기존 피처팀에게 준다. 피처팀은 (제품 책임자가 바라는 한) 일시적으로 이러한 업무를 수행한 후 다시 고객 중심 기능을 구축한다.

피처 팀으로의 전환

컴포넌트 팀에서 피처 팀으로 바꿀 때에는 조직마다 서로 다른 전환 전략이 필요하다. 우리는 효과가 있는 여러 전략을 경험해보았다… 그리고 다양한 상황에서 실패를 경험하기도 했다. 안전한 (그러나 느린) 전환 전략은 기존 컴포넌트 팀 조직 내부에 하나의 피처팀을 구성하는 것이다. 이 팀이 좋은 성과를 거두면, 두 번째 피처팀을 만든다. 조직에서 편안하게 느끼는 속도로 꾸준이 이렇게 계속한다. 다음 그림이 그 전략을 볼 수 있다.

추천 자료