애자일 확장: 스크럼 마스터를 위한 SAFe 모범 사례

이 기사는 팀 확장 노력에서 프로젝트 관리자를 안내하기 위해 설계된 Toptal의 Agile 확장 시리즈의 2부입니다. 첫 번째 기사인 "5가지 Agile Scaling Frameworks 비교: 어떤 것을 사용해야 합니까?"를 읽으십시오. 가장 인기 있는 옵션에 대한 자세한 개요를 보려면

제품이 성장하고 복잡해짐에 따라 제품을 생산하는 팀도 복잡해집니다. 규모를 확장해야 할 때 많은 기업이 스크럼에서 SAFe(Scaled Agile Framework)로 전환합니다. 이 시스템은 기업 수준에서 구현되고 기업이 팀으로 구성된 팀이 개발해야 하는 여러 복잡한 제품을 관리할 수 있게 해줍니다.

SAFe 프레임워크로 이동하는 스크럼 마스터는 친숙하면서도 새로운 환경으로 발을 들일 것입니다. 유물, 역할 및 의식은 스크럼을 기반으로 합니다. 그러나 더 큰 규모로 운영하려면 공통 궤적인 릴리스 트레인 엔지니어(RTE)의 역할로 이동하기로 선택한 스크럼 마스터에게 특히 몇 가지 추가 책임이 따릅니다. RTE는 전체 릴리스 트레인의 스크럼 마스터 역할을 합니다. 9명에서 11명으로 구성된 스크럼 팀을 이끄는 대신 RTE는 여러 부서에 걸쳐 있는 팀 팀의 서번트 리더가 되어 더 큰 규모와 범위의 이벤트를 조직합니다.

기본 사항: 스크럼에서 SAFe로

SAFe를 통해 회사는 여러 팀에 Agile 접근 방식, 가치 및 원칙을 적용할 수 있습니다. 결과 "팀의 팀"은 애자일 릴리스 트레인(ART)으로 알려져 있습니다. 개별 팀은 평소와 같이 업무를 수행하기 위해 스크럼 마스터를 계속 고용하는 반면, ART에서 스크럼 마스터와 같은 역할은 RTE가 수행합니다. RTE는 스크럼의 일반적인 메커니즘과 거버넌스를 적용하지만 팀 수준이 아닌 조직 수준에서 적용합니다. 다른 기존의 팀 수준 스크럼 역할과 아티팩트도 그에 따라 변경됩니다. 예를 들어, ART "제품 소유자"는 제품 관리자가 됩니다. "제품 백로그"는 프로그램 백로그가 됩니다. "스프린트 백로그"는 반복 백로그입니다. "제품 증분"은 이제 프로그램 증분(PI)입니다.

SAFe에는 4가지 구성(Essential, Large Solution, Portfolio 및 Full)이 있으며 사용하는 구성은 회사가 프레임워크를 얼마나 광범위하게 채택하는지에 따라 다릅니다. 구성을 통해 여러 팀이 함께 작업하는 것부터 전체 포트폴리오 통합 및 전사적 비즈니스 민첩성에 이르기까지 다양한 수준에서 구현할 수 있습니다. 그러나 모든 수준에서 목표는 Agile 및 Scrum 관행을 대체하는 것이 아니라 확장하는 것입니다.

SAFe의 스크럼 마스터

팀 수준에서 SAFe 프레임워크에서 일하는 스크럼 마스터는 자신의 업무가 크게 다르지 않다는 것을 알게 될 것입니다. 그들은 애자일 팀의 서번트 리더로 남아 코칭과 교육, 장애물 제거, 팀 구성원이 최선을 다하고 지속적으로 개선할 수 있는 환경 조성을 책임집니다.

그러나 몇 가지 새로운 책임이 있습니다. SAFe Scrum 마스터는 PI 계획 이벤트 및 프로그램 실행에서 RTE를 지원하고 ART 동기화 회의에서 팀을 대표합니다. 팀이 제거할 수 없는 장애물이 있는 경우 스크럼 마스터는 이를 RTE로 에스컬레이션합니다.

