대형 Agile을 위한 SAFe®의 역할 정리

Published in

민현기(Min, Hyun Gi)’s Blog

21 min readNov 9, 2022

소수의 Scrum Team들은 간단한 Scrum of Scrums 협업을 통해 Product 개발이 가능합니다. 하지만 비즈니스 규모가 커짐에 따라 여러 Agile team간의 정렬, 협업, 품질, 고객 중심의 빠르게 배포되는 제품을 만들고, 대규모 확장된 애자일(Scaled Agile) 조직을 위한 구조화된 접근 방식이 필요합니다. 따라서 전사적 대형 조직의 Product라면 SAFe®와 같은 Scaled Agile 방식으로 Business 및 IT간에 Align되며 개발/운영이 필요합니다.

확장형 애자일 프레임워크(Scaled Agile Framework®, SAFe®)는 대형 조직이 린(Lean), 스크럼(Scrum), Kanban, XP 등의 애자일 기법을 도입하여 고품질의 제품과 서비스를 더욱 신속히 개발하고 배포하는데 필요한 원리, 프로세스, practice를 포함합니다. 또한 SAFe®는 (Scrum)Team, Program, Portfolio 수준에서 여러 대규모 팀이 협업하는 복잡한 프로젝트에 적합합니다.

SAFe®의 중요 개념 및 역할을 정리해 보았습니다. SAFe® 관련 내용은 홈페이지(https://www.scaledagileframework.com/)에 지속적으로 업데이트되는 상세 내용을 보시는 것을 추천드립니다.

1. Scaled Agile Framework®(“SAFe”)

상세 내용은 SAFe 홈페이지(https://www.scaledagileframework.com/)를 참고하세요.

정의

엔터프라이즈 규모에서 더 나은 협업, 속도, 품질, 고객중심의 제품을 만드는 Agile practice를 구현하기 위한 프레임워크
개발팀, 사업팀, 전체 조직으로 여러 Agile team간의 정렬, 협업 및 배포를 촉진
비즈니스 규모가 커짐에 따라 SAFe는 애자일 확장을 위한 구조화된 접근 방식을 제공

출처 : https://scaledagileframework.com/posters/

2. SAFe®의 Agile Release Train(ART)

ART는 장기간 지속되는 Agile team으로서 이해관계자들과 함께 가치흐름에서 하나 혹은 여러 솔루션을 함께 점진적으로 개발, 배포, 운영하는 virtual한 Long term의 Agile Team이다.

2.1. 정의

Teams of Agile Teams
이해관계자들과 함께 가치흐름에서 하나 혹은 여러 솔루션을 함께 점진적으로 개발, 배포, 운영하는 virtual한 Long term의 Agile Team이다.
공통의 Program Backlog를 통해 공통의 Mission을 Align 시킨다.
(Feature level의 program backlog를 각 scrum team에서 story level의 backlog로 개발하므로 이들을 통합하는 virtual 조직 필요)
Agile 팀들의 공통 비즈니스와 기술 미션을 Cadence에 맞춰 조정하고, Program Increment(PI)를 동기화한다.

출처 : https://www.scaledagileframework.com/agile-release-train/

각 Virtual 조직(일반적으로 50~125명)은 계획, 커밋, 개발, 배포를 함께 수행
기업의 중요한 가치 흐름을 중심으로 구성되며, 최종 사용자에게 이익을 제공하는 솔루션을 구축함으로써 가치를 실현
Cross-Functional 하며, 소프트웨어, 하드웨어, 펌웨어 등을 정의/구현/테스트/배포/릴리스하고 솔루션을 적용/운영

2.2. Agile Release Train(ART)의 구성

상세 내용은 Team Topologies를 참고하세요.

스트림 정렬팀(Stream-aligned team)
- Stream이란 비즈니스 도메인이나 조직역량에 맞춘 업무의 지속적 흐름을 의미(고객의 흐름, 비즈니스 영역의 흐름, 제품의 흐름, 법규준수 흐름등 다양한 stream이 공존)
- Value의 흐름 중심으로 개발팀이 조직되고, 고객 또는 최종 사용자에게 직접 가치(Value)를 제공(개발)할 수 있는 능력의 팀
활성화팀(Enabling team)
- 전문 기능을 갖춘 다른팀(Stream-aligned team)의 부족한 역량 및 장애물 해결을 지원(실험, practice 제공)하고, 새로운 기술에 익숙해지도록 돕는 팀
- 예) Techical consulting team의 CI/CD, 테스트자동화, Infrastructure, Architecture 등을 담당
난해한 하위 시스템팀(Complicated subsystem team)
- 깊은 전문 지식과 기술이 필요한 시스템의 특정 하위 시스템의 일부를 구축하고 유지하는 팀
- 스트림 정렬팀의 인지 부하를 줄이는 것이 목표이며, 스트림 정렬팀보다 개발/전달 속도와 품질 향상을 기대
- 예) 비디오 코덱, 수학계산모델, 실시간거래 조정 알고리즘, 거래보고 시스템, 얼굴인식 엔진 등
플랫폼팀(Platform team)
- 다른 팀(스트림 정렬팀)이 원활하게 제품을 구현하고 지원할 수 있는 플랫폼의 개발 및 지원을 제공하는 팀
- 플랫폼팀의 주고객은 스트림 정렬팀
- 예) 하위 레벨 스택(프로비저닝, 모니터링, 배포, 테스트 환경, 네트워크 설정 등)의 세부지식을 담당하고 쉽게 사용할 수 있는 서비스를 제공

