대규모 스크럼 팀 운영을 위한 SAFe 프레임워크
조직 내 기능적인 스크럼 팀을 구축하는 것 자체가 쉽지 않은 일이며, 많은 조직들이 이 과정에서 어려움을 겪습니다. 하지만 동일한 제품이나 가치 흐름 안에서 여러 팀이 상호 의존적으로 운영될 때는 더욱 체계적인 접근 방식이 필요합니다.
이러한 문제를 해결하기 위해 스크럼 팀을 포괄하는 확장된 프레임워크를 활용하는 것이 중요합니다. 이 프레임워크는 팀들이 서로 조화를 이루고 목표를 잃지 않도록 프로세스와 규칙을 제공합니다.
흔히 개별 스크럼 팀들은 전체 프로그램의 공동 목표보다는 각자의 로컬 목표에만 집중하는 사일로 팀으로 운영되는 경우가 많습니다. 이러한 상황에서 SAFe(Scaled Agile Framework)가 중요한 역할을 합니다.
SAFe란 무엇인가?
출처: SAFe는 기존의 계층적 조직 구조에 애자일 프레임워크와 프로세스를 적용하는 방식입니다. 구조적 수준과 프로세스를 다루면서도, 기존 시스템의 이해관계자들이 익숙한 방식으로 유기적으로 시스템을 재구성합니다.
SAFe는 다음과 같은 핵심 가치를 중심으로 구축되었습니다.
조정
- 모든 스크럼 팀은 조직의 비전과 전략, 그리고 궁극적인 목표를 명확히 이해해야 합니다.
- 팀 간의 전략을 연결하고 협력을 통해 공동 목표를 달성해야 합니다.
- 팀들이 쉽게 이해할 수 있는 공통 언어로 소통해야 합니다.
- 팀들이 목표와 비전을 제대로 이해하고 있는지 지속적으로 확인해야 합니다.
- 팀은 고객 중심적이어야 하며, 고객이 누구인지, 무엇을 필요로 하는지 이해하고 전략에 반영해야 합니다.
투명성
- 신뢰를 바탕으로 모든 팀원이 최선을 다해 일할 수 있는 환경을 조성해야 합니다.
- 주장과 사실을 공개적으로 전달하고, 정직하게 행동하며 중요한 사실을 숨기지 않아야 합니다.
- 실패를 두려워하지 않고, 실수를 통해 학습하는 기회로 삼아야 합니다. 성공하지 못한 부분이 있다면 빠르게 인지하고 학습하여 전략을 수정해야 합니다.
- 팀원 모두가 현재 진행 중인 작업을 시각적으로 확인할 수 있도록 해야 합니다.
- 필요한 정보에 즉시 접근할 수 있도록 해야 합니다.
사람에 대한 존중
- 사람을 자원이 아닌 인간으로 대해야 합니다.
- 팀원의 의견과 다양성을 존중하고 솔직한 피드백을 장려해야 합니다.
- 코칭과 멘토링을 통해 팀원들의 성장을 지원해야 합니다.
- 자신의 작업 결과물을 사용하는 고객을 존중해야 합니다.
- 팀 내부 및 외부와 장기적인 파트너십을 구축해야 합니다.
끊임없는 개선
- 팀원들이 문제 해결에 적극적으로 참여하도록 동기를 부여하는 환경을 만들어야 합니다.
- 지난 한 주를 되돌아보고, 더 나은 성과를 위해 개선할 부분을 파악해야 합니다.
- 객관적인 사실을 개선을 위한 가장 중요한 근거로 삼아야 합니다.
- 혁신을 위한 시간과 공간을 제공해야 합니다. 팀에게 안전한 길만이 아닌 다양한 시도를 해볼 수 있는 기회를 제공해야 합니다.
SAFe는 확장된 애자일 시스템에 협업과 소통 계층을 제공합니다. 현재 수행 중인 개별 스크럼 팀의 스프린트 활동을 대체하는 것이 아닙니다.
SAFe의 핵심 구성 요소는 Agile Release Train(ART)입니다. ART는 각 스프린트 릴리스 후에 정기적으로 새로운 기능을 제공하는 스크럼 팀(일반적으로 최대 12개)으로 구성된 장기적이고 안정적인 팀입니다. 이들은 하나 이상의 솔루션을 개발, 제공 및 지원합니다.
출처: SAFe의 역할
SAFe는 다양한 책임을 가진 사람들에게 의존합니다. 각자의 역할에 대한 기대치를 정확히 지키는 것은 프레임워크 성공의 중요한 요소이므로, 각 역할이 무엇이고 어떤 목적을 가지는지 이해하는 것이 중요합니다.
#1. 애자일 팀
애자일 팀은 다기능 팀입니다. 즉, 팀 내부에서 실행해야 할 모든 부분을 처리할 수 있는 역량을 갖추고 있습니다. 또한 가치 증분을 정의, 구축, 테스트, 배포 및 릴리스하는 자체 조직적인 주체입니다.
각 애자일 팀은 합의하고 약속한 범위를 실행하기 위한 기술 세트를 보유하고 있습니다. 팀은 예측 가능한 방식으로 각 스프린트의 범위를 확장합니다. 예측 가능성은 팀이 특정 시간 내에 목표를 달성하기 위해 노력할 수 있도록 해주기 때문에 매우 중요합니다. 소통과 협업은 팀이 지속적으로 개선해야 할 중요한 가치입니다.
애자일 팀은 스프린트 내에서 스토리를 만들고 계획하는 PI(프로그램 증분) 계획 세션의 핵심입니다. 그리고 자체 PI 목표를 설정하고 약속합니다.
스크럼 마스터는 애자일 팀을 코칭하고 팀 회의를 진행하며, 장애물을 제거하고 외부 영향으로부터 팀을 보호합니다. 또한, ART의 일부로서 스크럼 회의에 참여합니다.
제품 담당자(PO)는 팀의 또 다른 중요한 구성원입니다. PO는 고객의 목소리를 대변하며 스토리와 우선순위에 직접적인 영향을 미칩니다. PO는 다른 PO와 협력하여 팀 백로그의 스토리를 정의하고 우선순위를 지정합니다.
#2. 제품 관리
제품 관리는 스크럼 팀 상위에 위치하여 팀 간의 조정을 관리합니다. 이들의 주요 책임은 다음과 같습니다.
- 개발팀이 지속 가능하고 실현 가능한 제품과 솔루션을 만들어 비즈니스 목표를 달성하도록 합니다.
- 고객 요구사항을 이해하고, 정의된 고객 관점에 따라 제품이 완성되었는지 확인합니다.
- 백로그에 항상 준비된 기능이 충분한지 확인합니다.
- 프로그램 보드를 통해 프로그램 백로그의 작업 흐름을 지원합니다.
- 팀이 만든 기능의 우선순위를 결정하여 다음 프로그램 증분 범위를 결정합니다. 제품 관리는 최종적으로 다음 PI 정의를 담당합니다.
#3. 시스템 아키텍트/엔지니어링
엔지니어링 팀은 백로그 스토리에서 합의된 내용을 분석하고 개발합니다. 이들은 팀의 전문적인 기술을 담당하며, 다음과 같은 책임을 수행합니다.
- 새로운 기능이 기술적 지원 요소를 활용할 수 있도록 아키텍처 활주로(Architectural Runway)를 만들고 관리합니다.
- 프로그램 증분 계획에 적극적으로 참여하며, 각 프로그램 증분 종료 시 시스템 데모에 참석합니다.
- 애자일 팀과 협력하여 새로운 아키텍처 구현 요소를 개발합니다. 이를 통해 팀은 새로운 기능을 구축할 수 있습니다.
- 애자일 팀이 높은 수준의 설계 솔루션과 결정을 정의하도록 지원합니다. 애자일 팀 내부에서 개념 증명 활동을 위한 대체 솔루션과 최적의 접근 방식을 제안합니다.
- 각 팀에서 정의한 기능을 사용할 수 있도록 기술 지원 요소를 정의하는 아키텍처 활주로를 만듭니다.
#4. 사업주/이해관계자
이들은 스크럼 팀 외부의 팀이지만 실행의 모든 단계에서 SAFe 프레임워크에서 중요한 역할을 합니다.
PI 계획 이전:
- 백로그 개선 활동에 대한 의견을 제공합니다.
- 필요에 따라 사전 PI 계획에 참여합니다.
- RTE(릴리스 트레인 엔지니어), 제품 관리 및 시스템 설계자를 포함한 열차의 주요 이해관계자들이 비즈니스 목표를 이해하고 동의하는지 확인합니다.
PI 계획 중:
- 다가오는 PI에 대한 비즈니스 컨텍스트와 비전을 제공합니다.
- 초안 계획 검토에 참여하고, 팀 PI 목표에 비즈니스 가치를 부여합니다.
- 경영 검토에 참여하고, 최종 계획 승인으로 이어지는 문제 해결을 지원합니다.
PI 계획 이후:
- 우선순위와 범위가 변경될 때 비즈니스와 개발 조정을 유지하기 위해 적극적으로 참여합니다.
- 프로그램 에픽에 대한 MVP(최소 실행 가능 제품)의 정의를 검증하고, MVP 제공을 기반으로 방향 전환 또는 지속 여부를 결정합니다.
- 시스템 데모에 참석하여 진행 상황을 확인하고 피드백을 제공합니다.
- 필요에 따라 애자일 팀 스프린트 계획 및 스프린트 회고 이벤트에 참석합니다.
- 범위, 품질, 배포 옵션, 릴리스 및 시장 고려 사항에 초점을 맞춘 릴리스 관리에 참여합니다.
#5. 릴리스 트레인 엔지니어(RTE)
RTE는 ART 내의 사람들과 팀의 활동을 조직합니다. 이것은 전체 프로그램에 대한 스크럼 마스터의 역할과 같습니다. 주요 책임은 다음과 같습니다.
- ART를 통한 가치 흐름을 관리하고 최적화합니다.
- 스프린트 및 프로그램 증분(PI)에 대한 연간 일정을 수립하고 전달합니다.
- PI 계획 회의의 진행자를 담당합니다.
- 팀을 구성하고, 식별된 PI 목표에 대한 요약을 작성하도록 돕습니다. 또한 팀의 목표를 전체 PI 계획 목표와 연결합니다.
- 팀들이 서로 위험과 의존성을 공유하고 해결하도록 돕습니다.
- 제품 관리, 제품 소유자 및 기타 외부 이해관계자들을 연결하여, 공통 전략에 따라 이들을 조정합니다.
- 기존 프로세스와 활동을 지속적으로 개선하는 것을 목표로 검사 및 조정 워크숍을 조직합니다.
- 팀 전체에 걸쳐 애자일 방법론 채택의 성숙도 수준을 평가하고, 팀을 개선하기 위한 후속 조치 항목을 정의합니다.
#6. 리더십
리더십은 프로그램 전략을 정의하고 팀이 업무를 수행하는 데 필요한 모든 도구와 지원을 제공합니다. 궁극적으로 이들은 나머지 모든 것이 작동하는 시스템을 정의합니다. 따라서 팀에 올바른 목적과 가치 정의를 제공하는 관리팀을 갖는 것이 중요합니다. 주요 책임은 다음과 같습니다.
- 모범을 보입니다.
- 성장 마인드를 장려합니다.
- SAFe의 가치와 원칙을 강조합니다.
- 팀원을 성장시키고 발전시킵니다.
- 변화를 주도합니다.
- 심리적으로 안정된 환경을 조성합니다.
프로그램 증분(PI) 계획
PI 계획은 다음 프로그램 증분 기간 동안 수행할 작업을 이해하고 약속하는 것을 목표로 하는 2~3일간의 이벤트입니다. 예를 들어, 다음 분기의 기간이 될 수 있습니다.
제품 관리는 PI 계획 중에 식별된 기능의 우선순위를 결정합니다. 애자일 팀은 용량 계획, 스토리 생성, 추정 및 PI 목표 약속을 담당합니다.
PI 계획은 SAFe의 필수 요소입니다. PI 계획을 수행하지 않는다는 것은 SAFe를 제대로 실행하지 않는다는 것과 같습니다.
PI 프로세스
출처: PI 계획은 여러 입력으로 시작합니다. 각 작업 흐름은 제품과 관련하여 다음에 개발하고 싶은 요구 사항과 아이디어를 수집하여 PI에 입력으로 가져옵니다.
- 다음에 구현할 상위 10가지 기능
- 공식화된 에픽 또는 기능의 ART 백로그
- 제품 담당자의 비전
논의는 다양한 작업 흐름 사이에서 시작됩니다. 각 작업 흐름은 자신의 비전과 기능을 제시합니다. 다음에 구현해야 할 중요 사항과 성공을 위해 필요한 것들을 강조합니다. 이는 여러 가지 의미를 가질 수 있습니다.
- 기능을 계속 진행할 수 있도록 다른 작업 흐름에서 활성화가 제공됩니다.
- 다른 작업 흐름에 대한 의존성과 순서를 우선시해야 할 필요성
- 시스템에 존재하며 계속 진행하기 위해 먼저 해결해야 할 현재 문제
- 팀의 인력 문제. 기능에 필요한 콘텐츠 구현을 위해 팀 내 여러 주요 역할이 아직 없을 수 있습니다.
- 예산 제약으로 인해 지정된 시간 안에 비전을 실행할 수 없는 경우
- 팀이 인식하는 다른 위험, 문제, 가정 또는 의존성이 있을 수 있습니다. 이러한 요소는 공통 목표에 맞추어 조정하기 위해 SAFe 팀 전체에서 광범위하게 논의되어야 합니다.
PI 연습
PI 계획 자체는 대개 며칠(일반적으로 2~3일)에 걸쳐 진행되며, 의제는 다음과 같습니다.
1일차
- 전반적인 프로그램 비전과 전략을 구성하는 비즈니스 설명을 제공하고 향후 주요 목표에 대해 논의합니다. 리더십 팀이 이 부분을 담당하고 팀과 명확하게 소통합니다.
- 작업 흐름의 모든 기능을 테이블 위에 놓고 공통 비전에 맞춰 우선순위를 정합니다.
- 아키텍처 비전을 검토하고 개발 요구 사항의 주요 목표를 정의합니다. 기술적 문제를 강조하고 팀 전체의 장애물을 해결하기 위해 합의합니다.
2일차
- 기획 프로세스를 팀원들에게 자세히 설명합니다. PI 종료 시 예상되는 결과에 대해 간략하게 설명합니다.
- 계획 중에 팀별 브레이크아웃 세션을 처음으로 진행합니다. 팀의 목표는 초안 계획을 세우고 장애물과 위험을 식별하는 것입니다.
- 브레이크아웃이 끝나면 각 팀은 만든 초안 계획을 다른 팀 앞에서 발표하고 검토해야 합니다.
- 다음 단계는 경영진이 계획을 검토하고 다음 단계의 문제 해결 계획에 대한 지침을 제공하는 것입니다. 과제, 위험 및 장애물을 기반으로 계획을 조정합니다.
3일차
- 전날 경영 회의에서 조정된 계획으로 하루를 시작합니다.
- 팀은 최종 계획을 개발하고 위험과 장애물을 개선합니다. 사업주는 팀 목표에 비즈니스 가치를 할당합니다.
- 다음으로 팀은 전체 청중 앞에서 최종 계획을 발표합니다.
- 나머지 프로그램 수준의 위험에 대해 논의하고, ROAM(Resolved, Owned, Accepted, Mitigated) 위험 정보를 적용합니다.
- 팀은 프로그램 증분 계획 결과에 대한 신뢰도에 투표합니다.
- 투표율이 너무 낮거나 전반적인 신뢰도가 여전히 낮은 경우 추가 계획을 수행합니다.
- PI 약속 후 RTE는 팀이 계획이 어떻게 진행되었는지 논의하고 다음 단계를 위해 개선할 점을 확인하기 위한 회고를 계획합니다. 리더십 팀은 최종 지침과 함께 앞으로의 계획에 대해 설명합니다.
PI 결과
PI 계획의 최종 결과는 다음 PI 기간 내에 스프린트별로 완료되도록 계획된 기능 목록입니다. 알려진 모든 종속성은 기능 진행을 해결하고 차단을 해제하는 방법에 대한 정확한 계획과 함께 정리됩니다.
팀은 목표와 범위를 약속합니다. 목록에 반드시 포함되지 않은 추가 목표가 있는 경우, 이를 확정되지 않은 목표로 처리합니다. 시간과 자원이 허용된다면 이러한 문제는 잠재적으로 해결될 수 있습니다.
팀은 프로그램의 모든 위험을 문서화하고 추적하며, 이를 해결하는 방법에 대한 정확한 계획을 세웁니다.
또한, 팀은 회고 회의에서 얻은 모든 회고 아이디어를 기록하고, 다음 PI 계획 세션을 위한 학습 교훈으로 활용합니다.
특히 팀과 관련하여 다음과 같은 구체적인 기대가 있습니다.
- 팀은 비즈니스 가치를 기반으로 목표를 달성하기 위해 최선을 다합니다.
- 팀은 로드맵 콘텐츠의 타당성을 더 잘 예측할 수 있도록 스프린트당 용량을 계산합니다.
- 또한 각 스프린트당 실제 부하도 고려합니다.
- 스토리는 제공된 용량에 따라 각 작업 흐름의 특정 스프린트로 옮겨집니다.
- 팀은 PI 계획 및 제공할 콘텐츠에 대한 신뢰도를 투표합니다.
결론
위에 제시된 모든 내용을 읽은 후에도 명확해 보이지 않을 수 있지만, 대규모 조직을 SAFe로 전환하는 것은 매우 어려운 작업이라고 말씀드릴 수 있습니다. 경우에 따라서는 미션 임파서블처럼 느껴질 수도 있습니다. 이러한 기본 원칙 중 일부를 적용하더라도 SAFe라고 부를 수 있는 상태로 전환하려면 많은 반복적인 과정을 거쳐야 합니다.
발전은 때때로 사라지지 않는 구식 계층적 원칙과 규칙을 깨는 과정이기도 합니다. 광범위한 PI 계획과 그 결과를 신뢰할 수 있다고 말할 수 있을까요? 작업 흐름 팀이 적절한 애자일 방법론으로 운영되지 않는다면 실제로 무슨 의미가 있을까요?
여기에는 하이브리드를 위한 자리가 없다고 말할 수 있습니다. 올바른 프로세스, 사람, 사고방식을 갖추거나, 방법론적인 측면 중 하나라도 충족하지 못하면 실패할 수 있습니다.
당연히 SAFe 구현을 고려하기 전에 이미 애자일 팀의 원칙과 작업 방식을 마스터했다는 사실을 확인해야 합니다. 리더십 관점뿐만 아니라 팀이 투표하고 솔직한 의견을 표현하도록 해야 합니다. 그 결과에 놀랄 수도 있습니다.
다음으로, 애자일 인증과 관련된 유용한 학습 자료를 확인해 보십시오.
이 글이 도움이 되었나요?
의견을 보내주셔서 감사합니다!