Advanced Agile Project Management - ③

Advanced Agile Project Management - ③

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

이번 글은 Hybrid Agile Approach의 특성 및 올바른 Approach를 위해 고려해야할 주요 요인들에 대해 소개하고자 합니다.

Agile에 대한 고정관념과 오해들

Agile이 무엇인 지와 관련된 매우 강한 고정관념과 오해들이 있습니다.

1. Agile Projects Are Totally Unplanned

첫번째 고정관념은 Agile 프로젝트는 전혀 계획 없이 진행한다는 것입니다. Agile은 실제로 많은 계획이 진행되고 있습니다. 이것은 단지 Heavy하거나 완전히 앞쪽에 치중하여 계획하기보다는 그 프로젝트 전체에 널리 퍼져있는 다른 종류의 “Just-in-time” 계획을 수행하고 있습니다.

2. Agile projects do not use any process and are uncontrolled

두번째 고정관념은 Agile 프로젝트는 어떠한 프로세스도 사용하지 않고 통제되지 않는다는 것입니다. 그 고정관념 또한 잘못된 것입니다. 대부분의 Agile 프로젝트들은 매우 잘 정의된 프로세스인 스크럼을 사용합니다. 그것은 다른 종류의 프로세스입니다. 엄격하고 규범적이기보다는 훨씬 더 경험적이고 적응적이지만 잘 정의된 프로세스입니다. 또한 Agile 프로젝트에 원하는 수준의 Control 기능을 적용할 수도 있습니다.

3. There is no project management required for an agile project

세 번째 고정관념은 Agile 프로젝트에 프로젝트 관리는 필요 없다는 것입니다. 팀 차원의 Agile 프로젝트에는 ‘Project Manager’ 라는 직함을 가진 사람이 없을 수 있지만, 많은 프로젝트 관리가 진행되고 있습니다. 그것은 단지 ‘Project Manager’ 라고 불리는 한 특정 개인에 의해 보유되는 것이 아니라, 프로젝트 관리 기능이 팀 내의 여러 다른 사람들에 의해 분배될 뿐입니다.

4. Documented requirements are not consistent with agile

네 번째 고정관념은 문서화된 요구사항은 애자일 사상과 맞지 않는다는 것입니다. 사실 그렇지 않습니다. 문서는 가치를 부가하는 Agile 프로젝트에서 여전히 유용합니다. 문서는 단지 문서 작성을 위해서만 수행되지 않아야 한다. 어떤 종류의 문서도 완전히 제거하지 않고 문서 사용을 간소화하는 방법은 여러 가지가 있습니다. 예를 들어, 요구사항 정의 프로세스를 단순화하기 위해 프로젝트가 진행됨에 따라 간단한 User story Format 을 사용하여 요구사항이 온라인 도구에 문서화되는 경우가 많습니다.

5. “Agile” as the polar opposite of “Waterfall”

Agile을 폭포수 모델의 반대편 극지로 보고 극단의 사이에 이진 선택이 있다고 생각하는 잘못된 오해들이 있으나, 그것은 그렇지 않습니다.

이러한 고정관념을 극복하려면…

Agile을 새로운 시각으로, 폭포수 모델과 경쟁하는 것으로 보지 말고 그 두 가지 대안을 상호 보완적으로 보아야 합니다. 그리고 이 두 가지 대안을 이진적이고 상호 배타적 선택으로 보지 말고 상황에 맞는 적절한 비율로 Agile 및 Plan-driven Practices 를 모두 혼합하는 Adaptive Approach(적응적 접근법)을 개발하는 방법을 배워야 합니다.

Hybrid Agile Models

What Is a Hybrid Agile Approach?

우선, Hybrid Agile 접근 방식이 무엇인지부터 간략히 정의해 보겠습니다.

“Hybrid Agile 접근 방식은 주어진 상황에 맞는 적절한 비율로 Plan-driven 과 Agile (Adaptive)의 Principles and Practices를 결합하는 접근 방식입니다.” 이 방법은 모든 Agile 프로젝트 매니저에게 있어 기본적인 Skill 입니다.

Why Would You Use a Hybrid Agile Approach?

Hybrid Agile 접근 방식을 고려하는 이유는 크게 두 가지입니다.

1. Hybrid as fit-for-purpose:

