원문: Is Kanban a Framework? by David J. Anderson

최근 스크럼에 익숙한 사람들이 스크럼과 칸반을 비교해보면서 “칸반도 역시 프레임워크야.”라거나 “칸반은 프레임워크의 대안을 제시하고 있어.”라고 이야기한다는 말을 들었다.

나는 스크럼이 프레임워크라는 것을 널리 알리고자 하는 여러 스크럼 커뮤니티의 리더들을 알고 있는데, “프레임워크(framework)”를 어떻게 정의하느냐에 달려있긴 하지만, 스크럼은 프레임워크로 보는 것이 합리적이다.

그러나 “칸반은 프레임워크다”라는 생각에는 이의를 제기하고 싶다. 칸반은 프레임워크가 아니다! 칸반은 (2004년부터 2006년까지 마이크로소프트 XIT 유지 개발 그룹에서 처음으로 사용했던 것처럼) 서비스 출시 개선의 포인트 솔루션(point solution)으로 사용할 수 있다. 또는, 조직의 점진적 변화를 촉진하고 지식 업무 서비스를 전반적으로 개선하기 위해 사용할 수도 있다. 여러분이 칸반을 애자일 방법(Agile Method)으로 포장해야 하는 상황이라면, 칸반은 서비스 출시를 변화시키고 개선하는 애자일 접근법이라고 할 수도 있다. 단언컨대, 지금으로서는 칸반이 “유일한” 애자일 변화 관리 프로세스다. 또한 애자일 커뮤니티에서 등장한 “지금 바로 시작할 수 있는” 유일한 방법이며, 칸반은 점진적 방식을 통해 현재의 업무를 개선할 수 있는 서비스 집합으로 바라보아야 한다.

“프레임워크”의 정의

다음은 “framework”에 대한 FreeDictionary.com의 정의다:

다른 것을 떠받치거나 둘러싸는 구조. 특히 구성하고자 하는 대상의 기반으로 사용하는 뼈대를 의미한다.

이 정의에 따르면, 스크럼은 프레임워크로 보는 것이 타당하다.

칸반이 프레임워크였다면 프로세스 프레임워크의 뼈대를 제공했을 것이고, 여러분은 상황에 맞도록 프로세스를 구체화하기 위해 그 뼈대를 확장하고 여러 가지를 덧붙여야 했을 것이다. 칸반은 분명 그런 방식이 아니다.

칸반의 정의

칸반은 시각적 보드와 가상 칸반 시스템을 사용해서 서비스를 점진적으로 개선하는 관리 방법이다. 칸반이라는 이름이 붙은 것은 이 방법이 칸반 시스템을 사용하기 때문이다. 칸반은 서비스 출시를 개선하는 방법을 설명하고 있으며, 이미 완벽하게 정의되어 있고, 반복해서 사용할 수 있을만큼 충분한 세부 사항도 갖추고 있다. 이 접근 방식, 즉 칸반은 소프트웨어 유지 보수 상황에서 분명하게 적용하고 시작할 수 있으며, 일반적인 소프트웨어 개발에도 사용할 수 있다. 또한 IT 운영이나 IT 서비스, 그리고 광고 에이전시나 웹 디자인, TV나 영화의 후반 작업과 같은 창조적 업무, 그 외 지식 업무 영역에서도 칸반을 활용해볼 수 있다. 모든 창조적 지식 산업에서 칸반이 서비스 출시를 개선하는 범용적인 변화 관리 방식으로 성장하리라는 믿음과 희망이 있다.

칸반에는 세 가지 기본 원칙이 있다:

아무리 형편없는 상황일지라도, 지금 바로 시작할 수 있다.
점진적 변화 방식을 지향한다.
처음에는 기존의 역할, 책임, 직함을 존중한다.

나는 칸반을 성공적으로 적용한 조직에서 다섯 가지 핵심 공통 요소를 찾아낼 수 있었다. 그 요소는 다음과 같다.

시각화 – 눈에 보이지 않는 업무와 업무 흐름을 볼 수 있도록 만든다.
WIP 제한 – 가상 칸반 시스템을 실행한다.
흐름 관리
관리 정책 명시화
협업 개선 – 모델과 과학적 방법을 사용한다.

다섯 번째 요소는 변화를 제대로 “유도”하기 위한 것이다. 칸반에서는 목표 프로세스가 돌연변이를 일으키는 경우가 없다.

나는 이 목록을 여섯 개로 늘릴 필요가 있음을 깨달았고, 그것은 점진적으로 프로세스를 발전시키는데 필요한 피드백에 대한 것이다. 여섯 번째 요소는 원래부터 존재하는 것이었고 책에서도 중요하게 다루고 있었지만, 처음에는 이 요소를 명시적으로 드러내지 않았었다. 사람들이 책에서 설명했던 피드백 루프를 실행하지 않고 있다는 것을 알게된 후 나는 그 생각을 바꾸었다. 요즘 글을 쓸 때에는 대개 이 여섯 번째 요소를 다섯 번째에 배치하곤 한다.

피드백 루프의 실행

보통 이야기하는 칸반은 목표하는 업무 흐름 프로세스와 서로 관계없이 독립적으로 존재한다. 여러분이 소프트웨어 개발을 하고 있다면, 칸반은 소프트웨어 개발 프로세스를 바탕으로 움직인다. 칸반은 프로세스의 일부가 아니다. 공정하게 말하더라도, 가상 칸반 시스템을 실행하려면 목표하는 프로세스에 변화가 필요할 것이다. 사실, 서비스 출시를 점진적으로 발전시키겠다는 아이디어에는, 변화란 기존 프로세스 위에서 일어나는 것이라는 의미를 내포하고 있다. 가상 칸반 시스템을 도입함으로써, 약속을 늦출 수 있고, 계획과 약속을 출시 리드 타임이나 예정된 출시와 분리할 수 있다. 칸반을 사용하면 애자일 방법에서 일상적인 타임 박스 배치 전달에서 벗어날 수 있다. 이 점이 엄격한 타임 박스 방식에서 별다른 도움을 얻지 못한 환경에서 매우 매력적이다.

정리

칸반은 점진적으로 서비스 출시를 개선하기 위해 만든 관리 방법이다. 소프트웨어 개발이나 프로젝트 관리 또는 IT 운영에서 사용하는 프로세스나 프레임워크가 아니다. 칸반은 변화를 촉진하는 관리 방법이지, 변화 관리에 사용하는 프레임워크가 아니다. 칸반에는 필요한 모든 것이 이미 갖추어져 있으며, 칸반에서 이야기하는 모든 요소를 담고 있다. 칸반은 “다른 무언가를 떠받치거나 둘러싸는 구조”가 아니다. 칸반은 반복 가능하고, 지속 가능하며, 탄탄하고, 회복력을 갖추고 있음이 증명되어 왔다. 칸반은 그 규모와 상관 없이 전세계 많은 업체에서 일상이 되었으며 4년 넘게 그 인기를 지속하고 있다. 칸반은 “프레임워크(framework)”가 아니라 “방법(method)”임이 분명하다.

칸반은 지식 노동자가 속해 있는 조직에서 영속적이고 효과적인 변화를 이끌어가기 위한 실용적이며 실행 가능한 조언이다. 칸반은 추상적 개념도 아니고 뼈대도 아니다. 이미 존재하는 프로세스를 점진적으로 개선하려면, 칸반을 선택하고, 칸반을 사용하고, 칸반의 도움을 받아보도록 하자.