규모가 너무 커서 최적의 스크럼 팀 규모 가이드

게시 됨: 2022-03-11

이 기사의 오디오 버전을 들어보세요

작은 스타트업에서 일하든 대기업에서 신제품을 개발하든 한 팀에 너무 많은 사람들이 있는 시점에 오기 쉽습니다. 징후를 조기에 식별하면 팀의 가장 비효율적인 단계에 도달하는 것을 막을 수 있습니다.

모든 제품이 다르고 작업하는 팀도 다릅니다. 따라서 팀을 나누려면 상황을 반영하는 몇 가지 결정을 내려야 합니다. 고려해야 할 사항은 다음과 같습니다.

팀원이 더 이상 함께 일하지 않을 때 노하우 무결성을 유지하는 방법
기능별로 분할해야 합니까(예: 프론트엔드 및 백엔드 팀)?
새 팀에 별도의 백로그가 있어야 합니까?
그에 따라 제품 관리 팀도 성장해야 합니까?

언제 두 번째 팀 만들기를 시작해야 합니까?

팀 분할 또는 새 팀 추가에 대해 생각하기 시작하는 가장 분명한 징후는 예산이 증가할 때입니다. 이는 스타트업에 대한 새로운 투자 라운드나 기업에서 제품에 대한 새로운 목표에 발생할 수 있습니다. 예산 증가가 너무 커서 팀이 3배 이상 성장할 경우, 노하우를 배포하기 위해 현재 팀을 분할해야 하는 것은 당연합니다. 그러나 예산 증가가 점진적이고 명단에 몇 명의 새로운 사람을 추가하게 되면 결정이 그렇게 명확해지지 않습니다. 예를 들어 팀을 7명에서 11명으로 늘릴 계획이 있다면 분할이 필요합니까? Agile은 소규모 팀을 촉진하지만 프로세스와 도구에 대한 개인과 상호 작용도 촉진합니다. 둘 이상의 팀이 있으면 필연적으로 동기화하여 작업할 수 있는 더 많은 프로세스가 생성됩니다.

전문가들은 무엇이라고 말합니까?

Amazon의 창립자인 Jeff Bezos는 회의와 팀 모두에 피자 2판 규칙을 사용하고 있습니다. 즉, 점심에 피자 2판을 먹일 수 있는 양만큼만 사람이 먹을 수 있어야 합니다.

스크럼 가이드에서는 스프린트 백로그를 실제로 실행하는 팀원이 3~9명이라고 제안합니다. 즉, 스프린트 백로그 항목을 구현하지 않는 한 제품 소유자 또는 스크럼 마스터를 합계에 포함하지 않습니다.

이 숫자는 직관적으로 이해되는 것처럼 보이지만 그 이면에 수학이 있습니다. 팀을 생각하면 모든 사람이 노드와 같으며 다른 노드와 연결됩니다. 팀원들 간의 대인관계입니다. 그들은 친절하거나 경쟁적이거나 악의적이거나 배려할 수 있습니다. 두 사람 사이의 관계가 무엇이든 관계는 여전히 각 사람의 정신적 능력이 필요한 연결입니다. 팀이 성장함에 따라 이러한 링크의 수는 선형적으로 증가하지 않습니다. 노드 간의 링크 공식은 \(n(n-1)/2\)입니다. 링크 성장 차트는 다음과 같습니다.

차트는 팀이 너무 크지 않을 때 가장 효율적으로 운영되는 이유를 수학적 관점에서 명확하게 보여줍니다. 스크럼 가이드에서 제안한 3~9명의 팀원을 모으면 3~36개의 링크가 생깁니다. 만약 우리가 15명으로 성장한다면, 우리는 100개가 넘는 링크를 갖게 될 것입니다. 이 팀은 임무가 매우 잘 정의되고 중복되는 경우가 거의 없거나 비공식적인 하위 그룹이 있는 경우에만 효율적으로 운영할 수 있습니다. 애자일 원칙을 기반으로 작업할 때는 그렇지도 않고 바람직하지도 않습니다.

팀이 너무 커지고 있다는 신호

일일 스크럼

때때로 데일리 스탠드업이라고도 하는 데일리 스크럼은 스프린트의 진행 상황과 장애물에 대해 논의하기 위해 전체 팀이 모이는 것입니다. 스크럼 가이드는 15분으로 시간을 정할 것을 제안하며 이는 팀 규모에 대한 좋은 리트머스 테스트입니다. 팀이 15분 막대를 초과 실행하고 있다는 것을 알아차리기 시작하면 다음 두 가지 중 하나를 나타낼 수 있습니다.