2.3. ART의 Cadence와 Synchronization

PI planning에 맞춰 ART의 각 (scrum) team의 개발 결과를 통합하고 demo 수행
각 team의 cadence가 일치되지 않는다면 통합이 안된다.

출처 : https://www.scaledagileframework.com/pi-planning/

2.4. Planning Interval (PI) Planning 회의

(SAFe 5.0에서는 Program Incremental(PI) Planning)
ART(Agile Release Train)의 심장 박동 역할을 하는 cadence 기반의 대면 이벤트로 ART의 모든 팀들간 공유된 mission과 vision에 Align되게 하는 이벤트입니다.
Scrum team에서는 Sprint Planning에 따라 scrum team의 결과물이 Product Increment로 생산된다면, SAFe®에서는 PI Planning에 따라 여러 scrum team(ART)에서 만든 product를 통합하기 위한 계획이 필요
- 예) scrum에서는 2주단위의 sprint 주기로 소스를 개발/통합/배포/데모한다면, SAFe®는 여러 Iteration/sprint 주기(PI 주기)안에서 통합/배포/데모한다.

PI Planning을 통해 Feature level인 Program의 mission이 각 (scrum) team에 Story Level로 일정 및 목적이 align된다.

3. Backlog 종류

EPIC → Feature → Story

Epic Owner → Product Management → Product Owner

출처 : https://www.scaledagileframework.com/portfolio-backlog/

출처 : https://www.scaledagileframework.com/safe-requirements-model/

3.1. EPIC

Portfolio 레벨이며 Epic Owner에 의해 관리된다.
Portfolio 레벨에서 안정적인 투자를 위한 중요한 Solution Development Initiative 단위입니다. (부연설명 : Solution 영역에서 Problem 영역을 Epic으로 분리)
큰 범위와 영향 때문에 구현하기 전에 Minimum Viable Product (MVP)의 정의와 Lean Portfolio Management (LPM)의 승인이 필요합니다.

출처 : https://www.scaledagileframework.com/epic/

3.2. Feature

ART(Program) 레벨이며 Product Management에 의해 관리된다.
Stakeholder의 요구를 충족시키는 서비스입니다.
각 Feature에는 Benefit Hypothesis 및 Acceptance Criteria을 포함한다.
Feature의 크기는 Program Increment (PI) 기간 동안에 할 수 있는 범위로 한다.(반면에 Story의 크기는 Sprint 기간안에 할 수 있는 범위 권고)

출처 : https://www.scaledagileframework.com/features-and-capabilities/

3.3. Story(User Story, Enabler Story)

Team 레벨이며 Product Owner에 의해 관리된다.
기능의 작은 부분으로 사용자 관점의 언어로 명세한 간략한 설명입니다.
Team 레벨에서 작성된다.
Story의 크기는 단일 Iteration(Sprint)기간내에 할 수 있는 범위로 한다.
- User Story는 사용자 및 Business 관점이며,
- Enabler Story는 기술탐색, 아키텍처, infrastructure, compliance를 포함하며, Portfolio, Solution, Program, Team Backlog 전반에 나올 수 있습니다.(부연 설명 : JIRA의 Task로 생각하셔도 될듯 합니다.)

출처 : https://www.scaledagileframework.com/story/

4. SAFe의 역할 정의

Product Management, Product Owner, Agile Team의 역할에 대해 소개한다.

출처 : https://www.scaledagileframework.com/product-owner/

4.1. Business Owner