• Risk가 낮은 프로젝트의 경우, 더 낮은 비용을 찾기 위해 Plan-driven 접근 방식을 사용하는 겁니다.
• Risk가 높은 프로젝트의 경우 Iterative Techniques 을 사용하여 문제가 드러나고 해결될 때까지 활동을 반복하는 겁니다.
• Aggressive Delivery가 필요한 프로젝트의 경우, Incremental Techniques은 고객의 참여를 보장하기 위해 무언가를 더 빨리 Delivery할 것입니다.
• 마지막으로, 복잡한 환경을 탐색하기 위해 Agile Techniques은 초기 오버헤드가 더 높을 수 있지만 전체적인 결과를 위해 그럴만한 가치가 있을 수 있습니다.

2. Hybrid Agile model is as a transition to Agile:

• 많은 팀이 Agile 변화를 위해 밤샘 작업 방식으로 전환할 수는 없습니다.
• 조직이 클수록 움직이는 이해관계자 및 구성 요소가 많아지고 Shift 하는데 시간이 오래 걸릴 수 있습니다.
• Plan-driven 세계에서 수년 동안 살아왔다면, Agile methods 는 매우 다르게 보이고 느낄 것입니다. 결과적으로, 여러분의 Agile 세계로의 초기 진출은 둘 다 엉망진창이 될 수도있습니다. 괜찮습니다. 여러분이 가고 싶은 방향으로 움직이기 위해 특정한 기술을 사용하고 있는 겁니다.

General Hybrid Agile Approach Benefits

Traditional Plan-driven Approach	Agile Approach
일관되게 구현되고 어느 정도 예측 가능한 잘 정의된 프로세스 높은 수준의 마일스톤을 통해 사용자 기대치를 관리하고 Agile 개발 환경 외부의 다른 활동과의 통합을 위한 프레임워크 제공 프로젝트의 범위와 비용을 쉽고 효과적으로 관리	불확실한 비즈니스 환경에서 최적화된 유연성 및 적응성 솔루션의 비즈니스 가치를 극대화하기 위한 창의성 및 혁신을 강조 직접적인 사용자 피드백 및 반영으로 인한 사용자 만족도

Time-to-market

Time-to-market을 크게 개선할 수 있는 방법은 다음과 같습니다 :

• Requirements를 도출하고 Releases 와 Iterations으로 Grouping
• 증분 제공(Incremental Delivery) 프로세스를 사용하여 조기에 구현된 기능을 제공
• 가능한 경우 노력은 더 동시에 덜 순차적으로 수행

Risk Management

리스크 관리를 개선할 기회도 있습니다.

• 먼저 고위험 항목에 초점을 맞추고 특정 위험 평가에 “Spike”를 부여하여 격리하도록 프로젝트를 구성함으로써 위험을 조기에 감지할 수 있는 능력이 있습니다.
• 일단 리스크가 구체화되면, 광범위한 Re-planning 없이 리스크에 동적으로 적응할 수 있는 능력이 있습니다.

Productivity and Efficiency

마지막으로, 생산성과 효율성을 크게 개선할 수 있는 기회가 있습니다.

• 팀에게 프로젝트에 맞게 프로세스를 조정할 수 있는 권한을 부여
• 프로젝트에 맞게 프로세스를 최적화
• 불필요한 서류작업 감소
• 더 많은 권한을 부여 받은 팀이 높은 동기 부여 환경을 조성
• Collaborative하고, Cross-functional한 접근 방식을 통해 커뮤니케이션 및 의사 결정을 개선

What Is Different About a Hybrid Agile Model?

Hybrid Agile 접근 방식을 위한 표준화된 “ Cookbook” 형태의 단계별 솔루션이 정해져 있지는 않습니다. 프로젝트의 성격에 맞는 접근 방식에 상당한 수준의 맞춤화가 필요하며, 이는 훨씬 더 많은 기술을 필요로 할 수 있지만, 확실히 이루어질 수는 있습니다.

Levels of Planning with Scrum

Scrum only defines a process for a team- level and sprint-level:

