Advanced Agile Project Management - ④

Advanced Agile Project Management - ④

이번글은 Advanced Agile/Scrum 원칙에 대한 6가지 교훈으로 Ken Rubin의 “Essential Scrum: A practical guide to the most Popular Agile Process” 라는 책의 내용을 기초로 하여 일부 내용을 요약 소개해 봅니다. 이 부분에 대해 좀 더 자세한 내용은 Ken Rubin의 책을 추천합니다.

이번 글은 특히 Advanced Scrum Principle 에 대해 소개하고자 합니다.

Advanced Scrum Principle - 6가지 영역

• Variability and Uncertainty
• Prediction and Adaptation
• Validated Learning
• Work-in-Progress
• Progress
• Performance
  
  

1. Variability and Uncertainty

1-1. Embrace Helpful Variability

• Plan-driven process는 변화를 통제하고 제한하는 것을 중심으로 프로세스를 구축합니다.
  
• Agile 프로세스는 고객의 요구에 쉽게 적응하고 변화를 수용하는 데 기초하지만, Agile 프로세스의 변경은 완전히 제한되지 않으며 변화를 관리하기 위해 여전히 현명한 접근이 필요합니다.
  
• 이 원칙의 키워드는 ‘helpful’ 입니다. 일부 변동성은 도움이 되지 않으며 더 높은 수준의 비즈니스 가치를 제공하기 위해 제품을 정제하는 데 아무런 목적이 없다면 파괴적일 수도 있습니다.
  

1-2. Employ Iterative and Incremental Development

• Agile 측면은 제품이 고객에게 제공하는 가치를 극대화하는 것이며, 때로는 동일한 설계를 여러 번 반복하여 반복적으로 접근하여 고객에게 가치를 극대화할 수 있도록 하는 것입니다. 그것은 “반복적 개발”을 의미합니다. Agile은 때때로 어떤 것을 최적의 솔루션으로 가정하기 위해 시행착오적 접근법을 필요로 합니다.
  
• Agile은 증분 개발에 기초합니다. 전체 제품을 한 번에 제작하려고 하지 않고, 각 증분 완료 후 피드백과 학습의 기회를 통해 제품을 더 작은 조각으로 분할하여 증분적으로 제작합니다. 요구사항의 우선순위를 정하고 기능을 점진적으로 제공하는 것은 많은 이점을 가지고 있습니다.
  
• 가치를 더 빨리 제공한다는 분명한 이점 외에도, 증분 개발의 또 다른 중요한 이점은 : 어느 시점에서는 프로젝트가 획득해야 할 가치를 초과하는 지점에 도달하고, 그 시점에서 개발 시간 및 비용에 있어서 절감과 함께 프로젝트를 종료하는 결정을 내릴 수 있다는 것입니다.
  

1-3. Leverage Variability Through Inspection, Adaptation, and Transparency

• 스크럼은 Inspection 과 Adaptation 을 기반으로 합니다.
  
• 구축 중인 제품은 사용자에게 제공하는 가치를 극대화하기 위해 필요에 따라 지속적으로 검사 및 조정될 뿐만 아니라, 제품 제작에 사용되는 프로세스 자체를 지속적으로 검사하여 공정이 최적으로 작동하는지 여부를 확인하고 필요에 따라 공정을 조정합니다.
  
• 당연히, 제품 및 프로세스 작동 방식에 대한 투명성 또한 이를 달성하기 위해 필요합니다.
  

1-4. Reduce All Forms of Uncertainty Simultaneously

• Final product의 기능과 관련된 불확실성을 다루는 “불확실성 종료”가 있습니다.
• 프로세스와 개발에 사용되는 기술을 둘러싼 “불확실성”도 존재합니다.
• 제품의 궁극적인 고객이 누구인지에 대한 “고객 불확실성”도 있을 수 있습니다
• Agile에서는 프로젝트가 진행됨에 따라 불확실성을 인식하고 관리하며 줄이는 것을 중심으로 구축됩니다.
  
  

2. Prediction and Adaptation

대부분의 많은 사람들은 Scrum을 프로젝트의 성격에 적응하려고 의도했을 때 매우 기계적이고 엄격하게 구현합니다. 이 영역의 5가지 원칙을 소개합니다.

2-1. Keep options open

• “옵션을 열린 상태로 유지”하는 것입니다.
  