RTE가 되기로 결정한 스크럼 마스터는 자신의 역할에 결정적으로 더 많은 고려가 필요하다는 것을 알게 될 것입니다. ART에는 비즈니스 분석, 하드웨어 또는 규정 준수와 같이 귀하에게 처음이거나 Agile을 처음 접하는 팀이 포함될 수 있습니다. 그리고 SAFe의 상위 구성에는 프로그램 또는 포트폴리오 운영이 포함되기 때문에 경영진은 스크럼에 포함되지 않은 방식으로 직접적이고 정기적으로 참여하여 모든 것이 엔터프라이즈 및/또는 포트폴리오 수준 목표와 일치하는지 확인합니다.

RTE는 단일 팀의 능력을 넘어서는 장애물을 제거하는 책임이 있습니다. 그들은 이해 관계자와 의사 소통하고 ART 수준에서 지속적인 개선을 주도합니다. RTE는 팀뿐만 아니라 해당 팀의 리더를 코칭하여 ART의 모든 수준이 자기 조직화 및 자기 관리로 나아갈 수 있도록 돕습니다.

SAFe 이벤트

스크럼 마스터가 팀 수준 이벤트를 용이하게 하는 것처럼 RTE는 PI 계획, ART 동기화, 시스템 데모, 검사 및 적응과 같은 ART 수준 이벤트를 용이하게 합니다. RTE는 스크럼 마스터였을 때보다 더 다양한 이해 관계자와 교류하고 이해 관계가 상충되는 여러 팀을 처리하게 됩니다. 모든 이벤트에는 점점 더 다양한 참석자가 있으며 우선 순위를 조정하고 이니셔티브에 대한 동의를 미리 얻어야 합니다.

PI 계획

PI 계획 이벤트는 PI 계획을 작성하여 향후 8주에서 12주 동안 ART 내 모든 팀의 목표를 조정하기 위한 거대한 2일 세션인 SAFe의 필수 행사입니다. 스프린트 계획 이벤트와 비슷하지만 여러 팀의 여러 스프린트에 걸쳐 있습니다.

입력

• 비즈니스 비전
• 구현할 상위 10~15개 기능 목록
• 각 팀의 능력에 대한 세부 사항

출력

• PI 계획(다음 5~6개의 스프린트에 대한 전달 계획)
• PI 목표
• 잠재적 위험 목록

PI 계획 이벤트에 대한 일반 팁

• 이해 관계자의 동의를 얻습니다. 회의에 앞서 RTE는 주요 이해 관계자가 누구인지 확인하고 그룹과 의견을 공유해야 합니다.
• 우선 순위를 조정합니다. 세션 전에 제품 관리 팀과 하루 종일 회의를 예약하여 제공해야 하는 기능과 향후 우선 순위에 대한 상위 수준 보기에 동의합니다. 위험 및 종속성과 같이 이벤트에서 해결해야 할 사항이 많으며 기본적인 방향 합의가 있는 것이 좋습니다.
• 리허설! PI 계획은 거대한 이벤트입니다. 이틀 종일 리허설을 하는 것은 유용하지 않을 수 있지만 ART의 팀 리더와 가능한 한 가까운 경험을 만드는 2~4시간 세션은 큰 도움이 될 것입니다. 이벤트 의제의 단순화된 버전을 만들고 리허설 전에 공유하여 잘 알려진 곳에서 연습을 시작할 수 있습니다.
• 미션 크립에 대비하십시오. PI 계획의 목표는 비교적 짧은 기간에 장기 계획을 달성하는 것입니다. 때때로 사람들은 이벤트의 목적이 아닌 모든 것에 대해 광범위한 세부 사항에 들어가기를 원할 것입니다. 리허설과 세션에서 팀 리더에게 이것을 설명하십시오. 목표는 다음 3개월 동안 매 순간 계획하는 것이 아니라 상위 수준의 계획을 제공하고 조정을 만드는 것임을 팀에 상기시킵니다.
• 팀 역량 정보를 준비합니다. 스크럼 마스터에게 향후 8주에서 12주 동안의 용량 계산을 제공하도록 요청하십시오. 약간의 반발이나 질문을 예상하십시오. 예를 들어, 스크럼 마스터는 팀이 앞으로 두 달 동안 얼마나 많은 결석을 하게 될지 정확히 알지 못할 수 있습니다. 이러한 경우 견적을 요청하고 PI 자체에서 용량 제한에 유연하게 대응할 수 있습니다.
• PI 계획 의제를 공유합니다. 일정을 행사 최소 2주 전에 배포하고 많은 질문에 답할 준비를 하십시오. 많은 참석자가 있을 것이며 SAFe가 귀하와 귀하의 회사에 새로운 것이라면 다른 많은 팀원들에게도 새로운 것일 것입니다. 내 경험상 두 번째 또는 세 번째 PI 계획 이벤트가 진행되면 팀이 이벤트에 익숙해지고 무엇을 기대해야 하는지 알게 되면서 진행자에 대한 압력이 훨씬 덜하게 됩니다.
• 관리 출석을 확보합니다. 관리자나 고위 관리자가 이틀 간의 행사에 참석하기 어려운 경우가 많지만 상위 수준의 조정을 위해서는 경영진 참석이 필수입니다. 최소 PI 계획 2주 전에 참석 여부를 확인하고 필요한 지원을 준비하십시오. PI 목표를 승인해야 하는 비즈니스 소유자에게도 동일하게 적용됩니다.