일일 스크럼은 효율적이지 않습니다. 사람들은 너무 많은 세부 사항에 들어가고 있습니다. 또는 명확한 발언 순서가 없고 팀원이 발언하는 데 시간이 걸립니다. 어쩌면 제품 오너나 스크럼 마스터는 스프린트와 관련이 없는 다양한 업데이트를 제공하는 기회로 일일 스크럼을 사용하고 있을지도 모릅니다.
팀이 너무 큽니다. 일일 스크럼이 효율적이지만 여전히 15분을 초과한다면 팀에 너무 많은 사람들이 있을 수 있습니다. 또한 한 사람이 받아들일 수 있는 정보의 양에는 한계가 있기 때문에 사람들이 관심을 잃는다는 사실을 인지해야 합니다. 너무 많은 사람들이 업데이트를 제공하면 모든 사람의 진행 상황을 추적하고 팀의 상태를 이해하기 어려워집니다. . 이것은 사람들로 하여금 다른 사람을 도울 기회를 찾지 않고 내면으로 돌아서고 자신의 발전에 대해서만 반성하게 만듭니다.

몸단장 및 스프린트 계획

그루밍과 스프린트 계획은 모두 사용자 스토리를 분석하고 전달 시간 또는 크기를 추정하는 것과 관련된 활동입니다. 더 많은 사람이 있으면 팀이 더 나은 결정을 내리는 데 도움이 될 수 있지만 너무 많은 사람이 있으면 팀이 교착 상태에 빠질 수 있습니다. 동일한 작업을 수행하는 데는 항상 다른 방법이 있으며 팀에 있는 사람의 수에 따라 양쪽의 논쟁 수가 늘어납니다.

일일 스크럼과 마찬가지로 비효율적인 계획 세션을 너무 큰 팀과 혼동하지 마십시오. 궁극적으로 스크럼 행사를 효율적이고 효과적으로 만드는 것이 스크럼 마스터의 임무입니다.

회고

회고 기간 동안 팀원들은 논쟁이나 갈등을 해결하고 작업 프로세스를 개선할 수 있는 방법을 제시할 수 있습니다. 회고는 우리로 하여금 서로 다른 당사자들 사이에서 공통점을 찾도록 하기 때문에 타협의 기술을 가르쳐줍니다. 팀은 구성원들이 차이점에 대해 기꺼이 타협하는 만큼 강력합니다.

그러나 스프린트 계획과 마찬가지로 너무 많은 팀 구성원이 너무 많은 링크를 생성하며 이 모든 것이 잠재적인 충돌 지점입니다. 회고를 하는 동안 점점 더 공통점을 찾지 못하는지 알아차리기 시작하십시오. 팀이 너무 커서 분할이 도움이 될 것이라는 신호일 수 있습니다.

팀 분할 방법

표면적으로 팀을 나누는 것은 비교적 쉬운 작업입니다. 팀 구성원을 두 그룹으로 나누고 각 그룹에 비슷한 경험을 가진 사람들이 있는지 확인하고 새 팀의 목표를 정의합니다. 그러나 새 팀의 미래 성공에 큰 영향을 미칠 수 있는 몇 가지 고려해야 할 사항이 있습니다.

팀 사기

아마도 명심해야 할 가장 중요한 것 중 하나는 팀 사기일 것입니다. 하루가 끝나면 새로운 구성에서 작업해야 하는 것은 팀의 사람들입니다. 팀이 Agile 원칙 측면에서 성숙했다면 스스로 분할할 수 있어야 합니다. 이것은 팀원들이 내부 관계를 가장 잘 알고 있기 때문에 가장 바람직한 결과입니다.

교차 기능 팀

스크럼은 "제품 증분을 만드는 데 필요한 팀으로서의 모든 기술을 갖춘" 다기능 팀을 촉진합니다. 이는 두 개 이상의 팀으로 확장할 때도 마찬가지입니다. 많은 개발자, 특히 애자일을 처음 접하는 경우 자연스러운 경향은 기술 라인과 함께 생각하는 것입니다. 예를 들어, 팀은 종종 백엔드 팀과 프론트엔드 팀으로 나누기를 원합니다. 이것은 드문 경우에 이해가 될 수 있지만 제품 관리자로서 대부분의 경우 이에 대해 조언해야 합니다. 프론트 엔드로 가득 찬 팀은 자체적으로 제품 증분을 제공할 수 없으며 자연스럽게 기술 역량에 대해 더 많이 생각하기 시작할 것입니다. 이것이 바로 그들을 통합하는 것입니다. 대신, 그들은 고객과 그들의 요구를 충족시키는 방법에 초점을 맞춰야 합니다.

또 다른 흥미로운 고려 사항은 팀의 비개발 역할입니다. 다양한 상황에서 팀에는 디자이너, 비즈니스 분석가 또는 QA 전문가가 포함될 수 있습니다. 팀을 나누면, 특히 새 사람을 너무 많이 고용하지 않는 경우 이러한 역할을 어떻게 처리해야 하는지에 대한 딜레마가 발생합니다. 팀 간에 시간을 나누어야 합니까? 한 팀에만 전념할 새로운 사람들을 고용해야 합니까? 그들은 개발 팀과 협력해야 합니까, 아니면 제품 팀의 일원이어야 합니까?

