---

Scrum 프레임워크를 확장하는 방법(분산 및 대규모 프로젝트)은 무엇일까요? 놀라실 수도 있습니다!

지금까지 설명한 Scrum 프레임워크는 한 장소의 단일 Scrum Team에서 가장 잘 작동합니다. 그러나 현실에서는 단일 팀이 프로젝트 전체를 구현하지 못하거나 팀원이 여러 장소에 흩어져야 하는 경우가 많습니다.

한 팀이 제품 요구를 충족하지 못하면 팀 추가를 고려할 수 있습니다. 지리적 분산만으로 팀이 더 필요한 것은 아니며 인원 추가는 조율 비용을 높일 수 있습니다. 또한 팀이 지리적으로 먼 장소나 대륙에 분산된 경우도 많이 보았습니다.

여러 장소에 팀을 분산하는 이유는 다양합니다.

• 기술적 이유: 소프트웨어의 개별 컴포넌트를 만드는 일부 노하우를 본사 지역에서 구할 수 없음,
• 전문성 관련 이유: 여러 엔지니어링 활동의 일부 역량을 현지에서 구할 수 없음. 예를 들어 테스트 자동화, 인터페이스 설계, 자체 소프트웨어와 다른 공급업체 소프트웨어의 통합에는 외부 전문가가 필요할 수 있음,
• 규모 관련 이유: 정해진 일정에 고객에게 제공하려면 더 많은 사람이 필요함. 단일 Scrum Team에 합리적으로 담을 수 있는 수를 넘는다면 한 팀을 끝없이 키우기보다 결속된 여러 팀이 필요할 수 있음,
• 사업 관련 이유: 비용이 낮은 지역의 인력이나 다른 시간대의 엔지니어로 업무 연속성을 확보하는 것은 좋은 사업 근거가 될 수 있음.

소통은 Scrum의 필수 요소이므로 모든 팀원은 분산 프로젝트 환경의 어려움을 극복하는 데 주의해야 합니다. 모두가 음성·화상회의와 화면 공유 등 소통 도구에 접근할 수 있어야 합니다.

흔히 쓰이는 프로젝트 관리 도구는 건전하고 지속적인 소통을 지원합니다. Product Backlog, Sprint Backlog, 사고 목록, 지식 및 소식 공유 도구 등이 포함됩니다.

프로젝트 조직: 여러 팀

대규모 프로젝트에서 Scrum을 확장하는 가장 간단한 방법은 같은 장소의 팀 수를 늘리는 것입니다.

여러 팀이 함께 구현해야 한다면 팀 수를 점진적으로 늘리는 것이 가장 좋습니다.

여러분에게 어떤 의미일까요?

한 장소의 여러 팀

대부분의 조직에서는 새 팀 열 개를 한꺼번에 시작하기보다 점진적인 성장이 관리하기 쉽습니다. 단일 팀으로 시작하는 것이 모범 사례입니다. 몇 번의 성공적인 Sprint 후 한두 팀이 합류할 수 있습니다. 여러 팀이(자세한 내용: 여러 Scrum 팀) 잘 협업하는지 확인한 뒤 분산 프로젝트 조직에 계속 추가할 수 있습니다.

팀 수 늘리기

새 Scrum Team을 만드는 전형적인 방법은 두 가지입니다.

• 기존 팀을 여러 팀으로 나누고 필요한 때와 장소에 새 팀원을 추가하기,
• 지금까지 프로젝트에 참여하지 않은 완전히 다른 엔지니어들로 새 팀 구성하기.

기존 팀을 나누면 진행 중 프로젝트를 이미 알고 경험한 팀원들을 활용할 수 있습니다.

따라서 새 팀은 구성 즉시 어느 정도 생산성을 갖는 경우가 많습니다. 큰 단점은 완전히 기능하던 팀을 두 팀으로 나누었다는 점이며 의욕 문제가 생길 수 있습니다. 특히 고위 리더십의 사전 공지와 근거 설명 없이, 팀원이 정신적·기술적으로 준비되지 않은 상태에서 바꾸면 그렇습니다.

완전히 새 팀을 추가하면 기존 팀은 구조와 Sprint를 유지할 수 있습니다. 새 팀과의 조율, 온보딩, 통합에는 여전히 관심이 필요합니다. 다만 완전히 새로운 팀이 필요한 노하우와 추진력을 갖추는 데 더 오래 걸립니다.

추가 방식과 관계없이 다음 원칙을 기억하세요.

• 적은 수의 Scrum 팀으로 시작하기,
• 팀 수를 점진적으로 늘리기,
• 변화와 성장 중 업무 연속성 및 소프트웨어와 사업 가치의 원활한 제공 확보하기,
• 생산성과 업무 연속성을 막는 큰 문제가 있다면 새 팀 확장보다 먼저 해결하기.

