Kanban vs Scrum: 왜 Flow가 Real Delivery를 위한 Theater보다 뛰어난가

Source: Dev.to

Introduction

현재 시각은 오전 9시 47분. 여러분 팀은 스토리의 난이도가 5인지 8인지 논쟁 중이다. 40분이 지났다. 아직 아무것도 배포되지 않았다.

이것이 바로 스크럼 극장—대부분의 조직이 이렇게 하고 있다.

Scrum theater

스크럼 극장은 의식(ceremonies)이 진행되고, 산출물(artifacts)이 만들어지며, 역할(roles)이 존재하지만, 가치 있는 소프트웨어의 지속적인 전달은 이루어지지 않는 상황을 말한다.

• 데일리 스탠드‑업은 Jira 낭송이 된다.
• 스프린트 계획은 아무도 믿지 않는 추정치를 만든다.
• 번다운 차트는 옆으로 가다가 마법처럼 10일 차에 완성된다.

Why Scrum can become corrupted

• Time‑boxing은 전달 압박 없이 인위적인 압박만 만든다.
• Estimation rituals은 정확성보다 게임을 장려한다.
• Velocity는 Goodhart’s Law가 작동하는 사례가 된다.

Kanban fundamentals

필수 요소는 세 가지다:

1. 작업 시각화
2. WIP 제한
3. 흐름 최적화

의식은 필요 없고, 정해진 역할도 없다.

Work‑in‑Progress (WIP) limits

WIP 제한은 흐름 문제를 고통스럽고 눈에 띄게 만드는 강제 기능을 제공한다. “In Review” 열이 제한에 도달하면 코드 리뷰는 즉시 모두의 문제가 된다—스프린트 종료 시가 아니라 바로 지금이다.

Metrics

• Velocity는 끔찍한 예측 지표다—스토리 포인트는 추정되고, 게임화되며, 일관성이 없기 때문이다.
• Cycle time와 throughput은 실제 완료된 작업을 기준으로 측정한다.

성숙한 칸반 팀은 이렇게 말할 수 있다:

“우리의 과거 처리량을 기준으로 보면, 이 기능 세트가 3월 15일까지 완료될 확률은 85 %입니다.”

이는 “스프린트 12에 커밋했다”는 말보다 더 정직하다.

Transition steps

1. 현재 상태를 시각화하기 – 실제 워크플로우를 매핑하고, 진행 중인 모든 작업을 시각화하며, 사이클 타임을 측정한다.
2. WIP 제한 도입 – 처음엔 느슨하게 시작하고, 흐름이 개선될수록 제한을 강화한다.
3. 스프린트 경계와 분리 – 커밋 대신 큐 보충으로 대체한다.
4. 극장(의식) 없애기 – 전달에 도움이 되지 않는 의식을 제거한다.

Conclusion

“칸반 vs 스크럼?”이 아니라 “우리가 실제로 최적화하려는 것은 무엇인가?”이다.

대부분의 팀은 프레임워크 문제가 아니라, 프레임워크가 가리고 있는 전달 문제를 가지고 있다.

Originally published at agilelie.com.