#4. 개발 문화(2) : 칸반 이야기
칸반 방법론
2010년 8월 데이비드 J. 앤더슨(David J.Anderson)은 도요타 생산 방식의 서브 시스템인 칸반 생산 방식과 제약 이론 (TOC:Theory of constraints)의 당김 방식(Pulling system)을 착안해 [칸반:지속적 개선을 추구하는 소프트웨어 개발 Successful evolutionary change for your technology business]이라는 서적을 출판하면서 알려지게 됩니다.
칸반이란 일본어로 간판이란 뜻입니다.
간단하게 풀어보자면, 각 프로세스마다 각 이슈를 표시해 전 프로세스 또는 다음 프로세스와의 연속적인 흐름을 유기적으로, 그리고 시각적으로 만들어 전체 프로세스를 유연하게 만들고자 하는 방법론입니다.
여기서 이슈가 간판을 의미하며, 카드(card)라도고 부릅니다.
출처 : http://www.devmedia.com.br/scrum-e-planning-poker-analise-de-estimativa-de-software/31019위의 그림처럼 to-do, dev, test로 표시된 행을 수영 레인(swimlane)으로 불리며, 각 프로세스를 나타냅니다. 각 수영 레인에 표시되어 있는 숫자는 WIP(Work In Process)로 불리며, 각 프로세스마다 동시에 진행할 수 있는 이슈의 제한 수를 의미합니다. 알파벳으로 되어 있는 이슈(또는 카드)들은 왼쪽에서 오른쪽으로 연속적으로 진행하게 되며, 해당 이슈에는 담당하게 되는 멤버나, 해당 이슈의 작업 일수(또는 시간)등을 표시하여 좀 더 구체적으로 표현할 수 있습니다.
해당 칸반 보드를 통해 한 프로젝트에서 관리되는 모든 이슈를 한 번에 확인할 수 있으며, WIP을 통해 개발 프로세스에 병목현상이나 지나친 업무 쏠림을 방지할 수 있습니다. 또한 각 프로세스에 위치한 이슈들을 확인함으로써 전 단계, 또는 다음 단계에 대한 유기적인 흐름까지 파악할 수 있습니다.
기본적으로 소프트웨어 개발론에서의 칸반은 해당 프로젝트에 참여한 모든 멤버가 알 수 있도록 시각화하는 것이 가장 큰 목표입니다만, 아래의 핵심 요소가 포함되어야 비로소 완성이 된다고 할 수 있습니다.
시각화
WIP을 통한 제한
흐름의 관리
정책의 명시화
피드백 루프 실행
모든 멤버의 참여로 인한 개선, 실험
좀 더 자세한 내용은 인터넷 검색으로도 쉽게 찾을 수 있으며, 서점에도 많은 책들이 있으니 참고하시면 되겠습니다. 단지 글의 이해를 위해 먼저 간단하게 설명했습니다. 부족한 부분이 있다면 양해 부탁드리겠습니다.
저는
국내 개발팀 리딩을 했던 시절 가장 큰 실패를 했던 두 가지가 있습니다.
하나는 개발팀에 애자일과 칸반의 도입이었으며, 다른 한 가지는 회의 문화였습니다.
꼬꼬마 개발자 시절 당시, 풀리지 않은 알고리즘보다 더 고통스러웠던 기억은 의미 없이 반복되는 폭포수 개발 방식이나, 밑도 끝도 없이 이어지는 결론 없는 회의들이었거든요.
며칠 동안 고민해서 해결한 기능 구현은, 하루아침에 기획단에서 번복이 되어 무의미한 기능이 되어버리는 경우도 많았고, 개발에 집중해야 할 시간에 회의에 불려 나가 2~3시간을 멍하니 앉아있다가 대답만 한 경우도 많았습니다. 기능이 번복되어 다시 개발한다고 해서 그동안 사용한 기간은 번복되지 않았으며, 하루에도 2~3시간짜리 회의에 두세 번씩 불려 나가 업무시간을 다 할애했다고 해도, 그날의 개발 시간이 다음날로 미뤄지는 것도 아니었기에 부담은 고스란히 개발자에게 당연스럽게 넘어와 야근, 철야로 이어졌습니다.
당연히 진정한 개발 업무는 퇴근시간인 6~7시부터 시작되었고 그날 해결하고 새벽에 퇴근을 해도 다음날 아침에 오면 기능은 다시 번복이 되어있고, 그 번복에 대한 회의에 끌려가 대책을 세우는 무한 반복의 날을 보냈던 적이 있기에 오랫동안 갈망해 왔던 부분 중에 하나가 애자일/칸반, 그리고 회의 문화 개선이었습니다.
꿈과 희망으로 가득 찼던 동기가 퇴색되어 내던져 버리다.
5년 전부터 시도, 실패, 시도, 실패를 무한 반복하면서 적어왔던 마인드 맵에는 실패의 원인을 이렇게 적어놓았습니다.
실패 요인
애자일/칸반 도입을 위해 팀원들과 공유해야 했던 지식들이 너무 적었다.
팀원들은 왜 애자일/칸반을 사용해야 하는지 이해하지 못했다.
개발팀 이외의 타부서에서는 프로젝트 관리 툴(당시 레드 마인, JIRA, Trello)을 사용하기를 꺼려했다.(메일이나 네이트온 또는 카톡으로 하면 되는걸 왜 이걸 써야 해?)
모든 팀원들이 한눈에 해당 프로젝트의 현황을 알리기 위해 화이트보드에 붙여놨던 카드들은 언젠가부터 팀원 공유가 아닌 팀장을 위한 보고나 사장에게 보이기 위한 카드로 변질되기 시작한다. (Done에 모인 내 카드가 이만큼이나 모였어. 어때? 나 쩔지?)
매일 하는 칸반 회의나 1주 또는 2주에 한 번씩 하는 스프린트 회의를 귀찮아 하기 시작한다.
개선의 의지에만 너무 힘쓴 나머지 경험보다는 닥치는 대로 읽어버린 애자일/칸반 관련 책들이나 회의 개선에 대한 글들에 기대어버린 나머지 현실에 대한 타협점을 찾지 못했다는 게 가장 큰 실패에 요인이었다고 생각을 합니다. 하지만, 가장 큰 실패의 요인은 나 스스로의 문제였지만, 마지막 국내 스타트업에서 애자일/칸반이나 회의문화 개선 따위를 후회 없이 집어치웠던 이유는 젊음과 변화를 대외적으로 쉬지 않고 외치던 그 스타트업 대표에게 아래와 같은 말을 들은 이후였습니다.
애자일인가 뭔가로 하면 이제 개발 기간 지켜지나요? 더 빨라지나요? 더 빨라지는 겁니까?
벽에 붙여있는 저 포스트 조각들은 뭔가요? 저게 의미가 있나요? 뭔 소린지 하나도 모르겠네
개발팀끼리 맨날 회의하는 거 같던데 시간낭비 아닌가요?
개발팀의 프로세스 개선을 하기 위해서는 온갖 이론과 개선법으로 가득 채워져 있는 서적들이나 글들보다 팀원들의 적극적인 의지나, 운영진들의 신뢰가 먼저 필요했을지도 모르겠습니다.
3. 개발 프로세스 관리의 꿈을 다시 가져오다. : 칸반(看板, kanban)
서론이 너무 길었습니다.
그런 개발 문화의 개선 의지가 많이 사라진 상태에서 좀 더 넓은 환경을 경험하고자, 지금은 팀장의 위치가 아닌 팀원의 위치에서 경험을 하고 있는 중입니다.
공교롭게도 이곳 일본의 회사에도 칸반 방식으로 개발 프로세스를 그려가고 있습니다.
지난 글에서도 설명을 했었지만, 우리 회사의 팀 구성은 개발팀, 디자이너팀, 분석팀 등의 역할 베이스의 팀 구분이 아닌 업무 베이스로 구성이 됩니다.
입사 당시, 실험적인 한 팀에서만 시범적으로 진행했던 칸반 방식은 현재 운영진, 재무팀, 마케팅, 사업 개발팀 등 비 개발적인 구성원이 중심이 된 팀에서도 모두 칸반 방식을 통해 진행하고 있습니다.
재무팀 칸반
마케팅팀 칸반
서비스 개발팀 칸반
데이터 개발팀 칸반
마케팅팀 칸반각 팀을 위해 사무실 구석구석에 칸반 보드를 만들어서 운영하고 있으며, 각 칸반 운영방식은 팀마다 독자적으로 운영됩니다.
따라서, 같은 칸반 방식이라고 할지라도 각 행을 구성하는 수영 레인(프로세스)에 대한 정의가 각각 다르며, 이슈를 구성하는 카드의 구성도 모두 다릅니다.
어떤 팀은 앞서 예를 들어 설명한 것처럼 to-do, doing, done 식의 형식으로 구성한 팀이 있는 반면, 어떤 팀은 사전조사, 계약 준비, 계약 성사, 계약 체결 등의 업무 베이스로 구성하는 팀도 있습니다.
카드의 색상에 대한 정의도 각각 다릅니다. 어떤 팀에서는 카드 색상으로 담당자를 표현하기도 하며, 다른 팀에서는 긴급도에 따른 이슈로 구분하기 위해 사용하기도 합니다.
회사에서 느꼈던 칸반 방식을 위한 준비사항을 나열해봅니다.
a. 칸반 방식을 적용하기 위해 실험할 팀을 선정한다.
b. 해당 팀원들에게 칸반에 관련된 서적을 알려주고 일주일 정도의 시간을 준다.
c. 해당 팀원들이 모두 습득이 완료되면, 1시간가량의 회의시간을 갖고 준비 단계에 들어간다.
d. 칸반 보드 구성을 위한 구성물 등을 구입한다.
e. 칸반 보드 구성을 위한 goal을 설정하며, 각 수영 레인을 구성하기 위해 1~2시간 모든 팀원들이 참석하여 회의를 진행한다.
f. 칸반 보드를 구성한다.
g. 구성된 보드를 보며 1~2시간가량 리뷰 회의를 한다.
h. 완성된 보드를 운영하며 약 2주간 테스트 운영을 하며, 수영 레인을 변경한다.
i. 최종 완료된 보드를 통해 운영을 하며, 3개월의 운영 이후 타 팀에게 리뷰를 한다.
또한 칸반 운영을 통해 암묵적으로 정해진 룰 또한 나열해봅니다.
a. 반드시 타 팀의 칸반 보드를 견학하여 구성한 사유를 듣는다.
b. 문제점이 있다면 피드백을 통해 반드시 공유한다.
c. 반드시 오프라인 보드를 작성하여 모든 직원들이 볼 수 있도록 한다.
d. 반드시 칸반을 위한 회의를 진행한다. (보통 10분 내외 소요)
보통 3개월(1분기)마다 팀이 변경이 되기 때문에 보통 3개월 간격으로 칸반 보드가 다시 만들어지지만, 팀 변경 후 업무를 시작하기 전, 칸반 구성을 위해 최소한 1주일~2주일의 시간은 팀원 모두가 칸반 보드 구성을 위해 시간을 할애합니다. 그 시기에는 회사 전체 모든 팀이 칸반 보드를 재구성하기 때문에 타 팀의 칸반 보드를 견학하며 참고하기도 하고 개선해가는 모습은 언제나 봐도 즐겁습니다.
우리 회사임에도 참 부러웠고 즐거웠던 점은.
전 회사 직원 모두가 칸반에 대해 적극적이었으며, 흔히 블로그나 웹에서 정리된 간단한 글만 읽어보고 칸반을 진행하는 수준이 아니었다는 점입니다. 각 수영 레인에 할당하는 WIP에 대한 숫자도 오랜시간동안 토론을 통해 결정합니다.
포스트잇 한 장 한 장에 진지한 의미를 부여하며, 다른 수영 레인으로 이동할 때는 매일 진행되는 칸반 회의에서 각 팀원들의 의견을 받은 후에 이동시킵니다. 개발팀끼리, 분석팀끼리의 칸반 회의가 아니기에 개발 중심적인 언급이 나올 때도 있으며, 마케팅 중심적인 언급이 나올 때도 있지만, 시간이 지나면서 각 롤에 대한 이해도가 깊어지는 부분도 개인적으로는 참 놀랐던 부분 중 하나입니다.
최근들어 문득 떠오른 깨달음 중 하나는, 과거의 실패 요인중 비개발팀 중심의 타부서와의 협조가 긴밀하게 되지 못한 큰 이유가 온라인 툴을 고집해서 였지 않을까 라는 생각도 해봅니다. 오프라인 보드를 사용하게 되면 계정 생성, 가입 승인, 권한 설정, 로그인, 수영라인 생성, 카드 작성, 카드 이동, 카드 삭제등에 대한 설명 이 전혀 필요없다는 것을 그때는 왜 몰랐을까요.
국내에서 5년간 시도했던 일들을 이곳에 와서 불과 1년도 채 되지 않아 발전해 가는 모습을 바라보며 조금은 슬프기도 하지만, 비로소 내가 보고 경험하고 싶었던 일들을 바라보며 업무를 진행하기에 참 다행이란 생각도 듭니다.
물론, 모든 게 완벽하지 않기 때문에 각 팀에서 시행착오도 많습니다. 의욕이 앞선 나머지 수영 레인(각 프로세스 행)을 30개 이상 나열한 팀들은 결국 며칠 진행하다가 스스로 녹다운된 사례도 있고, 앞서 실패의 요인으로 설명했던 것처럼 개발자와 비개발자 간의 간격을 좁히지 못한 채 수영 레인을 구성하여 결국 모두가 이해하지 못하는 칸반 보드가 되어버린 사례도 있습니다.
하지만 이들은 이런 실패도 모두 회사의 노하우, 각 팀원들의 노하우로 남겨진다고 믿고 있고, 그러기 때문에 실패에 대한 두려움이 전혀 없습니다. 이러한 사례들이 모든 팀에게 공유가 되어 좋은 부분만 병합하여 다음 칸반 보드가 만들어지기 때문입니다.
이곳 CTO도 쉽지는 않겠지.어느 날 생뚱맞게 슬랙에 올라온 CTO의 한탄입니다.
같은 이유는 아니었겠지만, 새로운 시도에는 항상 어려움은 따르는가 봅니다.
그래도 이 회사 CTO는 포기하지 않고 지금도 계속 많은 시도를 하는 중입니다. 억지로 하는 모습이 아닌 즐기는 얼굴을 하고 말입니다.
이 나이 돼서야 이런 것들을 경험한 다는 게 한편으로는 더 빨리 경험하지 못한 게 안타깝기도 하지만, 지금이라도 경험을 하면서 즐기고 있다는 게 한편으로는 다행스럽기도 합니다.
이번 글에는 칸반 문화와 회의 문화를 정리해볼까 했습니다만, 글이 너무 길어져 회의 문화는 다음 글에 이어 적어야겠네요. 한국에는 비가 많이 오는 모양입니다. 이곳 치바는 가을이 오려나 봅니다. 밤이 되면 선풍기 바람도 차갑네요. 다들 건강 챙기시길 진심으로 바라봅니다.
