이 글은 공식 LeSS 사이트에 있는 Coordination & Integration를 옮긴 것이다.

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

스크럼에서는 전통적인 프로젝트 관리에서 찾아볼 수 있는 중앙집중적(centralized)이고 통제적(controlled)인 조율보다, 분권화(decentralized) 되어있고 자기조직적(self-organized)인 조율 및 통합을 중요하게 여긴다. 레스(LeSS)에서의 조율 및 통합(coordination & integration)은 혼돈을 피할 수 있는 충분한 경계와 구조를 제공하면서도 동시에 분권화 조율을 뒷받침할 수 있는 방법에 초점을 맞춘다.

그냥 대화하기

아마도 팀 사이를 조율하는 최선의 방법은 그냥 그 팀들이 알아서 조율하는 방법일 것이다. 자기 관리(self-managing)팀의 팀원이라면 누구든지 논의할 이슈가 있다면 다른 팀과 접촉할 수 있으며 마땅히 그래야 한다. 조율이 필요한 상황이 생기면, 다른 팀으로 직접 가서, 또는 전화를 걸어서, 가장 소극적인 방법으로는 이메일을 보내서 “그냥 대화(Just Talk)”하면 된다. 조율을 하는 데 정형화 되어 있고 공식적인, 그래서 대개는 느린 그런 메커니즘은 필요치 않다. 그냥 자리에서 벌떡 일어나 사람들과 대화하면 된다.

코드로 소통하기

레스(LeSS)를 적용하는 그룹은 지속적인 통합(CI)를 활용하는데, 이는 모든 사람이 자신의 코드를 중앙 저장소의 메인라인(브랜치는 피해야 할 불필요한 복잡성이다)에 체크인한다는 뜻이다. 제품팀에 있는 모두는 하루에도 여러 차례 저장소를 동기화하고 다른 사람들의 변경 사항을 전부 받아보게 된다.

그래서, 업데이트를 할 때에는 2분 정도 다른 사람들이 변경한 내용을 살펴보고 현재 작업 중인 것과 관련이 있는지 확인한다. 만약 그렇다면, 자신의 업무와 다른 사람의 업무를 동기화하기 위해, 자유롭게 자리에서 일어나 “그냥 대화”하면 된다!

일일 스크럼에 관찰자 보내기

관련 업무를 하는 다른 팀의 일일 스크럼에 조용히 관찰만 하는 (스크럼마스터가 아닌) 대표자를 파견하는 것도 팀에서 활용할 수 있는 간단한 조율 방법 중 하나다. 관찰자는 팀으로 돌아와서 함께 필요한 조치를 취할 수 있도록 그 내용을 공유한다.

컴포넌트 커뮤니티와 멘토

같은 컴포넌트를 동시에 작업하는 사람들은 상대방의 코드에 대해 질문하고 리뷰할 수 있도록 서로를 알아야 한다. 메일링 리스트, 채팅, 간헐적 회의, 그 밖의 원격 협업 채널을 통한 컴포넌트 실천 공동체(CoP, Communities of Practice)를 만드는 방식으로 그렇게 할 수 있다.

이런 공동체, 즉 커뮤니티는 “컴포넌트 멘토(component mentor)”를 중심으로 구성하는 경우가 많다. 컴포넌트 멘토는 피처 팀의 구성원 중 한 명이지만 (1) 컴포넌트 작동 방식에 대한 교육, (2) 컴포넌트의 장기적인 품질 모니터링, (3) 컴포넌트 커뮤니티 조직화, (4) 설계 워크숍 개최, (5) 코드 리뷰 등과 같은 일을 추가로 담당한다.

컴포넌트 멘토가 코드 리뷰를 하는 것은 커밋하기 전에 승인받기 위한 목적이 아니다. 컴포넌트 멘토는 컴포넌트에서 선생님이자 집사의 역할을 하는 것이지, 문지기로 있는 것이 아니다.

컴포넌트에는 서로의 업무를 공유하는 여러 명의 멘토가 있을 수도 있다. 그렇게 하면 핵심 인력에 대한 의존성이 줄어든다.

