스크럼반Scrumban이라는 이름의 특정한 새로운 방법론이 있는 것은 아니다.

많은 사람들이 자신의 업무에 스크럼과 칸반의 장점을 모두 활용할 수 없을지 고민하면서 다양한 시도를 하는 것은 자연스러운 현상이라고 할 수 있다. 2000년대 후반부터 이런 움직임이 나타나기 시작했고, 이 부분에 대해서는 스크럼반이라는 이름을 최초로 사용했던 코리 라다스의 글에서 엿볼 수 있다.

그러나, 스크럼반이 단일 지식 체계이거나 방법론이 아니고 실험을 시도하는 사람들이 저마다 다르게 접근하다보니 그 용어에 약간의 혼란이 있는 것도 사실이다. 이번 기회에 칸반 진영에서는 스크럼반을 어떻게 바라보고 있고, 스크럼 진영에서는 스크럼반을 어떻게 생각하고 있는지 정리해보는 것도 재미있을 것 같다.

칸반 진영에서 바라보는 스크럼반

칸반 진영에서 바라보는 스크럼반은 다음과 같이 정의할 수 있다.

이미 스크럼을 실천하고 있는 팀에서 칸반 변화 관리 원칙에 따라 칸반을 점진적으로 도입하면서 자신들의 일하는 방식을 조금씩 “칸반화kanbanize“하는 과정. 그 과정에서 필연적으로 스크럼의 규칙은 서서히 깨지게 된다.

이러한 과정을 가장 극적으로 보여주는 사례가 포지트 사이언스의 사례일 것이다. 포지트 사이언스는 의료용 소프트웨어를 개발하던 회사인데, 출시 전 단계에서는 효과적이었던 스크럼이 제품을 시장에 출시한 후에는 더 이상 효과를 발휘하지 못하자, 조금씩 칸반의 요소를 도입해가면서 궁극적으로는 칸반으로의 전환을 성공적으로 이루었다.

이 사례 연구는 칸반 유니버시트 웹사이트에서 다운로드 받아 읽어볼 수 있으며, 칸반 전문가 워크숍 II에서도 비중있게 다룬다.

요약하자면, 칸반 진영에서는 스크럼반을 스크럼에서 칸반으로 바꿔나가는 점진적인 과정 그 자체를 스크럼반이라고 부른다.

스크럼 진영에서 바라보는 스크럼반

반면에 스크럼 진영에서 바라보는 스크럼반은 다음과 같다.

스크럼 프레임워크의 규칙을 존중하고 핵심 프로세스를 그대로 유지하면서 거기에 일부 칸반의 실천법들을 적용하여, 스크럼의 검토 및 조정을 효과적으로 돕는 것이다.

양 진영의 관점에서 가장 중요한 차이점은 스크럼 가이드에서 정의하고 있는 규칙을 지키느냐 그렇지 않느냐인 것 같다.

스크럼팀에서 칸반의 요소를 자신들의 일하는 방식에 도입할 때에는 다음 네 가지 실천법이 중심이 된다.

  1. 업무흐름의 시각화
  2. WIP 제한
  3. 진행중 업무 항목에 대한 적극적 관리
  4. 업무흐름 정의에 대한 검토 및 조정

Scrum.org 웹사이트에서 “스크럼 팀을 위한 칸반 가이드The Guide for Scrum Teams“를 다운로드 받아 살펴보면 더 자세한 내용을 살펴볼 수 있다. 이 가이드를 작성한 대니얼 베이컨티Daniel Vacanti와 유발 예레트Yuval Yeret는 스크럼 전문가이기도 하면서, 칸반 커뮤니티 내에서도 오랫동안 널리 알려져있던 인물들이기 때문에 충분히 신빙성 있고 그 의견을 존중할만 하다.

양쪽에서 바라보는 스크럼반에는 다소 차이가 있고, 앞으로도 이런 차이가 좁혀질 것 같지는 않지만 (그러니까 여전히 사람들은 스크럼반의 정의에 대해 혼란스러워 하겠지만) 사실 그 결론은 비교적 명확하다. 어떤 방식으로든 스크럼과 칸반 양쪽 모두의 장점을 취하고자 하는 노력이 스크럼반인 것이다.

내가 지금까지 코칭을 해왔던 거의 모든 팀에서는 시간이 흐르면서 점차 스크럼의 요소와 칸반의 요소를 모두 적용하는 모습으로 진화하는 경향이 있었다. 그 속도나 비율은 물론 팀의 성격마다 다를 수 있다.