• 계획 중심 접근방식은 프로젝트 시작 전에 프로젝트에 대한 불확실성을 해결하기 위해 요구 사항에 대한 모든 결정을 선행하는 경우가 많습니다.
  
• Scrum과 Agile은 “마지막 책임 있는 순간”까지 결정을 미루는 것에 기반을 두고 있습니다. 즉 일반적으로 프로젝트에 영향을 주지 않고 의사결정이 지연될 수 있는 한 결정을 지연시켜야 한다.
  
• 의사결정을 미루면 일반적으로 의사결정에 대한 더 나은 정보를 얻을 수 있다는 이면의 논리가 있습니다.
  
• 만약 여러분이 너무 멀리까지 미리 결정을 내리려고 한다면 그것은 종종 추측을 필요로 할 것이고 많은 경우 추측이 틀릴 것이고 그 결정은 나중에 다시 계획될 필요가 있기 때문에 노력이 낭비될 것입니다.
  

2-2. Accept That You Can’t Get it Right Up-front

• Scrum과 Agile의 중요한 원칙은 우리가 아마도 그것을 바로 잡을 수 없다는 것을 받아들이는 것이고, 최상의 해결책을 찾기 위해서는 약간의 시행착오 실험이 필요할 수도 있습니다.
  
• 이를 위해서는 “모르는 것을 알지 못한다”는 것을 인식하는 성숙한 자세가 필요합니다.
  

2-3. Favor an Adaptive, Exploratory Approach

• 실험과 실험의 결과에 적응하는 비용, 제품을 선행 설계하는 비용, 그리고 잘못된 경우 주요한 재작업과 재설계의 위험을 평가하는 것과 관련된 경제적 결정이 있습니다.
  
• 1990년대에는 변경 비용이 상당히 높았는데, 이는 계획 중심 접근법을 개발하게 된 이유 중 하나입니다. 그러나 툴과 기술은 그 시간 이후로 훨씬 좋아졌고 탐색적 개발 비용은 크게 낮아졌습니다.
  
• Agile 환경에서 잘 알려진 설명은 “조기 실패, 자주 실패”입니다. 다시 말해서, 어떤 것을 시도해 보고 무엇이 효과가 있는지 보는 것이 더 낫다는 것입니다.
  

2-4. Embrace Change in an Economically Sensible Way

• Agile과 스크럼은 변화 프로젝트에 미치는 경제적 영향을 최소화할 수 있는 변화를 관리하는 합리적인 방법을 제공합니다.
  
• 기존의 계획 중심 접근방식을 사용하면 그 영향이 클 수 있기 때문에 프로젝트 후반부에 변경 비용이 크게 증가할 수 있습니다.
  
• 개발에 대한 점진적인 접근 방식을 사용하여 Agile 프로젝트에서 변화의 영향은 프로젝트 전체에 걸쳐 변경 비용이 상대적으로 저렴할 수 있으며 제한적일 수 있습니다.
  
• 분명히, 솔루션의 최적화를 시도하기 위해 변경 사항 외에도 변경을 하는 것은 매우 가능하지만, 어느 시점에서는 수익이 감소하는 지점이 있을 가능성이 있으며 솔루션을 더욱 최적화하기 위해 계속 변경하는 것은 경제적인 이치에 맞지 않습니다.
  

2-5. Balance Predictive Up-front Work with Adaptive, Just-in-time Work

• 어떤 프로젝트에서든 미리 알려지거나 쉽게 알 수 있는 일정량의 정보가 항상 존재하며, 어떤 정보는 미리 결정하기가 훨씬 더 어려울 수 있습니다.
  
• 사전에 알려진 것을 이용하지 않고 무시하는 것은 어리석은 일일 것입니다.
  
• 합리적인 접근방식은 프로젝트의 성격에 근거한 불확실성을 해결하기 위해 예측적 선행 접근방식과 적응적 적시 접근방식의 균형을 맞추는 것입니다.
  
  

3. Validated Learning

Agile은 어떤 것을 시도하고 어떤 것이 작용하는지 보기 위해 경험적이고 실험적인 접근에 크게 기반을 두고 있습니다. 그러한 접근방식이 효과를 거두기 위해서는, 우리가 모든 답을 가지고 있지 않다는 것을 인식하는 것이 중요합니다. 우리는 몇 가지 가정을 할 수 있지만, 그러한 가정들은 단지 가정일 뿐이고 검증되어야 한다는 것을 인식하는 것이 중요합니다.