중요!… 이 실천법은 조율에 보탬이 되는 것 말고도, 컴포넌트의 코드/설계 품질을 유지하거나 개선하는데 도움이 되고, 학습을 강화할 수 있다.

스크럼의 스크럼

스크럼의 스크럼(Scrum of Scrums) 회의란 보통 일주일에 두세 번 열리며 일일 스크럼과 비슷한 팀 간 회의다.

대개의 형식은 일일 스크럼과 비슷하게 세 가지를 질문한다.

  • 우리 팀은 다른 팀과 관련한 무슨 일을 했는가?
  • 우리 팀은 다른 팀과 관련한 무슨 일을 할 것인가?
  • 다른 팀이 알아야 하거나 도움을 줄 수 있는 우리 팀의 장애물은 무엇인가?

유용하다는 생각이 드는 질문이라면 뭐든지 던져보고 자연스럽게 발전시킨다.

주의: 스크럼의 스크럼 회의가 필요하다는 생각은, 단일 기능 그룹 및 컴포넌트 팀에 때문에 생기거나, 공동의 업무를 처리하는 역량이나 의지가 부족한 팀에 의해 발생하는 불필요한 의존성 또는 조율 문제가 있음을 가리키는 신호일 수 있다.

스크럼의 스크럼은 레스(LeSS)의 일부가 아니며, 보다 공식적인 중앙집중적 조율 기법으로서도 권장되지 않는다. 그렇기는 하지만, 효과가 있다면 하지 않을 이유는 없다… 다만 레스(LeSS)를 적용하기 때문에 반드시 해야 한다고 생각하지는 말자.

다중 팀 회의

서로 긴밀하게 협력할 필요가 있는 팀도 있지만 그렇지 않은 팀도 있을 수 있다. 긴밀히 협력하는 팀끼리는 다중 팀 레스(LeSS) 회의를 갖는 것이 일반적이다. 다음과 같은 회의가 있다.

여행가 활용을 통한 병목 해소 및 기술 개발

한 제품 그룹이 경험이 풍부한 기술 전문가 두어 명에게 의존하는 경우가 있다. 어떻게 하면 이런 (부족한) 전문가의 지식을 모든 팀에서 활용할 수 있을까? 전문가들이 여행가(traveler)가 될 수 있다. 각 스프린트마다 각기 다른 팀에 합류해서 짝 작업, 워크숍, 교육 세션을 통해 코칭하는 것이다.

여행가 활용이 특별히 조율이 목적인 것은 아니지만, 여행가는 여러 팀에서 일하면서 네트워크를 만들고 강화하는데, 그것이 바로 비공식적 조율 채널에 필요한 것이다. 이들은 팀 간의 지식이나 실천법의 일관성을 높여주고 조율의 목표를 실현시킨다.

리딩 팀(Leading Team)

기능(feature)의 크기가 엄청나게 큰 분야도 있다. 이러한 거대 항목을 더 작은 제품 백로그 항목으로 분할할 때 많은 팀이 긴밀하게 협력해야 하며, PBI를 각자 따로 진행하면 한 덩어리로 된 괴물같은 기능이 생겨나기도 한다.

커다란 관련 기능을 분할해서 생겨난 여러 항목을 함께 작업할 때, 여기에 참여하는 여러 팀을 조율하는 또 다른 기법으로 리딩 팀(leading team)이 있다. 리딩 팀은 전체적으로 거대한 기능을 선도하는 역할을 담당하는 정규 피처 팀일 뿐이다. 개발 업무 이외에 추가로 다른 팀이 하는 일을 계속 추적하고 동기화를 돕는 일도 담당한다. 간단히 말해서, 리딩 팀은 자기들이 개발하는 것 이외에 관련 거대 기능에 대해 팀간 조율을 주도한다.

여러 팀이 거대 기능을 동시에 구현하기 시작할 때도 있다. 반대로, 리딩 팀이 초기 지식 전달에 초점을 맞추고 단순하며 응집력 있는 설계를 하기 위해 혼자 시작할 때도 있다. 몇 번의 스프린트 이후에는 더 많은 팀이 합류한다. 이 경우, 리딩 팀에게는 새로 들어오는 팀이 지식을 빠르게 습득할 수 있도록 도울 책임도 있다.