실무에서 Scrum 대비 SAFe의 Agile 팀 운영 특성

친구들 사이에 Burn Down Chart에 관한 첫 번째 글을 게시한 후, 댓글에서 가장 먼저 받은 질문은 "당신의 SAFe 경험에 대해 더 자세히 알고 싶다"였습니다. 그래서 이 글에서는 우리의 실무에서 Scrum 대비 SAFe 작업의 특성을 밝히려고 합니다. 저는 결코 최종 진리의 권위를 주장하지 않으며 동료들의 어떤 수정과 명확화도 환영합니다.

먼저 제 생각에 SAFe 작업을 SCRUM과 구별하는 가장 핵심적인 것을 요점별로 나열하겠습니다.

• Scrum의 Increment와 SAFe의 Program Increment
• ART - Agile Release Train
• 상호작용하는 팀 수
• PIPE
• SOS
• PO - 비즈니스 소유자가 아님
• RTE
• 학습을 위한 다섯 번째 스프린트
• System Demo

Scrum의 Increment와 SAFe의 Program Increment. 사실 용어는 다르지만 혼동하기 쉽습니다. 왜냐하면 우리 쪽에서는 아무도 Program Increment라는 용어를 사용하지 않고 모두 그냥 Increment라고 말하는데, 이는 이미 SCRUM에서 사용되는 다른 용어이기 때문입니다. 하지만 전반적으로 의미 측면에서는 제 생각에 충분히 유사합니다. SCRUM의 Increment는 본질적으로 현재 제품 + 완료 상태(DOD를 통과한 팀)의 스프린트 계획 스토리입니다. Program Increment는 트레인(Agile Release Train)이 증분 가치를 프로덕션에 전달하는 시간 간격입니다. 기간은 우리의 경우 개발에 2주씩 4개 스프린트와 학습에 1개 스프린트입니다.

Agile Release Train - 하나의 가치 창출 흐름을 함께 작업하는 팀들의 팀입니다. 우리는 이를 그냥 트레인이라고 부르지만 프레임워크상 올바른 명칭은 "Solution"입니다. 우리의 경우 이 규칙이 완전히 지켜지지는 않으며 팀들이 기술적 관점에서 서로 다른 제품을 함께 작업하는 경우가 많습니다. 대부분의 비즈니스 기능이 복합적으로 구현되어 여러 제품에 걸치기 때문입니다. 이는 기술적 측면입니다. 하지만 누군가는 모든 IT 시스템을 회사의 하나의 제품으로 생각하며, 어쩌면 그게 더 옳을 수도 있다고 확신합니다.

상호작용하는 팀 수 우리 SAFe에서는 상당히 많으며, 한 트레인에 총 최대 125명이 권장됩니다. 우리는 3개의 트레인이 있고 각각에서 이 규칙이 지켜지지는 않으며, 125명이 넘는 트레인도 있습니다. 제가 알기로 SCRUM은 다른 팀과 어떻게 상호작용하는지 설명하지 않지만, SAFe에는 이에 대한 매우 명확한 권장 사항이 있습니다. 제 생각에 이를 위한 가장 두드러진 아티팩트는 Program Board입니다.

여기에는 트레인 팀 간의 상호 관계가 표시되며, 이를 논의하며 우리의 주간 Scrum Of Scrums (SOS) 행사가 진행됩니다.

약 2.5개월마다(매 5개 스프린트마다) 다음 행사가 열립니다 PIPE - Programm Increment Planning Event. 모든 분산된 팀이 한 홀에 모여 2일 동안 다음 2.5개월의 작업을 계획하는 것입니다. 이 행사 과정에서 예를 들어 Program board와 같은 아티팩트가 생기며, 여기에는 각 트레인에 대한 팀 간의 모든 의존성이 표시됩니다. 위에서 이미 어떻게 보이는지 보여드렸습니다. 이 행사에서 각 팀의 스크럼 마스터의 임무는 최대한 많은 의존성 발굴을 퍼실리테이션하고, 그다음 가능하면 이를 제거하는 것입니다(예를 들어 구두로 역량을 팀에서 팀으로 전수하거나, 한 팀의 의존성을 다른 팀으로 가져와 팀이 아무에게도 의존하지 않고 자신의 기능을 자율적으로 구현할 수 있도록). 실무에서 우리는 이렇게 하고 있습니다. 먼저 기능을 User Story로 분해하고, User Story를 4개 스프린트에 나눕니다. 기능은 Program Board에 배치되고 다른 팀으로부터의 의존성이 있는 대로 표시됩니다. 행사 동안 이는 논의되고 조정됩니다.

