Advanced Agile Project Management - ⑥

Advanced Agile Project Management - ⑥

최근 베스트셀러 “The Project Manager’s Guide to Mastering Agile”의 저자인 Chuck Cobb의 강의 중에서 Advanced Agile Project Management 전문가 과정을 듣고 일부 내용들을 간략히 정리하여 연재해 봅니다.

이번 글은 Scaling Scrum 관련하여 Jeff Sutherland에 의해 만들어진 Scrum@Scale 접근방식의 주요 내용을 소개하고, 또한 Dean Leffingwell에 의해 만들어진 Scaled Agile Framework (SAFe) 의 Portfolio Level, Program Level, Team Level의 3가지 Level별 주요내용을 살펴보겠습니다.

Scaling the Scrum-of-Scrums

Scaling Scrum 관련하여 가장 최신 접근방식 중 하나인 Scrum@Scale 접근방식에서 소개된 일부 내용을 살펴보겠습니다.

위 그림의 예는 Scrum팀이 많은 경우 조직을 어떻게 구성할 지를 보여줍니다.

• 단일 Scrum-of-Scrums는 일반적으로 약 5개 팀으로 제한함
• 더 많은 팀이 Scrum-of-Scrums 접근 방식을 필요로 할 것

위 그림에서 알 수 있듯이, 모델은 팀의 수가 증가함에 따라 빠르게 복잡해질 수 있습니다.

Executive Action Team (EAT)

Scrum@Scale 프로세스의 중요한 요소는 조직 내에서 Scrum의 Quality 전반적인 책임을 지는 리더십 팀인 Executive Action Team(EAT) 입니다. EAT의 역할은 달성하고 실행해야 하는 Agile initiative의 우선순위 목록인 조직 혁신 백로그를 만드는 것입니다. Executive Action Team(EAT)이 전반적인 활동을 성공적으로 수행할 수 있도록 권한을 부여하고 자금을 지원해야 합니다.

Executive Action Team (EAT) Responsibilities

Executive Action Team(EAT)의 책임을 살펴보면,

• Agile Ecosystem 소유, Scrum 가치 구현, Scrum 역할 생성 및 지원 보장
• 민첩하지 못한 조직의 모든 부분과 효과적으로 통합되는 자체 지침 및 절차로 운영
• SoS에서 제거할 수 없는 장애물에 대한 최종 정지
• 스크럼 팀과 마찬가지로 PO와 SM이 필요하며 매일 만나야 합니다. 그들은 또한 투명한 backlog를 가지고 있어야 합니다.
  
  

Coordinating the “What” – The Product Owner Cycle

이 프로세스에서 “What”를 담당하는 Product Owner팀 프로세스의 개요를 보여줍니다. Product Owner그룹은 팀의 네트워크를 공급하는 공유 백로그를 조정하고, SoS에 대해 각 팀의 우선 순위를 조정합니다.

이 프로세스에서 주된 역할은 Chief Product Owner (CPO) 와 각 팀 또는 팀 그룹을 대표하는 제품 소유자입니다.

이 프로세스의 주요 이벤트는 백로그 정제의 scaled version 인 MetaScrum 입니다.

Product Owner Team Responsibilities

제품 소유자 팀은 다음과 같은 주요 책임이 있습니다.

• 제품에 대한 중요한 비전을 수립하고 이를 조직에 알리십시오.
• 주요 이해 관계자들과의 조정 구축을 통해 백로그 구현 지원 확보
• 우선순위가 지정된 단일 백로그 생성, 중복 작업 방지
• 모든 팀에 적용되는 “완료 정의” 작성
• 팀에서 제기한 의존성 제거
• 조정된 로드맵 및 릴리스 계획 생성
• 제품과 시장에 대한 insight 를 제공하는 측정 기준 결정 및 모니터링
  
  

Scaling the Product Owner Team

제품 소유자 팀은 Scrum-of-Scrums와 같이 매우 유사하게 Scale을 조정 할 수 있습니다. 일반 제품 소유자 팀은 대략 5개팀의 제품 소유자로 제한되며, 그 이상으로 제품 소유자 팀의 구성이 필요합니다.