켄 루빈은 이 분야에서 세 가지 핵심 원칙을 제시하고 있습니다.

3-1. Validate Important Assumptions Fast

• 프로젝트의 여러 영역에 중대한 영향을 미칠 수 있는 특정 가정이나 결정이 있다면, 그러한 영역을 식별하고 가능한 빨리 해결하여 그 영향을 최소화하는 것이 타당합니다.
  
• 이 영역에서 좋은 방법은 필요한 경우 중요한 가정과 관련된 불확실성을 해결하기 위해 “ Spike “를 사용하는 것입니다.
  

3-2. Leverage Multiple Concurrent Learning Loops

• Scrum 프로젝트에는 서로 다른 수준에서 작동하는 여러 개의 동시 학습 루프가 있으며, 이러한 모든 다른 레벨을 동시에 활용하는 것이 가장 좋습니다.
  
• 예를 들어, Daily Scrum Meeting에서 이루어지는 학습 수준과 스프린트 리뷰 및 스프린트 회고전의 각 스프린트 종료 시 발생하는 학습 Level 도 있습니다. 우리는 이 모든 학문의 소스를 이용해야 합니다.
  
• 이것은 크고 복잡한 프로젝트에서 특히 중요할 수 있습니다. 예를 들면, Hybrid Agile 프로젝트에서는 프로젝트 Level 에서의 프로젝트 완료에 필요한 시간과 비용에 대해 몇 가지 가정을 할 수 있지만, 좀 더 세부적인 Level 에서 일부 기능성과 관련된 요구사항은 예상보다 훨씬 많은 노력을 필요로 한다는 것을 알게 될 수 있습니다. 이러한 학습은 전체 프로젝트 Level 계획에 미치는 영향을 평가하기 위해 프로젝트 Level 로 피드백 될 필요가 있습니다.

3-3. Organize Workflow for Fast Feedback

• 불확실성을 해결하고 가정을 검증하는 데 피드백이 가장 중요한 항목에 대해 가능한 한 신속하게 피드백을 받을 수 있도록 프로젝트의 워크플로우를 구성해야 합니다.
  
• 좋은 예로는 개발 및 테스트와 관련된 워크플로우가 있습니다. 개발과 동시에 가능한 한 테스트 노력을 기울이면 개발자에게 프로젝트에 미치는 영향을 최소화하기 위해 가능한 한 빨리 이러한 결함을 시정하기 위해 발견될 수 있는 모든 결함에 대한 빠른 피드백을 제공할 것입니다.
  
  

4. Work in Progress (WIP)

4-1. Use Economically Sensible Batch Sizes

• 전통적인 계획 중심 개발 프로세스는 제조 환경에서 발생하는 규모의 경제 원리에 기초해 왔습니다. 제조 환경에서는 비용을 줄이기 위해 대형 일괄처리 크기에 대해 반복적인 제조 작업을 수행하는 것이 타당할 수 있습니다.
  
• 그러나 Agile 제품 개발 프로세스에서 더 작은 일괄처리 크기를 사용하는 것은 여러 가지 이점을 가지고 있습니다.
  
• 대규모 일괄처리 크기가 심각한 병목 현상을 유발하고 전체적인 흐름을 감소시킬 수 있는 경우 작업을 보다 균등하게 분배하고 프로세스를 통한 흐름을 극대화합니다.
  
• 주기 시간이 빨라지면 피드백이 빨라져 학습 및 적응 시간이 빨라집니다.
  
• 어떤 문제의 영향도 작은 일괄처리로 제한되기 때문에 위험도는 감소합니다.
  
• 매우 중요한 점은 제품 개발 프로세스와 관련된 규모의 경제가 매우 다르고 소규모 일괄처리 크기가 그러한 환경에서 더 효율적인 경향이 있다는 것입니다.

4-2. Recognize Inventory and Manage it for Good Flow

• 제조 공장은 대량의 재고 운반에 따른 비용과 영향을 매우 잘 알고 있습니다.
  
• 소프트웨어 개발 프로세스에서 “인벤토리”는 눈에 잘 띄지 않으며 “인벤토리”를 운반할 때의 영향을 잘 이해하지 못합니다.
  