스크럼은 아마도 세계에서 가장 널리 사용되는 Agile 방법론이며 Agile 프로젝트를 정의하기 위한 훌륭한 프레임워크를 제공하지만 실제로는 Team-level 및 Sprint-level 프로세스를 위한 프로세스만 정의합니다. 그것은 더 크고 더 복잡한 Enterprise-level 프로젝트에 그 위에 필요할 수 있는 추가적인 관리 계층을 명시적으로 명시하지는 않습니다.

인식해야 할 중요한 점은 몇몇 사람들이 생각하는 것처럼 전혀 계획하지 않고 코드를 작성하는 것으로 시작하는 Agile 프로젝트들은 거의 없다는 것입니다. Agile 프로젝트에서는 항상 일정 수준의 계획이 적절하지만, Scrum은 더 높은 수준의 계획을 명시적으로 지정하지는 않습니다.

더 크고 더 복잡한 프로젝트의 경우, 계획에 더 많은 계층을 추가하는 것이 필수적입니다.

대부분의 Scrum 프로젝트는 적어도 프로젝트의 높은 Level의 Goal과 Objectives를 가지고 있을 것입니다. 그러나 Project-level의 계획은 프로젝트의 성격에 따라 필요에 따라 “Thick”하거나 “Thin”할 수 있습니다.

Project-level 계획은 팀을 중심으로 “개발자”를 형성하고 Scrum에 의해 정의된 Sprint-level 계획 프로세스는 일반적으로 최소한 어느 정도 역동적일 것입니다. 프로젝트 전체 기간 동안 변경되지 않을 수 있는 경직된 선행 계획을 정의하기보다는 팀으로부터 배운 교훈과 Sprint-level 계획 프로세스가 Project-level 계획 프로세스에 다시 반영되어 필요에 따라 Project-level 계획을 조정할 것으로 예상됩니다.

그리고 물론 프로젝트의 범위와 복잡성에 따라 Release-level 계획도 필요할 수 있습니다.

Different Levels of Agility

접근방식의 스펙트럼을 살펴보면,

• 한 가지 극단적으로, 매우 적응력이 높은 접근 방식은 Release-level 계획 또는 Project-level 계획이 거의 없는 Team-level 계획에만 국한될 수 있습니다.
  
• 또 다른 극단적 관점에서, Plan-driven 접근방식은 Project-level 계획 및 Release-level 계획에 훨씬 더 높은 Level에 보다 더 중점을 둘 것입니다.

이러한 각 Level에서 계획에 대한 강조 Level을 조정함으로써, 민첩성과 적응성의 Level이 서로 다른 광범위한 Hybrid Agile 접근법을 만들 수 있습니다.

중요한 점은 이러한 사항들 중 어느 것도 Agile 프로젝트에서 수행될 수 있는 것과 크게 다르지 않다는 것이지만 표준 Agile 환경에서 이러한 사항들에 대한 필요성은 잘 정의되어 있지 않다는 것입니다. 경우에 따라, 이런 것들이 필요하지 않을 수도 있지만 현실에서는 필요할 수도 있습니다.

General Hybrid Agile Approach Characteristics

위 그림은 일반적인 Hybrid Agile 프로세스를 보여 줍니다.

• 프로세스의 핵심은 Agile/Scrum 개발 프로세스를 기반으로 합니다.
  
• 프로젝트의 전체적인 비전과 범위를 정의하고 프로젝트의 특성에 맞게 프로세스를 조정하기 위해 프로젝트의 시작 단계에 더 많은 Front-end Inception Planning 이 추가될 것입니다. Agile 프로젝트에서 발생하는 Front-end 계획이 없다는 것은 아니지만 Front-end 계획을 위한 Needs가 잘 정의되어 있지 않다는 뜻입니다. 프로젝트의 성격에 따라 Front-end Planning 수준이 제한될 수 있습니다.
  
• 프로젝트가 진행 중일 때 보다 지속적인 프로젝트 관리가 있을 수 있습니다. 이는 전통적인 계획 중심의 프로젝트 관리는 아니지만, 노력의 범위를 관리하기 위해 어느 정도 수준의 프로젝트 관리가 필요할 수 있습니다.
  
• 마지막으로, 프로젝트의 Back-end에 어느 정도 릴리스 및 배치 프로세스가 있을 수 있습니다. 이것은 일반적으로 Agile 프로젝트에서 수행해야 할 사항이지만 공식적으로 정의하지는 않습니다.
  