Executive Meta Scrum

전체 애자일 조직을 위한 제품 소유자 팀은 Executive MetaScrum 으로서 주요 이해 관계자들을 만납니다. Executive MetaScrum는 조직 비전을 소유하며 전략적 우선순위를 설정하여 모든 팀을 공통의 목표에 맞춰 조정합니다. 모든 조직에 강제적으로 맞추기보다는 조직의 성격에 맞게 모델을 맞추는 것에 주의해야 합니다.

Enterprise-level Agile Framework

Enterprise-level Agile Framework의 목적은 조직의 상위 수준을 애자일 개발 프로세스에 맞추는 것입니다. 그것은 풀기 어려운 문제가 될 수 있고 아무런 지침 없이 처음부터 시작하는 것은 매우 어려울 수 있습니다. 그러나 Enterprise-level Agile Framework를 “cookbook” 솔루션으로 간주해서는 안 된다는 점을 이해하는 것이 중요합니다. 어느 정도의 Skill과 Intelligence를 응용할 필요가 있으며 조직의 사업 방향에 잘 부합되어야 합니다.

• Dean Leffingwell에 의해 개발된 Scaled Agile 프레임워크은 프로젝트 포트폴리오 관리 계층을 포함하여 상단에서 하단으로 상당히 완전한 애자일 접근방식입니다. 이 접근 방식의 장점은 훨씬 더 민첩하고 보다 완벽한 구현이 가능하다는 것입니다. 단점은 기업이 떠맡을 준비가 되어 있지 않을 수 있는 애자일로의 전체적인 Transformation 변환이 훨씬 더 중요하기 때문에 구현이 훨씬 더 어려울 수 있다는 점입니다.
  

• 여러 가지 이유로, 기업은 애자일의 완전한 상단에서 상단으로 구현하는 것을 원하지 않을 수 있습니다. 그들은 애자일 구현을 팀 레벨로 제한하고 일부 상위 레벨에 대해 보다 계획적인 접근 방식 또는 하이브리드 접근 방식을 계속 사용할 수 있습니다.
  

• Scott Ambler가 개발한 Disciplined Agile Delivery 프레임워크은 스크럼을 기반으로 한 표준 애자일 개발 프로세스를 중심으로 구축되지만, 프로젝트 시작을 위한 스크럼 프로세스에 front-end를 추가하고 production transition 프로세스에 back-end를 추가해야 할 필요성을 인식하고 있습니다. 체계화된 애자일 프레임워크의 새로운 개정은 개발 팀과 다른 IT 기능, 특히 IT 운영 간에 훨씬 더 긴밀한 통합의 필요성을 인식했습니다. 훈련된 Agile Delivery 프레임워크의 원래 구현은 프로젝트 레벨 솔루션으로 제한되었지만, 최근 몇 년 동안 프로젝트와 프로그램 레벨 이상의 통합 수준을 제공하기 위해 새로운 변화가 도입되었습니다.
  
  

Scaled Agile Framework (SAFe) (Dean Leffingwell)

Dean Leffingwell에 의해 만들어진 Scaled Agile Framework 프레임워크을 살펴보겠습니다. 보시다시피, 이것은 훨씬 더 포괄적인 모델이며 구현하기 위해서는 일반적으로 훨씬 더 유의한 수준의 Transformation 이 필요할 것입니다.

Scaled Agile Framework (SAFe)는 다음과 같은 세 가지 주요 레벨로 구성됩니다.

• Portfolio Layer – 회사의 비즈니스 전략 및 투자 의도에 맞춰 프로그램을 조정하는 확장된 애자일 프레임워크에서 가장 높고 전략적인 계층입니다.
  

• Program Layer – 기업 및 이해관계자의 요구에 부응하기 위해 더 큰 가치를 창출하기 위해 크고 복잡한 enterprise-level 개발 활동에 참여하는 여러 팀의 활동을 조정하고 통합할 필요성을 인식합니다.
  

