Advanced Agile Project Management - ⑤

Advanced Agile Project Management - ⑤

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

이번 글은 Enterprise 레벨에서 다른 몇 가지 주요 과제를 포함한 Enterprise 레벨에서의 Agile을 적용하는 데 있어 무엇이 다른지 개괄적으로 살펴보고, Agile Manifesto 가치의 매우 다른 맥락의 원칙에서 재해석을 해보고, 다음으로 프로젝트 거버넌스가 Agile 환경에서 어떻게 적용되는지에 대해 설명하고자 합니다.

Enterprise-level Agile Project Management

많은 조직에서 Agile 방식으로 작업하는 팀이 있지만 전체 Enterprise-level 차원에서 이러한 모델을 구현하는 것은 쉽지 않습니다. 기업들이 개별 프로젝트에서 포트폴리오로, 그리고 궁극적으로 전체 비즈니스를 Agile로 적용함에 따라, 더 많은 핵심 프로세스들이 적용 되어야 하는데, 이는 그 자체로 중요한 운영상의 과제입니다.

How Do You Define Project Success?

• 세상은 급변하고 있으며, Traditional Plan-driven 프로젝트 관리 세계에서 수년 동안, On-time 과 Under-budget에 맞추어 일을 제공함으로써 성공을 정의해 왔습니다. 그리고 두번째 목표는 그것을 하기 위해 효율적이고 효과적인 과정을 사용하는 것이었습니다. 이 접근방식의 문제는 많은 프로젝트들이 비용과 일정 목표를 달성했고 성공적이라고 생각되었지만 필요한 Business value를 제공하지 못했다는 것입니다.
  

• 하지만, Value- driven delivery 는 “ Building the right thing “ 을 더욱 강조합니다. 고객을 위한 진정한 가치를 창출합니다. 이것은 프로젝트 관리 접근방식에 있어 주요한 변화로, 기존의 Traditional Plan-driven 프로젝트 관리로 과거에 강조되었던 것과는 다른 생각과 관행을 필요로 합니다.
  

• 이러한 새로운 환경에서는 예측 가능성을 달성하기 위한 계획과 통제보다 창의성과 혁신 그리고 출시 시간이 똑같이 중요할 수 있습니다. 단순히 일정 및 비용 목표에 대한 명확한 요구사항을 제공하기 위한 프로젝트 관리만으로는 많은 상황에서 더 이상 적절하지 않습니다. 프로젝트 매니저들은 프로젝트가 제공하는 솔루션의 비즈니스 가치를 극대화하기 위해 회사의 비즈니스 전략과 잘 통합된 전반적인 접근 방식을 취해야 할 것입니다.
  
  

Enterprise-level Agile Project Management

더 크고 복잡한 Enterprise급 프로젝트에 들어갈수록 좀 더 복잡해집니다. 여러 Agile 팀과 협력할 수 있도록 프로젝트를 확장하고 모든 프로젝트가 회사의 비즈니스 전략에 맞게 올바른 방향으로 이동하도록 프로젝트 포트폴리오 관리 접근 방식을 제공하는 것과 관련된 과제가 있습니다.

Why Is This Important to Project Managers?

대규모 복합 Enterprise 레벨의 Agile 적용에는 잠재적으로 다양한 수준의 관리가 있을 수 있습니다. Bottom level 에서는 단순한 팀 레벨의 Agile 적용이 전체 Agile 적용으로 전환될 가능성이 가장 높으며 기존 프로젝트 관리에 대한 필요성을 최소화할 수 있습니다. 더 높은 단계로 올라갈수록 프로젝트 관리자가 잠재적으로 제공할 수 있는 부가가치가 훨씬 더 중요해집니다.

많은 단순하고 팀 수준의 프로젝트 관리 역할은 프로젝트 매니저에게 더 높은 레벨로 이동하도록 요구하는 Agile에 의해 대체될 것입니다.

그렇기 때문에 프로젝트 매니저들은 선도적인 팀 레벨 프로젝트를 넘어 Enterprise 아키텍처의 Higher-level 에 집중하는 것이 매우 중요합니다.

Agile을 Enterprise 수준으로 확장하는 것과 관련된 두 가지 주요 유형의 과제가 있습니다.

• 첫 번째는 방법론에 내재된 도전
  • 팀 레벨의 Agile 몇 가지 관행을 Enterprise 레벨로 확장
  • Agile Manifesto 가치와 원칙을 훨씬 광범위한 Enterprise 수준의 맥락에서 재해석
    
• 두 번째는 기업이 부과한 도전
  • 비즈니스에 맞는 Agile 접근 방식 조정
  • 문화 문제 극복 및 변화 관리
    
    