• 제품 개발 프로세스의 “인벤토리”는 요구사항, 코드 등 다양한 종류의 작업 항목으로 구성되어 있습니다. 이러한 “인벤토리” 항목의 관리와 관련된 비용 및 일정량의 오버헤드는 항상 존재하므로 전체 프로세스를 보다 효율적으로 만들기 위해 가능한 한 소규모의 프로세스 인벤토리로 작업하는 것이 최선입니다.

4-3. Focus on Idle Work, Not Idle Workers

• 프로젝트에서 인식해야 하는 두 가지 종류의 낭비 요소가 있습니다.
  
• 하나는 “유휴 노동자 낭비”로, 노동자들이 100%의 용량으로 충분히 활용되지 못하고 있습니다. 그리고 용량의 일부 구성요소는 더 잘 활용될 수 있도록 사용되지 않고 낭비되고 있습니다.
  
• 다른 하나는 “유휴 작업 낭비”로, 사람들이 작업을 할 수 있을 때까지 그 자체로 작업이 유휴 상태로 유지되는 경우입니다.
  
• 이 두 가지 형태의 낭비 요소는 모두 중요하지만, 전통적인 계획 주도형 프로젝트는 전형적으로 “유휴 근로자 낭비”에 매우 집중되어 프로젝트의 모든 사람이 100%의 용량으로 작업하도록 노력합니다.
  
• Agile 프로젝트에서는 이러한 두 가지 형태의 낭비 요소가 모두 중요하고 “유휴 작업 낭비”가 중요하다는 것을 인식합니다. 만약 여러분이 그 과정을 통해 일의 흐름을 최적화하고 싶다면 적어도 똑같이 중요합니다.

4-4. Consider Cost of Delay

• 자원이 확보될 때까지 대기하는 프로젝트가 지연될 경우, 프로젝트의 모든 사람이 일정 기간 지연될 수 있기 때문에 프로젝트 비용에 미치는 영향이 상당할 수 있습니다.
  
• 루빈이 제시한 예는 프로젝트가 끝날 때까지 문서 완료를 연기하면 전체 프로젝트가 2~3개월 지연될 수 있으며, 그 지연에 상당한 비용이 소요될 수 있다는 것입니다.
  
  

5. Progress

5-1. Adapt to Real-time Information and Re-plan

• 기존 프로젝트는 계획이 잘못될 수 있다는 사실을 간과할 수 있는 계획에 따라 수행됩니다.
  
• Agile/스크럼 프로젝트는 훨씬 더 적응적이며 프로젝트가 진행됨에 따라 개발되는 새로운 학습과 정보를 기반으로 계획을 지속적으로 수정한다는 가정에 기초합니다.
  
• 이 영역에서 프로젝트를 지속적으로 계획하는 데 필요한 실시간 정보를 제공하기 위해 활용 도구가 필수적일 수 있습니다.

5-2. Measure progress by validating working assets

• 전통적인 프로젝트는 종종 프로젝트 완료에 필요한 작업의 완료를 추정하여 진행률을 측정한다. 그것은 전형적으로 매우 부정확한 매우 주관적인 판단에 근거합니다.
  
• 기존 프로젝트도 진행 상황 평가에 충분히 고려되지 않은 진행에 대한 몇 가지 주요 위험이 있습니다. 예를 들어 작업이 완료될 수 있지만 고객이 테스트하고 수락하지 않을 경우 작업이 실제로 완료되었는가?
  
• 진행률을 측정하는 훨씬 더 좋은 방법은 구축되는 동안 고객이 검증하고 수용한 완성된 작업 자산을 측정하는 것입니다.

5-3. Focus on Value-centric Delivery

• 기존의 계획 중심 프로젝트는 프로젝트 종료 시 모든 기능의 최종 통합 및 제공에 초점을 맞춥니다. 이러한 접근방식으로, 고객에게 중요한 가치를 모두 전달하기 전에 프로젝트 시간과 비용이 부족해질 위험이 있습니다.
  
• 또한, 우리 모두는 전통적인 계획 주도형 프로젝트들이 부풀려지거나 또는 “gold-plated”으로 특징의 몇 퍼센트가 실제로 필수적이지 않다는 것을 알고 있습니다. 이것은 종종 고객이 요구조건에 그들이 원하는 어떤 아이템을 미리 얻지 못한다면, 그들은 그것을 전혀 얻지 못할 수도 있다는 고객의 믿음에서 비롯됩니다.
  