정의 및 역할
- ART의 핵심 이해관계자이며 Business outcome에 대해 책임 및 권한
- ROI(투자 수익)에 대한 주요 비즈니스 및 기술 책임이 있는 소규모 이해관계자 그룹
- ART(Agile Release Train)에서 개발한 솔루션에 대한 거버넌스, 규정 준수
- 사용 적합성을 평가하고, ART 이벤트에 적극적으로 참여
- 팀 PI 목표에 비즈니스 가치를 할당하고 PI 계획을 승인
역할
- 전통적 관리자(Task를 할당하고 담당자를 관리감독)와 달리 Mission과 Vision을 제시하고 리딩
- 팀을 코칭하며 도움
- 조직과 팀의 성장, 운영의 우수성, Business outcome에 책임
- PI planning에 참석하고, Business context를 제공 및 Business value를 할당
- Inspect & Adapt(I&A) Workshop, System/Solution demo에 참석하여 Solution의 목적에 맞는지 Feedback

출처 : https://www.scaledagileframework.com/guardrails/

Business Owner는 다음 질문을 통해 식별할 수 있습니다.
- 비즈니스 결과에 대한 궁극적인 책임은 누구에게 있습니까?
- 누가 이 ART를 조정하여 올바른 솔루션을 개발할 수 있습니까?
- 현재와 가까운 미래에 솔루션의 기술적 역량에 대해 말할 수 있는 사람은 누구입니까?
- 누가 계획에 참여하고, 장애를 제거하고, 개발, 비즈니스 및 고객을 대신하여 발언해야 합니까?
- Program Increment(PI) 계획이 모든 사람을 만족시킬 수 없다는 것을 잘 알면서 누가 PI(프로그램 증분) 계획을 승인하고 방어할 수 있습니까?
- 기업 내 다른 부서 및 조직과의 협력을 누가 도울 수 있습니까?

4.2. Product Management/Manager

정의
- 비전, 로드맵 그리고 프로그램 백로그에 작성된 Feature들의 정의 등 ‘무엇을 만들어낼 것인가’를 담당
- 고객, PO와 함께 일하며 그들의 요구사항을 이해하고 전달/소통
- 솔루션(Scrum team의 통합 결과물)의 검증 역할
주요 역할
- 고객의 요구를 이해
- 통합 개발된 솔루션 검증
- 시스템 설계자/엔지니어링, RTE와 협력
- ART 비전 및 로드맵 작성 및 전달(소통)
- ART에 대한 작업 흐름 관리 및 우선 순위 지정
- PI Planning 준비 및 참여
- 데모 참여하여 Inspect & Adapt(검사 및 적응)
- 효과적인 Product Manager/Product Owner팀 구축
주요 책임
- 비즈니스 목표 달성(Meet business goals) : 제품 및 솔루션은 포트폴리오에서 설정한 경제적 비즈니스 목표를 충족한다.
- 구축(Get it built) : ART(Agile Release Trains) 및 Solution Train과 협력하여 필요한 기능을 구축한다.
- 제품을 시장에 제공(Get it off the shelf) : 내부적으로 제품 관리자는 IT와 협력하여 솔루션이 내부 고객 및 사용자에게 배포되도록 한다. 외부적으로 더 많은 비즈니스 이해 관계자와 협력하여 제품을 시장에 제공한다.
- 영향력 지원(Leverage support) : 제품 관리자는 제품이 지속적으로 가치 흐름을 생성하도록 지원되고 향상되도록 한다.

출처 : https://www.scaledagileframework.com/product-management/

4.3. Product Owner

정의
- 팀의 Feature나 Component의 개념적이고 기술적인 무결성을 유지하면서 프로그램 우선 순위의 실행을 자연스럽게하기 위해 Story를 정의
- 팀 백로그(Team Backlog)의 우선 순위를 정의하는 Agile Team의 구성원입니다.
주요 역할
- PI Planning을 준비하고 참여
- Team Backlog 관리
- Iteration Planning
- Story 정제
- 기능 수락 기준(Acceptance Criteria)를 위해 팀과 Behavior-Driven Development(BDD) 상세화 적용
- 팀과 함께 Acceptance Criteria 작업
- Enabler (기술 Story) 이해
- 팀의 Demo 및 Retrospective에 참석

4.4. Scrum Master / Team Coach