• Team Layer – 확장된 애자일 프레임워크의 기초를 형성하며, 각 주요 비즈니스 영역에 대한 개발 요구사항을 충족하기 위해 기본 설계, 구축 테스트 활동을 수행하는 곳입니다.
  
  

Scaled Agile Framework (SAFe) Variations

Scaled Agile Framework 은 최근 몇 년간 3가지 다른 변형으로 발전했습니다. SAFe의 최초 및 Original Variation은 Portfolio SAFe입니다. 이것은 포트폴리오 전략 및 투자 자금, 신속한 변화를 위한 포트폴리오 운영 및 린 거버넌스를 제공합니다.

다음 Variation “ Essential SAFe” 입니다. 이것은 프레임워크의 가장 기본적인 구성이며 SAFe로 공하는 데 필요한 최소 요소를 제공합니다. 이것은 본질적으로 포트폴리오 수준을 없애고 프로그램 수준까지만 올라갑니다.

세 번째 Variation은 “Large Solution SAFe “입니다. 이것은 포트폴리오 수준의 구성이 필요 없는 크고 복잡한 솔루션을 구축하고 있는 기업을 위한 솔루션입니다.

SAFe의 최종 Variation을 “Full SAFe”라고 합니다. 이것은 가장 포괄적인 구성을 나타냅니다. 일반적으로 수백 명 이상이 개발 및 유지보수를 필요로 하는 대규모 통합 솔루션 구축을 지원합니다. Large Solution SAFe와 Portfolio SAFe의 계층을 기본적으로 결합합니다.

Scaled Agile Framework – Team Level

팀 레벨은 Scaled Agile Framework 의 기초가 되며, 이는 전적으로 Scrum에 기초합니다. 그러나 SAFe의 팀 레벨은 일반적인 Scrum이 다루지 않는 여러 팀이 필요한 Scrum 프로젝트를 위해 제공됩니다.

중요한 점은 팀 레벨에서 SAFe는 Scrum에 기초한 표준 애자일 원칙과 관행을 사용한다는 것입니다. 그러나 SAFe는 Enterprise-level 에서의 애자일 개발 접근 방식은 훨씬 더 복잡할 수 있습니다.

SAFe의 가장 큰 문제는 일부 조직이 이를 “Cookbook” 솔루션으로 그대로 적용하려 했다는 점입니다. 비즈니스에 맞는 프레임워크의 커스텀 적용은 매우 중요합니다.

SAFe의 팀 수준에서, 팀은 cross-functional 하며, 팀당 5-10명으로 구성됩니다.

각 팀은 제품 소유자와 Scrum Master의 일반적인 Scrum 역할을 가지고 있지만, 이러한 역할은 단일 팀에만 국한되지 않고 프로젝트의 규모와 복잡성에 따라 여러 팀 간에 공유될 수 있습니다.

여러 팀에 걸친 노력은 Agile Release Train 이라는 계획 개념에 의해 동기화되며, 통합은 프로그램 레벨에서 언급하도록 하겠습니다.

Agile Release Trains

SAFe의 핵심 계획 개념은 “Agile Release Trains”의 개념입니다.

Agile Release Train(ART)은 애자일 팀의 long-lived 팀으로, 다른 이해관계자와 함께 PI(Program Increment) 타임박스 내에서 일련의 고정 길이 반복을 사용하여 점진적으로 솔루션을 개발하고 제공합니다. ART는 팀을 공통 비즈니스 및 기술 미션에 맞춰 조정합니다.

Agile Release Train 은 솔루션이 충족해야 하는 몇 가지 상위 수준의 목표에 팀을 집중시키는 방법입니다. ART의 두 가지 주요 패턴은 기능을 중심으로 구성하거나 서브시스템을 중심으로 구성되는 것입니다. 예를 들어, Train은 “고객 등록” end-to-end 기능과 같은 기능적 기능 또는 모바일 애플리케이션과 같은 하위 시스템 주위에 구성될 수 있습니다.

Agile Release Train 구성 방법을 살펴보면,