Differences in Enterprise-level Practices

Enterprise 레벨에서의 Agile을 적용하는 데 있어 무엇이 다른지 개괄적으로 살펴보겠습니다

1. Enterprise-level Challenges – Customer Participation

첫 번째 차이점은 고객 참여입니다. 소규모 Agile 프로젝트에서도 고객은 팀과 일체가 되어 함께 하지만, 일반적인 대규모 Enterprise급 적용에서는 그 이상의 다양한 환경이 존재합니다.

• 고객이 원격 상태일 수도 있고 Agile 팀에 직접 참여할 수 있는 기술이나 시간이 없을 수도 있습니다.
  

• “고객”은 다양한 사용자 및 이해관계자로 구성될 수 있습니다.
  

• 팀의 비즈니스 분석가(BA)는 좀 더 복잡한 요구사항을 분석하고 고객과의 인터페이스를 관리하도록 도울 수 있지만, BA가 관여하는 경우 고객과의 직접 통신을 필요 이상으로 제한해서는 안 됩니다.
  
  

2. Enterprise-level Challenges – Development Team Organization

소규모 Agile 프로젝트에서는 일반적으로 개발자, 제품 소유자 및 테스터를 훨씬 쉽게 조합할 수 있지만, 일반적인 대규모 기업 수준 에서의 적용은 다음과 같은 구성이 존재할 수 있습니다.

• 많은 팀 구성원이 다른 국가 및 표준 시간대에 있을 수 있으며 심지어 다른 언어를 말할 수도 있습니다.
  

• 팀의 또다른 팀에게 어느 정도 수준의 지침과 방향을 제공할 수 있는 더 높은 수준의 기술 리더가 이끄는 더 많은 주니어 레벨 개발자들로 팀을 구성해야 합니다.
  
  

3. Enterprise-level Challenges – Application Architecture

• 프로젝트의 진행에 따라 아키텍처의 변화를 수용하기 위해 설계를 재조정하는 비용과 어려움을 갖게 되고, 대부분의 경우에 프로젝트 앞 단계에 아키텍처 계획과 설계를 더 많이 수행하게 됩니다.
  

• 대규모 시스템 설계는 하위 구성요소로 세분화해야 하며 충분한 아키텍처를 정의하지 않고서는 팀에게 작업을 할당하는 것이 어려워집니다.
  

• 또한 구현하고자 하는 솔루션은 다른 Enterprise급 소프트웨어와 통합해야 하며, 조직이 다른 애플리케이션과 상호운용성을 보장하기 위해 사용하는 모든 표준을 준수해야 합니다. 그것은 일반적으로 프로젝트 초기에 계획 및 설계 검토가 필요합니다.
  

• 또 다른 고려사항은 솔루션이 일반적으로 훨씬 크고 복잡하기 때문에 필요한 활동 수준이 훨씬 더 클 수 있기 때문에 설계가 진행 중인 후 솔루션을 재설계하거나 재조정해야 하는 것과 관련된 위험이 훨씬 크다는 것입니다.
  
  

4. Enterprise-level Challenges – Requirements Management

소규모 애자일 프로젝트에서 애자일 개발 활동은 잠재적으로 한 번에 한 가지씩 발생할 수 있으며 프로젝트 기간 동안 설계가 점진적으로 진화합니다. 일반적인 Enterprise-level 구현의 경우, 다음과 같은 여러 가지 이유로 Enterprise-level 에서 요구 사항을 보다 전향적으로 계획할 필요가 있습니다.

• 아키텍처와 요구사항은 밀접하게 관련되어 있으며, 요구사항이 무엇인지 어느 정도 파악하지 않고는 아키텍처를 정의할 수 없습니다. 리스크를 줄이기 위해 개발 전에 아키텍처를 정의할 필요가 있다면, 전형적인 엔터프라이즈급 애자일 프로젝트에서 선행적으로 더 많은 요구사항을 정의하는 것이 아마도 필수적일 것입니다.
  

• 요구사항은 훨씬 더 복잡할 수 있으며, 가장 적절한 솔루션과 최적의 아키텍처를 결정하고 상호의존성을 이해하기 위해 요구사항의 선행 분석이 더 필요할 수 있습니다.
  

• 요구사항 개발에 관련된 이해관계자의 수가 일반적으로 더 많습니다. 예를 들어, 지원 그룹은 여러 번 지원 가능성 요건을 결정하는 데 핵심적인 역할을 하게 될 것입니다.
  