프로젝트 조직: 분산 팀

여러 팀의 주요 복잡성은 새 팀들이 여러 장소에 분산될 때 드러납니다. 사람 사이 소통 장벽, 업무 조율의 어려움, 공동 규범의 오해는 많은 복잡성 중 일부일 뿐입니다.

여러 장소의 여러 팀

이 어려움을 해결하지 않으면 결과는 심각합니다.

기업은 다음 역량 부족으로 수십억 달러의 IT 예산 낭비를 감수합니다. 조직 리더십 및 확장 Scrum 전문성.

대응을 위한 네 가지 중요한 제안입니다.

• 새 팀원이 다음 수준으로 Scrum 프레임워크 교육을 받도록 하세요. 확장 Scrum 전문가,
• 프로젝트를 적절히 소개하여 무엇을 위해 일하는지 이해하게 하세요. 기술뿐 아니라 전문적인 사업 가치 관점에서도 이해해야 기여 가치를 높이는 결정을 내릴 수 있습니다.
• 프로젝트 규범을 마련하세요. 단일 팀에 소통, 계획, 수행 규범이 있듯 다중 팀 조직에도 상위 규범이 있어야 함께 소통하고 계획하고 운영하며 문제를 해결하고 고객 및 사업 가치를 제공할 수 있습니다.
• 새 팀원들이 최소한 일시적으로라도 경험 많은 프로젝트 구성원과 함께 일하도록 하세요. 원격 현장 방문과 현장 교육이 필요할 수 있으며 이는 괜찮을 뿐 아니라 바람직합니다. 노하우를 원활히 전달하고 서로 다른 팀과 장소의 사람들 사이에 양방향 개인 대화를 형성할 수 있습니다.

가상 팀

또 다른 분산 Scrum 방식은 한 팀의 구성원이 여러 장소에 흩어지는 것입니다. 이를 “가상 팀”이라고 합니다.

주요 과제는 완전한 팀원 소통입니다. 모든 필수 이벤트로 작업을 조율해야 하지만 이제 모두 같은 방에 있지 않은 상태에서 해야 합니다.

가상 팀

같은 장소의 팀원은 유용하다면 공용 공간에서 일하고 원격 구성원도 충분히 참여하도록 할 수 있습니다. 협업과 소통 도구에 더 의존해야 합니다. 같은 회의실에서 화상회의로 가상 팀의 다른 구성원과 연결하여 이벤트에 참여할 수 있습니다.

Scrum Product Owner Team

여러 번 설명했듯 Product Owner와 팀의 정기적인 소통은 성공적인 프로젝트 제공에 중요합니다.

다른 장소의 팀도 제품 결정에 효과적으로 접근할 수 있어야 합니다. 단일 제품의 팀은 Product Owner, Product Goal, Product Backlog를 공유합니다. Product Owner는 지원 작업을 위임해도 책임을 유지합니다. 모든 팀에 별도의 최종 책임 Product Owner를 추가할 필요는 없습니다.

이 판은 “Scrum Product Owner Team”과 “Chief Scrum Product Owner”를 조직 협업 방식으로 설명합니다. Product Owner가 대리인이나 다른 제품 전문가와 일할 수 있지만 이 직함은 추가 Scrum 책임이 아니며 하나의 제품에 책임지는 단일 Product Owner를 대체하지 않습니다.

이 협업의 지원을 받는 책임 Product Owner는 다음을 확보하는 데 집중합니다.

• 고객 요구를 충족하는 올바른 제품 만들기,
• Product Owner와 대리인의 효과적인 협업으로 팀이 고객의 사업 및 기술 가치를 만들도록 돕기.

효과적인 Backlog 관리는 여전히 Product Owner의 책임입니다. 다른 역량과 이해관계자 의견은 요구사항 지원 작업에 유익합니다. 사업 근거 담당자, 관련 이해관계자, 기업 아키텍트, 기술 아키텍트 등이 포함될 수 있습니다.

같은 제품의 Product Owner와 지원 기여자는 순서가 정해진 하나의 Backlog에서 공동 Product Goal을 향해 일합니다. 각 팀은 일부 사용자 스토리 제공을 책임집니다. 그래도 여러 팀의 관심과 결과물이 필요한 특정 스토리는 생길 것입니다.

컴포넌트 팀과 기능 팀 비교

작업을 나눌 때 특정 소프트웨어 컴포넌트나 기능을 팀의 책임으로 정할 수 있습니다. 그래서 “컴포넌트 팀”이나 “기능 팀”이라고 부릅니다.

컴포넌트 팀