SOS - Scrum Of Scrum. 이 행사는 각 트레인별로 매주 한 번 진행됩니다. 트레인의 모든 팀의 스크럼 마스터가 온라인으로 모여 트레인의 Program Board가 중계되고 특정 트레인 팀의 모든 의존성과 기능의 상태가 논의됩니다. 본질적으로 이 행사는 트레인 내 팀들의 중앙 집중식 동기화를 위해 필요합니다. 일종의 스탠드업이지만 매주 한 번이며 팀이 아니라 스크럼 마스터를 위한 것입니다.

PO (제품 책임자) - 비즈니스 소유자가 아닙니다. Product Manager가 있으며, 그는 해당 비즈니스 방향의 Bussiness Owner들과 작업하며 본질적으로 제품 책임자에게 기능을 배분합니다. 제품 책임자는 이미 팀 내에서 직접 작업합니다 - 기능을 User Story로 나누며(우리의 경우 팀과 함께) 항상 나누지는 않지만 우리는 이 방향으로 계속 발전하고 있습니다.

RTE (Release Train Engineer - 기관사. 스크럼 마스터들의 스크럼 마스터. 자신의 트레인의 SOS 이벤트를 진행한다. 기능 수준에서 Product Manager와 소통한다. PIPE를 퍼실리테이션한다.

학습을 위한 다섯 번째 스프린트 - 네, Scrum과 달리 여기서는 인크리먼트 마지막에 팀에게 학습을 위한 전체 스프린트가 배정됩니다. 우리는 보통 실무에서 이를 우선적으로 내부 교육(SAFe 관련 교육 포함) 참석에 사용하지만, 그것만은 아닙니다. 사설 과정과 밋업은 가능한 한 이 시간에 계획하려고 합니다. 또한 5번째 스프린트 동안 자신의 스택을 확장하여 팀 내 누군가의 역량을 커버할 수 있도록(필요 시 백업할 수 있도록) 하는 개발자들도 있습니다.

System Demo. PIPE의 결과로 각 팀은 인크리먼트에 대한 목표 목록을 가지며, 이 목표들 각각은 트레인의 Business Owner에 의해 10점 척도로 평가됩니다. 이를 Business Value라고 합니다. 이 목표들은 기본 목표와 확장 목표로 나뉩니다. 기본 목표는 팀이 달성에 어떤 위험도 보지 못하는 목표입니다. 확장 목표는 달성 위험이 있는 목표입니다. 모든 목표는 필수이며 작업량은 모든 목표에 맞춰 계획됩니다. System Demo에서 Business Owner는 인크리먼트에 대한 작업 결과를 승인합니다. 예를 들어, 팀에 10, 6, 8점의 기본 목표 3개와 10, 3점의 확장 목표 2개가 있었다고 합시다. Business Owner가 각각 다음과 같은 점수를 주었다고 가정해 봅시다: 8, 6, 4, 2, 0. 이제 목표 달성 비율을 계산할 수 있습니다: 100%는 기본 목표에 대한 초기 점수 합계로 계산되며, 우리의 경우 10+6+8=24입니다. 달성 점수는 확장 목표를 고려하여 계산됩니다 (즉, 팀은 24점 중 20점을 달성했습니다). 결과적으로 팀의 목표 달성 비율은 (20*100)/24 = 83.3%가 됩니다. 정상적인 결과는 80%에서 100% 달성으로 간주됩니다.

그 외의 모든 면에서 우리는 SCRUM으로 일합니다. 아니, 거의 모든 면에서 :) 우리 경험에 관해 말하자면, 제 관점에서 진화는 분명합니다. 1년 동안 팀들은 크게 성장했고 자기 조직화되었습니다. 일부 팀은 실제로 해체되었지만, 그 안에서도 일정한 진화가 보입니다. 성장할 여지도 아직 있습니다.

facebook 동료들의 코멘트

«제냐, 안녕! 글 써줘서 멋져, 잘하고 있어! 트레인에 대해 조금 고치자면 - 트레인은 제품이 아니라 가치 창출 흐름을 중심으로 구성됩니다. 그리고 우리 소매에서는 SAFe 관점에서 트레인이 아니라 Solution입니다. 단지 소통의 편의와 이해의 단순화를 위해 우리는 계속 이것을 트레인이라고 부릅니다)»

– 콘스탄틴 보로닌 (Ingosstrakh 프로젝트 오피스 대표)

«음, 그리고 누군가는 알아차릴 수도 있겠네요, SAFe 관점에서 목표 평가는 I&A에서 이루어지며 (SD는 그 일부로 포함되지만 평가와 직접적으로 연결되지는 않음) SD 자체는 매 스프린트마다(팀 데모 이후) 진행되어야 한다고요. 하지만 우리는 아직 거기서 멀리 떨어져 있으므로, 의식적으로 당신이 기사에 쓴 대로 모두 부르고 있습니다)»

– 콘스탄틴 보로닌 (Ingosstrakh 프로젝트 오피스 대표)

«제냐, 계속해 주세요, 정말 유용해요!»

– 알렉세이 이오노프 (SAFe 공인 트레이너)