• 대규모 조직에서는 여러 개의 Agile Release Train이 있을 수 있으며 각 Agile Release Train은 Release Train에 참여하는 모든 팀을 통합하는 공통 비즈니스 및 기술 미션으로 시작되며, 애플리케이션 Release Train의 목표를 보다 구체적으로 정의하는 프로그램 비전과 프로그램 백로그가 있습니다.
  

• 각 Agile Release Train 은 일반적으로 8-12주 길이의 프로그램 증분으로 구성됩니다. 각 프로그램 증가는 대형 스프린트와 같으며, 일반적으로 2주 길이의 개별 스프린트로 더 세분화됩니다.
  

• 각 프로그램 증분 시작 시, 상위 레벨의 스프린트 계획 세션과 유사한 프로그램 증분 계획 세션이 있으며, 이 세션에서는 모든 팀이 참여하여 해당 프로그램 증분에서 수행할 작업을 계획합니다.
  

Agile Release Train 관련 보다 중요한 역할 몇 가지를 살펴보면,

Release Train Engineer

“프로그램 수준 실행, 장애 제거, 위험 및 의존성 관리, 지속적인 개선을 촉진하는 직원 리더” 입니다. Release Train Engineer는 프로그램 증분 계획 세션을 용이하게 합니다.

Product Manager

“프로그램 백로그의 비전, 로드맵 및 새로운 기능에 의해 정의된 ‘ what gets built ‘을 책임집니다. 고객 및 제품 소유자와 협력하여 고객의 요구 사항을 이해하고 전달하며 솔루션 검증에도 참여”

System Architect/Engineer

시스템의 전체 아키텍처를 정의하는 개인 또는 팀입니다. 그들은 팀과 구성 요소 위에 추상화 수준에서 일하고 비기능 요구사항(NFR), 주요 시스템 요소, 하위 시스템 및 인터페이스를 정의합니다. Business Owner는 ART의 주요 이해 당사자로 Train Business 결과에 대한 궁극적인 책임을 지며, 고객은 솔루션의 최종 구매자입니다.

Scaled Agile Framework – Team Level

팀 수준에서 일반적으로 수행해야 하는 몇 가지 Adaptation을 살펴보면,

팀 간의 개발 활동을 가장 잘 세분화하고 조직하는 방법에 대한 의사결정이 필요합니다. 가능한 대안은 Feature 팀, 컴포넌트 팀 또는 둘 모두의 조합입니다.

이러한 결정이 이루어지면, 전체 프로그램의 범위와 복잡성에 따라, 모든 팀의 활동이 잘 조정되고 동기화되도록 팀 간 커뮤니케이션과 상호의존성을 관리할 필요가 있을 것입니다.

역할도 더 복잡해질 수 있습니다. 예를 들어, Scaled Agile Framework 는 프로그램에 제품 관리자와 제품 소유자가 모두 포함될 수 있음을 인식하고 이러한 역할을 구분합니다.

Scaled Agile Framework Program Level

프로그램 레벨은 SAFe에서 매우 중요한 레벨로, 모든 팀이 제대로 통합된 프로그램 레벨 솔루션을 개발하기 위해 올바른 방향으로 나아갈 수 있는 “Glue”를 제공합니다.

Different Kinds of Programs

SAFe 프로그램 수준을 이해하기 위해 두 가지 다른 종류의 프로그램을 살펴보면,

첫 번째 유형은 정말로 프로젝트의 모음입니다. 그것은 각 프로젝트마다 요구사항이 잘 정의된 전체 목표를 달성하도록 설계된 통합 프로젝트 집합으로 구성됩니다.

두 번째 유형은 비즈니스 프로그램이다. 전반적인 비즈니스 목표를 달성하기 위한 광범위한 이니셔티브 – 활동의 정의는 훨씬 더 역동적이고 유동적이며 잘 정의된 프로젝트로 구성되지 않을 수 있습니다.

SAFe Program Level은 광범위하게 정의될 수 있는 비즈니스 목표 달성을 목표로 하는 매우 동적인 이니셔티브인 두 번째 종류에 해당됩니다.