각 팀은 전체 시스템의 특정 컴포넌트 구현만 책임집니다. 스토리를 완료하려면 보통 단일 컴포넌트 안에 구현할 작은 부분으로 나누어야 합니다. 컴포넌트 간 의존성 때문에 성공적인 제공에 지속적인 통합이 필수적입니다.

Scrum Product Owner Team

의존성은 Sprint 안에 완전한 기능을 제공하기 어렵게 할 수 있습니다. 협업과 통합으로 해결해야 합니다. 같은 제품의 팀에는 여전히 공통 Definition of Done을 충족하는 통합된 사용 가능한 Increment가 필요합니다.

이로 인해 진행 중이지만 아직 통합되지 않은 작업의 묶음 크기와 리드 타임이 늘어납니다. Scrum 팀은 더 작은 묶음과 짧은 리드 타임으로 출시 가능한 Increment를 목표로 해야 하므로 좋게 들리지 않습니다.

장점은 특정 컴포넌트의 아키텍처와 설계 세부사항에 집중하여 전문성을 쌓기 쉽다는 것입니다. 탐색과 혁신이 필요한 컴포넌트에 매우 유익할 수 있습니다.

반면 구성원들은 전체 시스템의 개별 컴포넌트만 전문화합니다. 전체 시야와 기능의 사업상 필요를 놓칠 수 있습니다.

고객은 컴포넌트가 아니라 사업 수행에 쓸 기능을 제공하는 대가를 지불한다는 점을 기억하세요. 기능에 끊임없이 집중하지 않으면 전체 최적화와 통합에 시간이 더 들 수 있습니다. 개별 컴포넌트를 최적화하는 결정은 전체 해결책의 성공과 성능에 보이지 않는 병목을 만들 수 있습니다.

컴포넌트 팀

기능 팀

Product Backlog에 명시된 사용자 스토리 구현을 전적으로 책임집니다. 여러 컴포넌트에 따라 팀을 나눌 필요가 없습니다. 각 팀은 완전히 작동하는 기능과 그 사업 가치 제공을 책임집니다.

기능 팀

구성원들은 교차 기능 역량을 갖추고 빠른 제공을 위해 가능한 한 자율적으로 행동합니다. 시스템 지식을 유지하므로 자신의 기능을 나머지 시스템과 통합하기 쉽다는 장점이 있습니다.

다만 컴포넌트의 충분한 노하우를 쌓기 더 어려울 수 있습니다. 여러 분야를 아우르는 팀 구성은 쉽지 않아 빠르고 독립적으로 제공하는 자율 기능 팀을 만드는 데 시간이 듭니다. 그래도 여러분의 조직을 포함한 대부분의 조직에서 일을 해내는 고성과 팀입니다.

컴포넌트 팀과 기능 팀은 어떻게 선택하나요?

실제로 대부분의 큰 조직은 전담 컴포넌트 팀과 기능 팀을 모두 사용합니다.

컴포넌트 팀과 기능 팀

그림의 팀 C는 컴포넌트 팀입니다. 기능 팀인 다른 팀에 계획되었거나 요청에 따른 기반 시설 서비스를 제공합니다. 팀 C는 전 과정의 사용자 스토리를 직접 구현하지 않습니다. 기능 팀이 이행을 약속한 스토리의 요구사항을 제공합니다.

따라서 기능 팀에서 해당 컴포넌트 노하우를 가진 전문 인력의 수를 최소화할 수 있습니다.

분산 프로젝트 환경의 Scrum Master

분산 환경에서는 Scrum Master의 역할이 더욱 중요합니다. 이러한 구조에서는:

• Scrum 가치에 팀들의 방향을 맞추는 추가 노력이 필요합니다.
• 여러 팀에 영향을 주는 개별 팀 및 프로젝트 규범(표준)을 마련하는 데 더 오래 걸립니다.
• 마지막으로 팀과 결과물의 의존성이 늘어 장애물이 많아집니다.

Scrum Master는 접근하기 쉽고 효과적으로 지원해야 합니다. 같은 장소에 있으면 유익하지만 필수는 아니며 원격 지원도 가능합니다. 분산 구조는 Scrum Master가 다음을 하게 해야 합니다.

• 팀 진척의 장애물 제거를 돕기,
• 효과적인 업무 합의를 마련하도록 돕기,
• Scrum 프레임워크 사용을 개선하도록 돕기.

일부 조직은 팀 간 코칭과 조율을 위해 Lead(Primary) Scrum Master를 둡니다. 선택적인 조직 방식이며 필수 위계나 각 팀 책임의 대체가 아닙니다.

큰 조직의 각 Scrum Team에는 여전히 Scrum Master 책임과 자체 이벤트, 자기 관리, 개선에 대한 효과적인 지원이 필요합니다.