• 대규모 엔터프라이즈급 구현에서는 요구사항 관리가 스토리 개발을 조정하여 비즈니스 요구를 충족하는 관련 기능을 만들기 위해 상호 협력할 수 있도록 하는 좀 더 통합된 접근 방식이 필요합니다.
  

• ” Functional decomposition” 라고 불리는 기법은 요구사항을 논리적 구성으로 분해하는 데 종종 사용됩니다. 기능적 분해는 요구사항이 시스템의 비즈니스 목표를 지원하는 것과 어떻게 일치하는지 이해하는 유용한 방법이기도 합니다.
  
  

5. Enterprise-level Challenges – Project Portfolio Management

소규모 애자일 프로젝트는 대규모 애자일 프로젝트의 포트폴리오 관리에 대한 전형적인 기업 요구를 충족하기 위한 상위 수준의 통합 메커니즘을 제공하지 않습니다. 일반적인 대규모 기업 수준의 환경에서는 일반적으로 어떤 형태의 전체 프로젝트 포트폴리오 관리에 대한 필요성이 훨씬 더 큽니다.

• 다수의 애자일 프로젝트를 전형적인 엔터프라이즈급 프로젝트 포트폴리오 관리 접근방식으로 통합하는 것은 매우 어려울 수 있지만, 포트폴리오 관리 결정을 위해서는 어느 정도의 통합과 관리가 필요합니다.
  

• Predictability, Control, Agility 의 필요한 균형을 제공하기 위해 여러 번 Hybrid 접근 방식을 채택해야 합니다.
  
  

6. Enterprise-level Challenges – Agile Manifesto Values

Enterprise Level 의 맥락에서 Agile Manifesto 가치와 원칙을 다소 다르게 재해석해야 하는 필요성에 초점을 맞추어 봅니다.

Agile Manifesto 의 가치와 원칙은 결코 절대적으로 받아들이라고 할 의도는 없습니다. 그들은 항상 상황의 맥락에서 재해석될 필요가 있습니다.

Agile의 중요한 가치 중의 하나는 “Individuals and interactions over processes and tools” 이지만,

• Enterprise-level 에서는 여러 팀이 필요한 대형 프로젝트의 작업을 조정 및 동기화하고 팀 외부의 다른 활동을 조정하기 위해 정의된 프로세스가 더 많이 필요합니다.
  

• 사업수행 범위와 복잡성이 증가함에 따라 Enterprise Level에서 도구가 더욱 중요해질 수 있습니다. 전체 Effort을 통합하기 위한 적절한 애자일 프로젝트 관리 도구가 없었다면 그 범위와 복잡성의 Effort을 끌어내는 것은 사실상 불가능했을 것입니다.
  

Agile의 중요한 가치 중의 또 하나는 “Working software over comprehensive documentation” 이지만,

• Enterprise-level 에서 솔루션은 훨씬 더 복잡한 경향이 있으며 소프트웨어는 전체 솔루션의 한 부분에 불과하다. 결과적으로, 전체 솔루션의 모든 구성요소를 통합하기 위해 어떤 형태의 추가적이고 전체적인 조정이 필요합니다.
  

• Enterprise Level 에서 솔루션에는 단순한 소프트웨어 개발 이상의 교육, 비즈니스 프로세스 변경, 지원 계획, 마케팅 및 roll-out 계획 및 기타 많은 요구사항이 포함될 수 있습니다. 이 모든 것들이 어떤 종류의 문서화의 필요성을 증가시킬 수 있습니다.
  

Agile의 중요한 가치 중의 또 하나는 “Responding to change over following a plan” 이지만,

• Enterprise-level 에서는 여러 팀이 필요한 대규모 프로젝트의 Effort 조정
• 개발팀 Effort 범위를 벗어난 다른 활동과 동기화
• 개발 Effort 을 보다 계획 중심적인 Higher-level Management 프로세스에 맞게 조정
  
  

7. Enterprise-level Challenges – Agile Manifesto Principles

Agile 원칙은 Change Control과 관련이 있으며, “개발이 늦더라도 요구사항의 변화를 수용한다. Agile 프로세스는 고객의 경쟁 우위를 위해 변화를 활용한다.” 이지만,

• 변경은 결과 없이 이루어질 수 없으며 변경 관리는 구성 관리 및 이전에 개발된 다른 요구사항 및 가정과 일치하는지 검증하는 데 유용할 수 있습니다.
  

• 적절하게 수행되면, 그것은 불필요한 변경은 거부되면서, 프로젝트에 필요한 변경이 유입되고 설계, 계획, 기간, 시험, 계약(등)에 필요한 조정은 최소의 리스크로 이루어 지도록 하는 것을 의미합니다.
  