프로그램과 프로젝트의 차이는 일반적으로 일부 비즈니스 목표에 의해 정의된 광범위한 지향점을 가진 프로그램인 반면, 프로젝트는 일반적으로 일부 특정 프로젝트 산출물에 의해 정의된 보다 명확한 지향점을 가지고 있습니다.

Scaled Agile Framework – Program Layer

SAFe는 프로그램 수준에서 전통적인 프로젝트 관리 구조 대신에 그 수준에서 좀 더 적응적인 접근 방식을 사용합니다. 프로그램 레벨의 주요 요소는 비전, 로드맵, 릴리스 관리 입니다.

Vision

비전 작성을 위한 Input은 다음과 같이 구성됩니다.

• Investment Theme Driven Strategy
• Portfolio Epics
• Customer Value Stream Feedback
• Architectural
• Team Inputs
  

Road Map

SAFe 로드맵은 일정 기간 동안 릴리스에 제품 기능을 할당하는 계획을 제공한다는 점에서 일반적인 애자일 로드맵과 유사하지만, 엔터프라이즈 레벨에서는 모든 팀 간에 정렬을 설정하는 추가적인 기능을 제공합니다. Roadmap은 Roadmap의 내용을 정의하기 위해 Rolling Wave Planning 접근방식을 사용합니다.

Release Management

SAFe는 Enterprise-level 에서 릴리스 관리의 중요성을 인식합니다. 릴리즈는 일반적으로 특정 비즈니스 목표와 기능을 제공하는 데 초점을 맞추고 있으며, 릴리즈 엔지니어 또는 프로그램 매니저가 조정을 제공합니다.

Scaled Agile Framework Portfolio Level

Portfolio Layer는 프로그램이 회사의 비즈니스 전략과 투자 의도에 맞춰 조정되는 Scaled Agile Framework 에서 가장 높고 전략적인 계층입니다.

Portfolio Management

모든 포트폴리오 관리 접근방식의 전반적인 목표는 새로운 이니셔티브에 대한 기업의 투자로 인한 수익을 최적화하는 것입니다. 대표적인 포트폴리오 관리 접근법에는 다음과 같은 두 가지 주요 요소가 있습니다.

• 첫째는 회사의 비즈니스 목표에 부합하고 선택한 이니셔티브의 위험/수익 최적화를 위한 올바른 이니셔티브를 선택하는 것입니다. 이 부분은 여러분이 주식시장 투자 포트폴리오를 선택하기 위해 하는 것과 유사합니다. 주어진 위험 수준에 대한 잠재적 수익률을 극대화하는 주식과 채권의 혼합을 선택할 수 있습니다.
  

• 두 번째 구성요소는 이니셔티브가 예상 수익을 달성하도록 선정되면 이니셔티브를 적극적으로 관리합니다.
  

Methods of Portfolio Management

두 가지 유형의 포트폴리오 관리를 살펴보면,

• 전통적인 포트폴리오 관리 접근방식에서 프로젝트의 잠재적 수익에 대한 상세한 재무 분석이 프로젝트의 최적 혼합을 선택하기 위해 수행될 수 있으며, 일단 프로젝트의 혼합이 선택되면 한동안 비교적 정적인 상태로 유지될 것입니다.
  

• 보다 동적인 모델에서는 일반적으로 프로젝트 포트폴리오를 선정하기 위해 엄격한 재무 분석을 할 수 없습니다. 왜냐하면 그러한 종류의 분석을 기초로 하는 프로젝트에 대한 정보의 수준이 불충분할 수 있기 때문입니다. 그 결과 예상되는 비즈니스 가치 프로젝트에 기반한 보다 전략적인 평가가 이루어져야 하며, 일단 선정되면 훨씬 더 역동적이고 변경될 수 있습니다.
  