• 가치에 따라 제공될 기능의 우선순위를 정하고, 그 기능을 점진적으로 개발 및 제공함으로써, 우리는 일반적으로 기존의 계획 중심 프로젝트에서 발생하는 “All or Nothing” 접근 방식을 피할 수 있으며, 적어도 고객에게 가장 중요한 가치를 제공할 수 있습니다.
  
• 가치의 일부분이 전달된 후, 고객은 자신의 필수적 요구가 충족되고, 나머지 기능 완료와 관련된 수익이 감소할 수 있으며, 프로젝트의 나머지 부분을 완료할 필요가 없을 수 있다고 생각하는 많은 상황이 있었습니다. 이로 인해 개발 비용이 상당히 절감될 수 있습니다.
  
  

6. Performance

6-1. Go fast but never hurry

• Agile 프로젝트는 민첩하고, 적응력이 뛰어나며, 신속함을 기반으로 하지만 너무 빨리 진행하려고 하면 역효과를 낼 수 있습니다.
  
• 일을 빨리 끝내기 위해 너무 서두르는 것은 최선의 방법이 아닐 수도 있고 프로젝트를 진행하는 팀원들을 burning out 시키고 심지어 제품의 질을 떨어뜨리는 것과 같은 바람직하지 않은 부작용을 일으킬 수도 있습니다.

6-2. Build in Quality

• 전통적인 계획 중심 프로젝트에서는 일반적으로 순차적으로 테스트를 수행하고, 품질에 대한 접근은 어느 정도 사후 대응적이며 개발이 완료된 후 결함을 찾아 수정하는 데 초점을 맞춥니다. Agile은 TQM(Total Quality Management)의 원리에 크게 기반을 두고 있는데, 이 원리는 나중에 결함을 찾아 고치기 보다는 선제적으로 결함을 제거하는 보다 사전 예방적인 프로세스를 강조합니다.
  
• 제조 환경에서는 오래 전에 교훈을 얻었는데… 수년 전에는 제조 조립 라인 끝에 제품을 검사하고 결함이 있는 제품을 불합격시키는 품질 관리 검사관이 많았다고 합니다. 그것은 폐기 또는 재작업해야 하는 제품과 검사 비용뿐만 아니라 제품 생산에 주기 시간을 연장하는 측면에서 비용이 많이 드는 과정이었습니다.
  
• 이 과정에서 상류로 올라가 결함이 없는 제품을 생산하는데 있어서 본질적으로 신뢰할 수 있는 공정을 설계함으로써, 기업들은 품질 검사원들의 비용을 현저히 낮출 수 있었고, 품질도 훨씬 우수하고 신뢰도도 높은 제품을 생산할 수 있었습니다. 그리고, 물론, 처음으로 품질로 제품을 제작함으로써 그것을 올바르게 하는 것은 또한 제품 제작을 위한 주기 시간을 단축시켰습니다.

6-3. Employ Minimally Sufficient Ceremony

• 기존의 계획 주도형 프로젝트는 상위 Level 수준의 Ceremony 이고, 문서 중심적이며 프로세스 중심적인 접근 방식을 채택하는 경향이 있습니다.
  
• 스크럼과 Agile(Altile)은 프로젝트에 가치를 부여하는 항목으로만 가능한 한 Ceremony 하고, 최소한의 문서화 및 프로세스를 사용합니다.
  
• 좋은 예로는 문서화… Agile 프로젝트에서 어떠한 문서도 작성하지 않는다는 잘못된 일반적인 인식이 있습니다. 그렇지는 않지만 문서 자체가 최종적인 것이 되어서는 안됩니다. 우리는 문서가 중요한 목적에 부합하고 어떤 방식으로든 가치를 제공하는 경우, 프로젝트에 포함되어야 하지만 문서를 단순화하여 의도한 목적을 보다 효율적으로 충족시킬 수 있는 방법은 많습니다.
  
• 예를 들어, 기능 집합을 정의하기 위해 상세한 기능 사양을 작성하는 대신, 간단한 사용자 스토리를 만들 수 있고 매우 간결한 Acceptance 테스트를 사용자 스토리와 함께 정의하여 스토리가 충족해야 하는 요건을 더 잘 정의할 수 있습니다.
  

Advanced Scrum Principle 6개 영역에 대해 이해하는 데 도움이 되었기를 기대해 봅니다. 다음 편을 기대해 주세요.

Comming Soon ~~

이전글

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