또 다른 애자일 원칙은 Communication과 관련이 있으며, “개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화” 라고 말합니다. 그러나,

• 단순한 소프트웨어가 아닌 전반적인 솔루션에 초점을 맞추고 있기 때문에 Enterprise Level 에서, 팀은 일반적으로 소프트웨어를 개발하는 단순한 사람들보다 더 광범위합니다.
  

• Enterprise Level 에서 커뮤니케이션 전략은 솔루션 구현에 중요한 이해 당사자인 운영 및 지원과 같은 광범위한 인원을 포함해야 합니다.
  

또 다른 애자일 원칙은 Progress Measurement와 관련이 있으며, “Working Software는 Progress 의 일차적 척도.” 그러나,

• Enterprise Level 에서는 단순한 소프트웨어 개발보다 사용자에게 실제 비즈니스 가치 제공 측면에서 성공 또는 실패는 더 측정되어야 합니다.
  

• Progress의 주요 척도는 스폰서가 가치로 정의하는 것이어야 합니다.
  
  

Project Governance

“프로젝트 거버넌스”는 애자일 접근법과 모순되는 것처럼 들릴지 모르지만, 그렇게 생각하지 않습니다. 주어진 프로젝트와 비즈니스 환경에 적합한 적응성과 통제력을 적절히 조합하여 프로젝트 거버넌스 접근법을 만들 수 있는 경우. Enterprise Level 에서, 모든 프로젝트가 회사의 비즈니스 전략과 일치하도록 하기 위해서는 일반적으로 어떤 형태의 프로젝트 거버넌스가 필수적입니다.

Levels of Project Governance

Agile 개발 접근법은 주로 Team-Level과 Project-Level로 제한되며, 그 수준 이상을 충족해야 하는 큰 차이가 있으며, 각 Level에는 애자일 접근 방식 또는 보다 전통적인 관리 접근 방식을 선택할 수 있습니다. 이 양극단들 사이에서 실제로 하나만 선택하는 것은 아니고, Hybrid 접근을 만드는 여러 가지 방법이 있습니다.

Three Primary Project Governance Challenges

Enterprise Level 에서 프로젝트 거버넌스 접근법을 만드는 데는 세 가지 주요 목표가 있습니다.

• 첫 번째 목표는 개발 관점에서 여러 팀의 활동을 통합하는 것입니다.
• 또 다른 중요한 목표는 프로젝트 팀 외부의 다른 관련 활동과의 조정 및 경영진에게 추적 및 진행 상황 보고/제공하는 것입니다.
• 최종 목표는 모든 팀과 프로젝트의 활동을 조직의 비즈니스 목표에 맞추는 것입니다.
  
  

1. Project/Program Management

먼저 프로젝트 거버넌스 전략에서 프로젝트/프로그램 관리의 역할에 대해 살펴보겠습니다. 프로젝트/프로그램 관리는 전반적인 프로젝트 거버넌스 접근방식의 매우 중요한 구성요소입니다. Enterprise Level 에서 프로젝트/프로그램 관리에 더욱 집중해야 하는 여러 요인들이 있습니다.

• 첫 번째 요인은 다중 분산 팀 – 엔터프라이즈급 프로젝트의 규모 때문에 여러 팀이 필요할 때가 많습니다. 많은 경우, 그러한 팀들은 서로 다른 위치에 분산될 수 있으며 쉽게 공동 위치를 잡을 수 없습니다. 따라서 이러한 활동이 의도된 사업 결과의 산출과 일관되고 동기화된다는 것을 보장하기 위해 해당 팀과 팀 간에 어느 정도 수준의 조정과 커뮤니케이션이 필요할 것입니다.
  

• 또 다른 요인은 Higher-level 의 비즈니스 목표와의 통합 – 프로젝트 관리자가 Enterprise Level 에서 제공할 수 있는 주요 부가가치 원천은 회사의 비즈니스 목표와의 통합이다. Team-Level 에서는 일반적으로 해당 역할이 제품 소유자에 의해 제공되지만, Enterprise Level 에서는 프로젝트 또는 프로그램 관리자들에게 해당 기능과 관련된 작업 부하가 발생 할 수 있습니다. 경우에 따라, 프로젝트 관리자는 제품 소유자 그룹 또는 전체 프로젝트/프로그램의 운영 그룹 역할을 하는 다른 사업 이해관계자들의 참여를 이끌어 내야 합니다.
  

• 또 다른 요인은 다른 조직 및 이해관계자와의 조정 – Enterprise Level 의 솔루션이 매우 광범위한 영향을 미칠 수 있기 때문에 일반적으로 일상적인 프로젝트 팀 이외의 다른 조직 및 이해관계자와의 조정이 상당히 필요합니다.
  
  