Key Differences from a Waterfall Approach

폭포수 모델 접근법과의 몇 가지 주요 차이점을 간단히 요약해 보겠습니다.

1. 비즈니스 스폰서 및 비즈니스 사용자와의 파트너십

프로젝트 범위에 대한 높은 수준의 이해와 높은 수준의 요구사항은 매크로 수준에서 사용자 이야기 형태로 존재합니다. 요구사항 정의의 세부 수준은 프로젝트의 성격에 따라 달라질 수 있지만, 일반적으로 Project-level 계획에서 솔루션 개발 방법에 대한 모든 세부사항을 지정할 필요는 없습니다. 비즈니스 스폰서/사용자 및 프로젝트 팀은 Micro-level 프로세스에서 성공할 수 있도록 솔루션의 세부 사항을 추가로 정의하고 최적화해야 하는 책임을 공동으로 집니다.

2. Cross-Functional Team Approach

팀 내 다양한 기능 참여자(개발자, 비즈니스 분석가, 테스터 등)가 비즈니스 사용자와 통합 팀으로 동시에 작업하여 프로젝트 전반에 걸쳐 솔루션을 공동으로 정의, 개발 및 테스트할 수 있는 더 많은 Cross-functional Team Approach 방식이 필요합니다.

또한 전체 프로젝트 팀은 비즈니스 스폰서, 제품 소유자 및 비즈니스 사용자들과 함께 Project-level 계획 및 Release-level 계획 활동의 일환으로 상호 기능적인 협업 결정을 내리는 데 참여할 것입니다.

3. Rolling Wave Planning Approach

“Progressive Elaboration” 과 “Rolling Wave” Planning 을 사용합니다. 요구사항은 일반적으로 초기 프로젝트 계획에서 high-level 로만 정의되며, 이후 프로젝트가 진행됨에 따라 요구사항이 보다 구체화됩니다.

4. Incremental and Iterative Development Approach

전체 솔루션을 설계, 개발 및 테스트하기 위해 순차적 접근 방식을 사용하는 대신, 전체 솔루션의 일부를 점진적으로 설계, 개발 및 테스트하기 위해 반복적 접근 방식을 사용합니다. “Micro” Level 에서는 Scrum과 같은 표준 Agile 접근 방식을 사용하여 개발 프로세스를 관리할 수 있습니다.

Agile Inception Planning and choosing the right approach

Inception Planning의 세부사항에 들어가기 전에 고려해야 할 가장 중요한 것 중 하나는 프로젝트에 맞는 올바른 접근법을 개발하는 것입니다. 올바른 접근법을 개발할 때 고려해야 할 주요 요인은 다음과 같습니다.

• 불확실성 수준
• 이해관계자 관리
• 프로젝트 팀의 교육 수준 및 역량 숙련도

그럼 각각의 요인에 대해 간략히 살펴보겠습니다.

Level of Uncertainty

올바른 접근법을 선택하는데 가장 중요한 요소는 프로젝트의 불확실성 수준입니다. 불확실성 수준의 두 가지 차원으로 식별해봅니다.

• 첫 번째 차원은 요구 사항에 대한 합의 수준 – 프로젝트 요구 사항을 얼마나 잘 정의하고 이해하고 있는가?

• 두 번째 차원은 기술과 관련된 확실성 수준 – 기술 및 문제 해결을 위한 솔루션이 얼마나 잘 이해되고 있는가?

일반적으로 불확실성 수준이 높을수록 더 적응적인 접근방식과 불확실성 수준이 낮을수록 더 계획 중심적인 접근이 도움이 될 수 있습니다.

Stakeholder Management

고려해야 할 또 다른 중요한 요소는 프로젝트의 주요 이해관계자 Relationship과 참여(Participation) 수준입니다.

이해관계자 Relationship이 상당히 협력적인 경우, 보다 Agile 접근법을 선호하는 경향이 있을 것이고, 이해관계자 사이의 관계가 더 계약적인 경우, 아마도 더 계획 중심적인 접근법을 선호하는 경향이 있을 것입니다. 이해관계자와의 관계는 큰 영향을 미칩니다. 협업적 이해관계자는 전반적인 사업목표를 달성하기 위해 요구사항이 어떻게 구현되는지에 대해 유연할 수 있는 반면 계약상 이해관계자는 프로젝트 요구사항에 대해 유연성이 없을 수 있습니다.