• 일단 선정되면 사업 포트폴리오를 어떻게 관리하느냐에도 큰 차이가 있습니다. 전통적인 포트폴리오 관리 접근법에서 PMO 또는 일부 동등한 기업은 프로젝트의 선택이 기대치에 부합하도록 포트폴리오 관리 전략의 실행을 관리할 책임이 있습니다. 이는 일반적으로 진행 중인 프로젝트의 상세 진행 상황 추적 및 보고에 의해 이루어집니다.
  

• 좀 더 역동적인 포트폴리오 관리 모델에서는 프로젝트를 관리하기 위한 그러한 접근방식이 동적 포트폴리오 관리 접근방식과 매우 일관되지 않을 수 있으며, 일반적으로 많은 책임이 프로젝트 팀이 수행하는 작업을 미세하게 관리하지 않고 권한을 부여받은 팀에게 위임됩니다. 증분 개발 접근방식은 실제 산출물의 측면에서 진행률을 측정할 수 있습니다.
  
  

Scaled Agile Framework – Portfolio Layer

Portfolio Layer 다음과 같이 구성됩니다.

• Investment Themes

  시장 차별화 및 경쟁 우위를 제공하는 주요 제품 또는 서비스 가치 제안을 나타냄
  

• Epics

  투자 테마의 가치를 실현하는 대규모 개발 이니셔티브임
  

  Investment Themes 와 Epics 은 프로그램 실행의 세부사항에 너무 깊이 들어가지 않고 프로그램 전반에 걸쳐 포트폴리오 통합을 제공하는 방법입니다.
  

• Architectural Runway

  기업의 제품 포트폴리오의 맥락에서 그리고 일련의 짧은 증분 출시 앞에서, Architectural Runway 는 ‘향후 1년 정도 내에 새로운 종류의 기능을 안정적으로 제공할 수 있도록 지금 어떤 기술 이니셔티브가 진행되어야 하는가?’ 라는 큰 질문에 대한 해답입니다.
  

  Architectural Runway 는 일반적으로 포트폴리오 계층에서 정의되고 있는 비즈니스 이니셔티브를 지원하기 위해 어떤 기술 혁신이 필요할지 예측하려는 senior-level architect 그룹에 의해 정의되며, 또한 현재 개발 노력에 대한 구조적 방향을 제공합니다.
  

• Portfolio Vision and Backlog

  Portfolio Vision은 비즈니스 Epis를 통해 Investment Themes 를 실현하는 방법에 대한 가시성을 제공합니다. Epics은 테마가 내포한 가치를 전달하며, 포트폴리오 백로그에서 식별, 우선순위 지정, 추정 및 유지됩니다. Portfolio vision은 프로그램 레벨의 제품 로드맵과 유사하지만 더 높은 레벨에 있습니다.
  

• Kanban Systems

  Framework는 포트폴리오 백로그를 관리하기 위해 약간 다른 두 개의 칸반 시스템을 적용합니다. 하나는 Business Epics를 위한 칸반이고, 다른 하나는 architectural Epics를 위한 칸반이다. 칸반은 이러한 영역의 업무 흐름을 관리하는데 사용됩니다.
  

• Portfolio Management Team

  포트폴리오 관리 팀은 사업 라인에 대한 궁극적인 책임을 가진 개인들로 구성됩니다. 그들은 보통 포트폴리오 관리 노력에 대한 사업 방향을 제공하는 책임을 지는 senior-level business manager 들입니다.
  
  

이번글은 여기까지 소개드리며, Scaling Scrum 관련하여 Scrum@Scale 접근방식의 주요 내용 및 Scaled Agile Framework (SAFe)의 Portfolio Level, Program Level, Team Level의 3가지 Level별 주요 내용에 대해 이해하는 데 도움이 되었기를 기대해 봅니다.

휴우….영어 강의를 듣고 번역/이해 및 정리하는데 꽤 시간이 걸리는군요. 번역 상에 문맥이 좀 매끄럽지 않은 부분이 있더라도 너그럽게 양해 부탁드려요…..

이전글

• Advanced Agile Project Management - ⑤
• Advanced Agile Project Management - ④
• Advanced Agile Project Management - ③
• Advanced Agile Project Management - ②
• Advanced Agile Project Management - ①