2. Project/Portfolio Management

거버넌스 접근법 프로젝트 포트폴리오 관리는 프로젝트와 제품으로부터 기업의 투자 수익률을 적절히 조합하여 선정한 후 프로젝트의 성과를 추적·모니터링하여 수익률을 극대화하도록 설계되어야 합니다. 필요한 재무 엄격성 수준 및 기타 요인에 따라 가능한 다양한 달성 접근 방식입니다.

일부 기업은 프로젝트 및 제품으로부터의 수익을 식별하고 추적하기 위해 어떤 종류의 재무 분석을 수행할 수 있지만,

• 이러한 접근 방식은 애자일과 매우 일관되지 않음
• 불확실성 수준이 높은 환경에서는 비현실적일 수 있음

보다 애자일 접근방식은 high-level 의 비즈니스 이니셔티브를 기반으로 전략을 수립하고 프로젝트 포트폴리오 관리를 위해 보다 동적인 접근방식을 사용하는 것입니다.

각 접근방식은 통제/예측 가능성과 Agility 사이의 절충을 제공합니다.

3. Enterprise-level Business Management

마지막으로 언급하고 싶은 개념은 엔터프라이즈급 비즈니스 관리에 관한 것입니다. “Lean Startup” 개념은 전략적 비즈니스 이니셔티브의 개발과 계획에 매우 민첩한 접근법입니다. Lean Startup을 설명하는 가장 간단한 방법은 매우 역동적이고 성공적인 전반적인 비즈니스 전략을 개발하고 관리하기 위한 애자일 접근법입니다.

• “Startup” 이라는 단어는 오해의 소지가 있을 수 있다. 이 접근법은 매우 성공적이고 기업가적인 신생 기업의 본질을 포착하고 있지만, 성숙 단계에서는 어떤 규모의 기업에도 적용될 수 있습니다. 창업 단계에 있는 기업에만 국한되지 않고, 성공한 스타트업 기업의 심리를 환경에 불어넣어 더 큰 기성 기업을 회생시키는 데 활용할 수 있습니다.
  

• Lean Startup 접근 방식의 이면에 있는 아이디어는 많은 비즈니스 벤처나 신제품 출시가 시장이 원하는 것에 대한 잘못된 가정 때문에 실패한다는 것입니다. Lean Startup의 접근법은 매우 불확실한 시장에서 신제품의 사업 전략을 개발하고 검증하는 매우 효과적인 방법이 될 수 있습니다. 시장이 원하는 것이 무엇인지에 대한 가설에서 시작하여 일련의 실험을 통해 그 가설을 점진적으로 검증하고 다듬으려고 시도합니다. 시장 수용의 불확실성때문에 사업전략이 성공하는 것과 관련된 리스크가 높을 때 가장 효과적입니다.
  

• 기업들은 이러한 가정 이면의 불확실성을 인식하고 검증하는 대신, 완전히 테스트되고 검증되지 않은 일부 매우 잘못된 가정을 바탕으로 정교한 사업 전략과 값비싼 제품 개발 활동을 여러 번 만들어 냅니다. 그들은 비싼 개발 활동이 완료될 때까지 사업 전략 뒤에 숨겨진 일부 기본적인 가정들이 잘못되었다는 것을 발견하지 못하며, 그 때쯤에는 중요한 변화를 하기에 너무 늦게 됩니다.
  
  

4. Lean Startup Approach

두 가지 접근방식의 비교를 보면,

• 전통적인 제품 개발 활동에서 사업 전략 및 계획 활동과 제품 개발 활동은 일반적으로 순차적입니다. 사업전략이 완성되어 개발이 시작되면 건전한 전략이라는 가정이 있으며, 요건의 세부사항만 해결하면 됩니다.

• Lean Startup의 접근법은 시장이 원하는 것에 대한 가설로 시작하여 일련의 실험을 통해 그 가설을 점진적으로 검증하고 구체화하려고 시도합니다.

Lean Startup의 접근방식에서, 사업 전략과 계획 활동은 개발 활동과 더 동시에 이루어집니다. 개발활동이 시작되면 사업전략은 개발활동이 진행됨에 따라 시험·검증·정비가 필요한 가설로만 인식됩니다.

이번글은 여기까지 소개드리며, Enterprise 레벨에서의 Agile을 적용하는 데 있어 무엇이 다르고, 프로젝트 거버넌스가 Agile 환경에서 어떻게 적용되는지에 대해 이해하는 데 도움이 되었기를 기대해 봅니다.

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

Comming Soon ~~

이전글

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