이해관계자 관리와 관련된 두 번째 요인은 주요 이해관계자가 프로젝트에 기꺼이 참여할 수 있는 수준입니다. 이해관계자가 프로젝트에서 상당히 적극적인 역할을 기꺼이 수행할 경우, 보다 민첩한 접근방식을 선호하는 경향이 있을 것입니다. 이해관계자가 프로젝트 수행으로부터 더 멀리 떨어져 있고자 한다면, 아마도 더 계획 중심적인 접근법을 선호할 것입니다.

Training and Sophistication of the Project Team

마지막으로 고려해야 할 요소는 프로젝트 팀의 교육 수준과 역량 숙련도입니다. 당연히, 프로젝트 팀뿐만 아니라 조직 내의 다른 사람들도 여러분이 어떤 접근법을 선택하든 적절한 수준의 훈련을 받아야 합니다. Agile 접근 방식은 높은 수준의 교육과 역량을 필요로 합니다.

Interrelationship of Factors

세 가지 요인 모두 서로 연관되어 있습니다. 예를 들어, 프로젝트의 불확실성 수준은 일반적으로 올바른 접근법을 선택하는 데 가장 중요한 요소지만 다른 두 가지 요소는 제약조건입니다. 불확실성 수준이 높은 경우, 보다 Agile 접근법을 선호하는 경향이 있을 수 있지만, 프로젝트 팀의 교육 및 역량 숙련도 수준이 Agile 접근법과 일관되지 않는 한, 주요 이해관계자와의 관계가 작동하지 않을 것입니다.

이 외에 올바른 접근 방식을 선택하는 데 영향을 미칠 수 있는 다른 요인 중 일부를 살펴보겠습니다.

• 첫 번째는 위험 수준 및 위험 관리 접근법입니다. Agile 접근방식은 고위험 프로젝트에 적합하거나 적합하지 않을 수 있습니다. 한편으로, Agile 접근법은 광범위한 재계획 없이 잠재적으로 훨씬 더 동적으로 위험에 적응할 수 있습니다.
  그러나 한편으로, 이를 위해서는 기술과 정교함이 필요합니다. 프로젝트가 위험 수준이 높고 프로젝트 팀이 위험 관리에 대한 동적 접근 방식을 채택하는 데 상당한 수준의 숙련도를 갖추지 못한 경우, 보다 계획 중심적인 접근 방식이 더 적절할 수 있습니다.
  

• 두 번째는 프로젝트 팀의 지리적 분포입니다. Agile은 팀이 서로 협력하는 경우 최상으로 작동되지만, 분산될수록 Agile 접근 방식을 적용하기가 더 어려울 수 있습니다.
  

• 프로젝트의 범위와 복잡성은 또 다른 주요 요인입니다. Agile은 여러 팀이 필요한 프로젝트에 대해 확장하기가 어려울 수 있으며 이를 위해 고도의 정교함이 필요할 수 있습니다. 조직이 크고 복잡한 다수의 팀 프로젝트를 위해 Agile 확장 모델을 상당히 정교한 방식으로 수행할 준비가 되어 있지 않은 경우, 보다 계획적인 접근이 필요할 수 있습니다.
  

• 마지막으로, 프로젝트 內 팀의 수(The number of teams)는 일반적으로 프로젝트의 범위와 복잡성과 직접적인 관련이 있습니다.
  

Hybrid Agile Project Management Role

한 가지 극단적인 경우, 여러분은 확고한 약속과 세부 요구사항, 그리고 어떤 형태의 변경 통제와 함께 꽤 잘 정의된 계약이나 프로젝트 계획을 가지고 있을 수 있습니다. 전형적인 계획 중심 프로젝트 환경이기 때문에 모든 프로젝트 매니저들은 그 상황에 매우 익숙합니다.

다른 극단적 경우는, 여러분은 매우 느슨하게 정의된 계약이나 프로젝트 계획, 노력의 전체적인 목표가 정의되지만 프로젝트가 진행됨에 따라 세부 요구사항이 정의될 것으로 예상되는 매우 적응적인 계약이 있을 수 있습니다.