정의
- Agile team의 Servant leader이며 코치
- 자기 조직화 및 자기 관리에 대해 팀을 지도
- Scrum, 익스트림 프로그래밍(XP), 칸반 및 SAFe에서 팀을 교육하여 합의된 애자일 프로세스를 따르도록 유지
- 장애물을 제거하고 성과가 뛰어난 팀 dynamic, 지속적인 흐름 및 끊임없는 개선을 위한 환경을 조성
- ART 이벤트를 조정하고 도와 조직 전체의 효과성을 높임
- Scrum을 사용하지 않는 조직을 위해 Team Coach용어 추가(SAFe 6.0)
주요 역할
- PI Planning 퍼실리테이트 : PI Planning 준비, PI 목적 지원, Plan과 Biz value 리뷰)
- 이터레이션(Sprint) 실행 지원 : Scrum, XP 이벤트 지원, PO와의 협력
- 흐름(Flow) 개선 : 팀 Kanban 보드 생성, Flow를 측정하고 최적화, 품질내재화
- 고성과 팀 만들기 : 효과적으로 일하기, 협업 독려, 좋은 질문, 팀의 충돌 제거, 팀의 Skill 올리기
- 전체적인 Program 레벨의 성과 개선 : Stakeholder 신뢰 구축, PI 끝내기

출처 : https://scaledagileframework.com/scrum-master-team-coach/

4.5. Release Train Engineer(RTE)

정의
- ART의 ‘Chief Scrum Master’ 역할
- RTE는 프로그램 수준에서 Lean-Agile 가치 전달을 촉진하는 리더 역할
주요 역할
- ART를 통한 가치 흐름 관리 및 최적화
- 팀과 시스템 레벨의 이해관계자간의 협업 촉진
- Program Increment(PI) Planning 준비
- 이벤트 Facilitating
- 주요 ART 실행 측정 항목 추적 및 소통
- ART 장애의 에스컬레이션 및 추적
- ART에 대한 끊임없는 개선 촉진

(Backup) RTE vs. Scrum Master

Feature 및 Enabler가 소셜화(공유)되었는지 확인하면, 나중에 PI Planning 중에 많은 문제가 해결됩니다.

4.6. System Architect

정의
- 시스템의 전반적인 아키텍처를 정의하는 개인(또는 팀)
- 개발 중인 시스템 또는 솔루션이 의도한 목적에 적합하도록 하기 위해 ART(Agile Release Train)에 대해 공유된 기술 및 아키텍처 비전을 정의하고 전달할 책임
주요 역할
- 팀과 컴포넌트를 넘어 추상적인 레벨의 작업
- 주요 시스템 구성 요소 정의
- ART 팀과 협력하여 하위 시스템 및 해당 인터페이스 정의
- 솔루션 수준에서 중요한 NFR(비기능요구사항)을 설정
- Enabler 구현 정의, 탐색 및 지원
- Product Manager와 협력하여 Capability 할당 결정
- System Architect는 기술 관련 권한 보유
- 미션, 비전 및 로드맵을 달성하기 위한 공통 기술의 방향으로 팀을 정렬(Align)

4.7. System Team

정의
- 지속적 배포 파이프라인을 지원하는 Tool chain 개발 및 유지 관리를 포함하여
애자일 개발 환경을 구축하고 지원하는데 도움을 주는 전문화된 애자일 팀
주요 역할
- System(or Solution) Integration
- End-to-End Testing(Feature, 성능 등)
- System(or solution) Demo
- 릴리스(Release)

출처 : https://www.scaledagileframework.com/system-team/

솔루션 통합 및 테스트의 Balancing
- System team이 통합 문제에 대해 전체 문제를 해결할 수 없으므로Agile team도 함께 해야 생산성이 올라갑니다.
- 반대로 모ㄴ 성능 테스트 부담을 Agile team에 맡기면 생산성이 낮아집니다.
- 따라서 ART 속도를 최대화하려면 Agile Team과 System Team간의 균형을 유지해야합니다.

4.8. Shared Service Team

정의
- ART(Agile Release Train)의 성공에 필요한 전문 역할,인력,서비스를 대표하지만 전담을 못함
- 따라서, 필요할 때 필요한 공유 서비스의 직원을 참여시킬 계획 수립 필요
주요 역할
- Agile 및 software/systems engineering 코칭
- Application/web portal 관리
- 구성관리(Configuration management)
- Data modeling, data engineering, and database support
- Desktop support
- End-user training
- Enterprise architecture, Information architecture, Infrastructure 및 tools management
- Internationalization와 localization support
- IT Service Management (ITSM)와 deployment operations
- Security specialist(InfoSec), Regulatory and compliance
- System QA와 exploratory testing
- Technical writers