아트 싱크

ART 동기화 이벤트는 RTE가 팀의 진행 상황에 대한 통찰력을 얻고 프로그램 위험 및 장애물을 식별할 수 있는 주간 회의입니다. RTE가 장애를 평가하고 에스컬레이션이 필요한지 여부를 결정할 수 있는 유일한 기회는 결코 아니지만 이러한 문제를 제기할 수 있는 정기적인 장소를 제공하는 중요한 이벤트입니다.

입력

• 팀의 진행 상황
• 장애물 로그
• PI 계획(계획과 실제 진행 사이의 주요 편차를 식별하기 위해)

출력

• 에스컬레이션(필요한 경우)
• PI 계획 변경에 대한 결정

ART Sync 이벤트에 대한 일반 팁

• 정기적인 의사소통을 장려하십시오. ART Sync는 Scrum 스탠드업과 같이 매일이 아니라 매주이기 때문에 RTE는 팀이 긴급한 문제를 즉시 제기할 수 있고 다음 ART 동기화를 기다리지 않아야 함을 분명히 해야 합니다.
• 데이터로 준비하십시오. 진행 상황에 대한 정보에 입각한 대화를 나누기 위해 스크럼 마스터와 제품 소유자에게 번다운(burndown) 또는 누적 흐름과 같은 정량화 가능한 진행 메트릭을 가져오도록 요청하십시오.
• 주간 상태 검토를 넘어서십시오. ART sync는 단순한 체크인이 아닌 우선순위를 맞추고 문제를 해결하는 이벤트를 의미합니다.

시스템 데모

시스템 데모는 이전 반복 중에 생성된 전체 작업 범위를 보여주기 위한 것입니다. 이 행사에서 제품 관리자와 그들의 팀은 현재의 형태로 ART의 통합 진행 상황을 비즈니스 소유자 및 기타 이해 관계자에게 보여줍니다.

입력

• 이전 반복 과정에서 모든 Agile 팀 구성원의 출력을 기반으로 한 현재 작업 상태

출력

• 시스템의 목적 적합성에 대한 피드백
• 백로그 변경(필요한 경우)

시스템 데모 이벤트에 대한 일반 팁

• 리허설! 격주로 30~45분을 발표자와 함께 작업하여 세그먼트를 정리합니다.
• 슬라이드를 버리십시오. 실제 통합 작업을 제시합니다. 소프트웨어 제품에서 작업하는 경우 발표자가 이해 관계자에게 슬라이드 데크가 아닌 작업 제품 증분을 보여주도록 하십시오. 가능하면 스테이징 환경에서 제품을 시연하십시오. 데모가 최종 사용자 경험과 정확히 유사하기를 원합니다. 2주마다 통합 시스템을 제공할 수 없는 경우 제공 파이프라인을 살펴보고 CI/CD 및 DevOps 문화를 채택할 수 있는 방법에 대해 팀과 함께 브레인스토밍하십시오.
• 비즈니스 가치에 중점을 둡니다. 귀하의 프레젠테이션은 비즈니스 소유자 및 이해 관계자를 위한 것입니다. 그들에게 가장 중요한 것을 공유하십시오.
• 피드백에 집중하세요. 여러분이 받는 이해관계자 피드백이 중요하겠지만, 이번 행사는 제품 비전이나 로드맵을 대폭 변경할 때가 아닙니다. 팀이 나중에 작업 항목으로 전환할 수 있도록 대화를 상위 수준의 피드백으로 되돌릴 준비를 하십시오.
• 짧게 유지하세요. 이해 관계자는 바쁜 사람들입니다. 45분에서 60분의 회의는 더 자주 참여하고 참여하게 합니다.
• Q&A 시간을 허용합니다. 답변에 투명하게 하십시오. 때때로 "모르겠지만 알아낼 수 있다"가 가장 좋은 대답이라는 것을 기억하십시오.