각 제품이 너무 다르기 때문에 이것에 대한 좋은 단일 조언은 없습니다. 이러한 결정은 팀과 함께 하는 것이 가장 좋으며 도중에 코스를 수정해야 할 수도 있다는 점을 염두에 두십시오.

팀에 별도의 백로그가 있어야 합니까?

팀이 분할된 경우 자연스러운 질문은 동일한 백로그로 작업해야 하는지 아니면 별도의 백로그가 있어야 하는지입니다. Scaled Agile Framework에서 지침을 확인할 수 있습니다.

스크럼@스케일

Scrum@Scale은 Scrum Guide의 작성자가 개발한 방법론입니다. Scrum@Scale은 규범적이지 않으며 제품 백로그를 처리하는 방법을 구체적으로 설명하지 않습니다. 그러나 다음 두 가지 사항에 유의합니다.

팀 수준 프로세스는 스크럼 가이드에 나와 있는 것과 동일합니다.
제품 소유자는 제품 소유자 팀을 구성하여 단일 통합 백로그를 생성합니다. 이는 업무의 중복을 방지하고 회사 내에서 가시성을 확보하기 위해 수행됩니다. 동시에 팀에는 통합 백로그에서 항목을 공급하는 별도의 백로그가 있습니다.

따라서 본질적으로 Scrum@Scale은 새로운 팀에 각자의 PO와 백로그를 이미지화합니다. 팀 간의 작업을 조정하기 위해 몇 가지 추가 구조를 추가할 뿐입니다. Scrum@Scale은 여러 팀, 수십 또는 수백 팀에서 가장 잘 작동하지만 두 팀과 함께 작업하는 경우에도 몇 가지 귀중한 통찰력을 제공할 수 있습니다.

대규모 스크럼(LeSS)

LeSS는 제품 백로그에 대한 흥미로운 접근 방식을 장려합니다. LeSS에서는 제품 소유자가 2~8개의 팀과 함께 작업합니다. 한 PO가 많은 팀과 작업하는 것은 불가능해 보일 수 있습니다. LeSS 철학은 PO가 추상적인 수준에서 작동하고 제품 백로그 항목 개선 책임을 팀에 위임한다는 것입니다. 이 경우 교차 기능 개발 팀은 제품 증분을 제공할 수 있도록 비즈니스 도메인 지식도 포함해야 합니다. LeSS에는 백로그가 하나만 있습니다.

결론

팀이 성장함에 따라, 특히 다음과 같은 상황에서 팀이 너무 커지고 있다는 몇 가지 징후를 알아차리기 시작할 것입니다.

일일 스크럼. 매일 스크럼을 하는 동안 15분이라는 시간을 초과하여 사람들이 흥미를 잃기 시작하는 것을 보면.
스프린트 계획. 스프린트 계획 중에 교착 상태에 빠지는 경우가 점점 더 많아집니다.
회고전. 회고 중에 타협에 도달하기가 점점 더 어려워지고 있음을 알아차리기 시작하면.

이 모든 것은 팀을 분할해야 할 수도 있다는 사실을 나타냅니다. 팀을 나누는 것은 겉보기에 쉬운 작업이지만 지속적인 결과를 가져오기도 하며 모든 제품 관리자는 그렇게 할 때 몇 가지 고려해야 할 사항이 있습니다.

팀 사기. 이상적으로는 부서지는 좋은 업무 관계의 수를 최소화하기 위해 팀이 분할 방법을 결정하도록 해야 합니다.
교차 기능 팀. 팀은 제품 증분을 만드는 데 필요한 모든 기술을 갖추고 있어야 합니다.
제품 백로그. 팀에 별도의 백로그 또는 단일 통합 백로그가 있는지 결정합니다.

둘 이상의 팀을 추적하려면 우선 순위를 지정해야 합니다. 효과적인 제품 관리자는 새 팀과 최신 정보를 유지하는 방법을 계획해야 합니다.

회의를 우선시하십시오. 어떤 애자일 의식이 시간을 들일 가치가 있고 어떤 것이 무시될 수 있는지 생각해 보십시오.
스크럼 마스터와 협력하십시오. 스크럼 마스터를 팀 대리인으로 사용하고 정보를 수집하십시오.
제품 팀을 확장합니다. 함께 일할 사람을 추가하고 매일 반복되는 작업을 돕거나 사용자 조사 및 시장 분석을 수행합니다.

이러한 제안을 활용하여 깔끔한 팀 분할이 가능해야 합니다. 팀이 계속 성장하고 앞으로 더 많은 팀을 추가할 예정이라면 규모에 맞게 Agile에 대한 구조 및 프로세스 제안을 제공하는 Scaled Agile Framework에 대해 읽어야 합니다.