이 두 가지 극단의 중간에는 프로젝트가 진행됨에 따라 요건을 정의할 수 있는 어느 정도의 융통성이 있는 계약을 체결할 수 있는 광범위한 시나리오가 있습니다.

인식해야 할 중요한 것은 상황에 대한 접근법을 맞춰야 한다는 것이고 그 결정을 내릴 때 가장 중요한 요소 중 하나는 불확실성의 수준입니다. 광범위한 시나리오를 단일 접근방식에 강제 적합시키려 하는 것은 잘 작동하지 않으며, 이는 프로젝트 관리자가 기존의 계획 중심 접근방식을 넘어 다양한 접근방식을 다루도록 훈련 받는 것이 중요한 주요 이유입니다.

Relationship with the Customer

고객과의 관계는 매우 중요한 변수입니다. 솔루션 제공자와 고객 모두 상황의 불확실성 수준과 어떻게 관리될 것인지에 대해 공통적으로 이해해야 합니다. 만약 그것에 대한 단절이 있다면, 그것은 몇몇 중요한 놀라움과 문제들로 이어질 수 있습니다. 예를 들어, 고객이 정해진 가격과 납품 일정을 제공하는 매우 명확한 계약으로 무언가를 구입하고 있다는 기대를 가지고 있고, 솔루션 제공자가 변경사항을 어떻게 관리할 것인지에 대한 공통적인 이해뿐만 아니라 동일한 기대치를 가지고 있지 않다면, 그것은 큰 문제가 될 수 있습니다.

상황의 불확실성 수준이 매우 높다면, 프로젝트 진행 중 상황을 관리하기 위해 고객과 솔루션 제공자 간의 많은 신뢰와 파트너십을 요구합니다. 그것은 고객과 솔루션 제공자 사이에 더 많은 적대적 관계가 있다면, 사업을 진행함에 따라 많은 협상이 필요할 수 있습니다.

Using Agile Concepts in Non-Agile Projects

마지막으로, 진정한 “Agile” 프로젝트나 Hybrid Agile 프로젝트에 결코 참여하지 않더라도, 기존의 계획 중심 프로젝트의 효과를 높이기 위해 Agile 개념을 사용하는 방법은 다양합니다. 다음은 Agile 접근 방식을 반드시 완전히 채택하지 않고도 프로젝트를 개선할 수 있는 몇 가지 예를 들어 보겠습니다.

• 비즈니스 사용자와 보다 협업적인 접근 방식 개발 – 어느 프로젝트에서나 사용할 수 있는 신뢰와 파트너십을 기반으로 한 협업 접근 방식을 개발하는 것이 중요하다는 것을 알려줍니다.
  

• 비즈니스 가치 극대화에 보다 중점을 두는 – Agile 프로젝트 매니저는 기존의 프로젝트 비용 및 일정 관리 강조와 달리 비즈니스 성과에 보다 중점을 두는 방법을 배울 필요가 있습니다.
  

• 더 반복적인 접근 방식 – 일반적으로 모든 프로젝트를 반복적으로 분리하여 기능을 점진적으로 발전시키는 것이 매우 쉬우며, 이는 모든 프로젝트에서 크게 개선될 수 있습니다.
  

• 불필요한 문서화 및 오버헤드 감소 – 불필요한 문서화 및 오버헤드 감소는 모든 프로젝트의 효율성 향상에 도움이 될 수 있는 또 다른 개선 사항입니다.
  

비유를 해보면, 축구 선수에게 발레를 가르치는 것과 같다는 것입니다. 발레 실력은 축구 기술과 양립할 수 없는 것처럼 보일 수 있고, 축구 선수는 직접 발레를 사용하지 않을 수도 있지만 발레에서 배운 민첩성은 그를 훨씬 더 나은 축구 선수로 만들 것입니다.

많은 Agile 원칙과 실천은 올바른 맥락에서 적용되는 한 많은 이치에 맞을 것입니다.

Hybrid Agile Approach 특성 및 올바른 Approach를 위해 고려해야할 주요 요인들을 이해하는 데 도움이 되었기를 기대해 봅니다. 다음 편을 기대해 주세요.

Comming Soon ~~

이전글

• Advanced Agile Project Management - ②
• Advanced Agile Project Management - ①