2018 M02 23

왜 애자일은 동작하지 않을까?(Why Isn’t Agile Working?)

몇장의 그림들...


몇해 전 친척집을 방문 했을 때 였습니다. 안타까운 내 사촌 (보험회사 CEO) 은 Agile Silver Bullet ™ 사의 제품을 판매한 뒤 매우 화를 내며 말했습니다:
이건 완전 사기야! 우리는 모든 방식을 변경했어. 컨설턴트에게 자문도 구했고 마스터 프로젝트 메니져도 고용했어. 하지만 아무 소용 없었어! 어떤 차이도 없었고, 그 누구도 책임지지 않았어. 모두가 변명뿐이였어.
그때 어떤 대답을 했는지 기억 나지 않지만 오늘은 내가 어떻게 대답해야할지 알것 같습니다. 이를 위해 몇장의 그림을 그릴 것이고 심지어 애자일(agile) 은 언급하지 않을 것입니다. 먼저 원활한 소통을 위해 몇가지 핵심 개념이 필요할 것 같습니다...

1. 유동 효율 (Flow Efficiency)

첫째, 아이디어를 생각해낸 시점부터 - 고객에게 도달할때까지 리드 타임 (lead time) 을 살펴보면 - 대부분 "기다리는 (waiting)" 시간임을 알수 있습니다. 보통 유동 효율 (작업 시간 / 리드 타임)이 15% 라면 정상이라고 합니다. 어이가 없죠? 실제로 일한 시간은 적은데 말이죠. 최고의 회사들은 40% 유동 효율 을 기록했습니다. 정리하자면, 고객에게 더 빨리 도달하기 위해서는 대기 시간을 효율적으로 다뤄야 합니다.

presentation

2. 계획되지 않은 일 과 멀티태스킹 (Unplanned Work and Multitasking)

계획되지 않은 일(unplanned work)과 업무 변경 (task switching)을 결합한 팀이 75%의 "이자(interest)" 를 지불하는 것은 드문일이 아닙니다. 심지어 이러한 팀은 그 원칙에 대한 지불을 안하고 있을지 모릅니다. 이는 그야말로 오버헤드(overhead) 이며, 종종 티케팅 시스템 (ticketing system 또는 issue tracking system) 에서도 추적되지 않습니다. 위와 같은 상황과 가장 관련이 높은 팀은 이러한 원칙에 불만이 많죠. (끔직한 상황입니다.) 만약 이를 오랜동안 무시한다면, 그들은 더욱 심각한 상황을 마주할 것 입니다.
예를들어 원칙에 불만이 많은 팀이 "공유 서비스"를 제공하고 이들은 생산 문제를 해결하거나 새로운 인프라를 프로비저닝하는 동시에 "프로젝트 (projects)"를 수행 할 책임이 있다고 가정합시다. 이런 상황은 언제든 병목현상 (bottleneck) 을 초래합니다.
렛슨(Lesson): 계획되지 않은 일과, 공유 서비스가 가져올 경제적 효과를 정량화 해야 합니다. 공유 서비스는 직관적이지만, 종종 큰 비용이 드는 사전 계획에 영향이 있기 때문입니다.

presentation

3. S, M, 그리고 L

아래 그림은 웃긴 트릭(trick) 이에요. 먼저 큰 항목, 중간 항목, 작은 항목의 완료 시간을 계획하고 레벨을 높혀 실제 고객 가치 (작업 제외) 항목에 집중합니다. 대부분의 조직은 작업의 "크기(size)" 가 완료 시간 과 아무런 관련이 없는 것을 확인할 수 있습니다. 왜일까요? 그 이유는 작업 완료 시간에 미치는 영향들이 너무 많기때문입니다. (예: 종속성, 계획되지 않은 작업, 진행 중인 작업이 많음. 기타 등등...)

presentation

4. 이익 실현 (Benefits Realization)

저는 이른바 "전달 위험 (delivery risk)" 을 줄이기 위해 많은 노력을 해왔습니다. 이는 당신이 사용자 정의 프로젝트를 제공하고 고객이 대금 상환 (cach-and-delivery) 지불을 하는 경우 의미가 있습니다. 하지만 SaaS (software as a service)는 업무 진행 시 돈을 받지 않습니다. 수익은 시간이 지남에 따라 발생합니다. 저는 이것을 "수익 위험 (benefits risk)" 이라고 합니다. (이 일은 실패할 위험이 있습니다.)
대기업은 애자일 선택이 일반적이지만 재정적인 이점은 없는 것으로 보입니다. 왜일까요? 개발이 더 빠르긴 하지만 1) 올바른 의사결정을 내려야하고 그다음 2) 이윤을 내기위해 노력하기 때문입니다. 애자일의 가장 큰 포인트 (Whole POINT) 는 위험(risk)을 줄이는 것 입니다. 프로젝트업무 중 이러한 위험(risk)은 "정확히 (on time) / 범위 내(within scope)" 이며 제품 생산에서 위험은 "심각할정도로 정상동작 안함" (“this thing doesn’t ****ing work”)을 의미합니다. 이는 PO 를 "수락하는(accepting)" 기능의 전체적인 오류이며 어떠한 이득도 없습니다.
대부분의 회사들은 아래 그림의 왼쪽 모델을 채택합니다. 오른쪽 모델을 채택하는 곳은 거의 없습니다. 하지만 결과가 좋지 않을때는 더 많은 일들을 끼워 넣으면서 결국 불행한 결과를 가져 오게 됩니다.

presentation

5. 관리되지않는 복잡성 (Unmanaged Complexity)

마지막으로, 잘 알려진 기능을 제품 개발 시스템에 전달 하세요. 또한 복잡성/리팩토링/자동화 에 대한 관리가 없다면 이 기능을 완성하는데 더 오랜 시간이 걸릴 것입니다. 그렇지 않다면 당신의 팀이 똑같이 유지된다고 해도 3일에서 6주까지 늘어나는 것은 시간문제입니다.

presentation

Agile

애자일은 지속적인 개선 노력을 하지 않는 다면 아무런 가치가 없습니다. 또한 스크럼 (Scrum) 과 SAFe 을 지속적인 발전을 위한 기폭제 역할을 못한다면 이는 아무 쓸모없는 것들입니다. 왜나고요? 속도가 느려지는 이유는 스프린팅 (sprinting), 사용자 스토리 작성, 격주로 진행되는 데모 중 일부에 의한 것이니까요. 나는 이러한것들이 상대적으로 중요하지 않다고 봅니다. (일단 위험을 점진적으로 낮추자는 생각을 하면 됩니다.)
애자일을 유지하려면 다음과 같은 많은 노력이 필요합니다:
  • 실제로 중요한 일 (이득(benefits)) 을 해야합니다.
  • 자동화, 툴링, 배포 파이프라인, 기능 플래그 등 (Devops)
  • 매니지먼트 문화 변화
  • 펀드(fund) 모금 방법 조정. 미션(mission) 기반 펀딩(funding) 또는 펀딩 프로젝트 전환
  • 복잡성을 관리하기 위한 리소스 할당 (규칙적인 리팩토링 및 설계변경)
  • 가치 흐름 분석 (mapping value streams) 및 당신의 비지니스를 서비스 생태계에서 다루는 것
  • 공유 서비스에 대한 새로운 관점
문제해결을 위한 특효약 (silver bullet) 은 없습니다. 당신은 일만하면 됩니다. 다른 말을 하는 사람들은 조심하세요.


이글은 번역글입니다.
원문은 아래를 참고 바랍니다.