검사 및 적응

검사 및 적응은 PI가 끝날 때 발생하는 대규모 회고 세션입니다. 세션은 세 부분으로 나누어져 있으며,

• PI 시스템 데모: 전체 PI의 통합 출력을 위한 쇼케이스. 메인 시스템 데모와 비슷하지만 한 번의 반복이 아닌 이 이벤트는 전체 PI에 대한 통합 작업을 보여줍니다.
• 정량적 및 정성적 측정: RTE가 PI 과정에서 수집된 메트릭을 제시할 수 있는 기회. 이러한 메트릭에는 팀 속도, 수용된 사용자 스토리, 단위 테스트 적용 범위 또는 미결 결함이 포함되지만 이에 국한되지 않습니다.
• 회고 및 문제 해결 워크숍: 참가자들이 PI를 되돌아보고, 무엇이 효과가 있었는지, 무엇이 효과가 없었는지 성찰하고, 체계적인 문제를 식별하고, 해결 방법을 제안하는 기회.

입력

• 팀의 진행 상황
• 모든 프로그램 증분 출력을 포함한 ART 통합 작업의 현재 상태

산출

• 잠재적인 개선 사항 목록

Inspect 및 Adapt 이벤트에 대한 일반 팁

• 사업주에게 사전 통지하십시오. 행사 최소 2주 전에 통지하십시오. 세션 전에 참석하는 제품 관리자 및 비즈니스 소유자와 만나 정성적 결과 프레젠테이션을 조정합니다.
• 고위 이해 관계자의 참석을 확보합니다. 팀의 작업과 진화하는 제품을 선보일 때 PI 시스템 데모에서 이들의 존재가 가장 중요합니다. 일반 시스템 데모에 대한 많은 지침이 여기에 적용됩니다. 미리 연습하고, 프레젠테이션 슬라이드를 피하고, 실제 결과물을 보여줍니다.
• 비난을 피하십시오. 세션을 진행하는 동안 회고록에서 확인된 문제나 제시된 데이터로 인해 아무도 위협을 느끼지 않도록 하십시오. 어떤 팀은 다른 팀의 숫자가 더 높으면 질투나 방어를 느끼거나 문제가 팀에서 비롯된 경우 소외감을 느낄 수 있습니다. 이러한 문제를 사전에 예방하기 위해 전체 팀 문화를 수용하십시오.
• 체계적인 문제에 중점을 둡니다. 산발적인 문제에 너무 많은 관심을 기울이지 않도록 하고, 팀에 브레인스토밍에 필요한 공간을 제공하고, 제안된 솔루션에 대해 자유롭게 상상할 수 있도록 하십시오.
• 실행 가능한 제안을 만듭니다. 이벤트가 끝나면 팀에서 구현할 백로그 항목이 있어야 합니다. 문제를 식별하는 것은 문제를 해결하기 위한 조치를 취하지 않으면 도움이 되지 않습니다.

아래 표는 SAFe 이벤트를 스크럼 이벤트와 비교하고 기업 수준에서 행사의 빈도와 실행을 설명합니다.

강화 및 확장

Scrum에서 SAFe로의 전환은 위협적일 수 있습니다. 더 높은 규모로 운영하는 것은 가장 친숙한 관행에 대해서도 항상 새로운 도전과 새로운 사고 방식을 제시합니다. RTE가 되기로 선택하면 직업이 이미 보유한 기술에 가장 많이 의존한다는 것을 알게 될 것입니다. RTE는 스크럼 마스터와 마찬가지로 변화 에이전트이자 서번트 리더이며, 이 직무는 기업 수준에서 이 역할을 수행하여 제품과 함께 기술을 향상시킬 수 있는 기회를 제공합니다.