애자일로 가는 또다른 길 KanBan
애자일로 가는 또다른 길 KanBan 영상의 내용을 정리한 글입니다
애자일하게 일한다는 것?
애자일의 특징을 떠올려보면 주로 스크럼의 특징을 이야기하게 된다.
스크럼의 주요 멤버는 제품 책임자인 PO, 개발자, 스크럼 마스터의 역할들로 구성된다.
제품 백로그를 planning을 통해 스프린트 백로그를 만들어내고 이를 통해 4주 이내 스프린트를 진행하는데 매일마다 일일 스크럼이라고 부르는 짧은 회의를 통해서 진행상황을 팀내에서 sync를 맞추게 된다.
이러한 스프린트가 완료되면 결과물이 나오게 되는데 이 결과물이 계속 눈덩이처럼 쌓이면서 증분(Incremental)이라는 용어로 표현되는 결과물로 나아가게 되면서 만들어나가는 것이 스크럼의 구조이다. 추가적으로 하나의 스크럼이 끝날 때마다 스크린트 리뷰 (제품에 대한 피드백), 스프린트 회고(우리가 일하는 방식에 대한 피드백)을 진행한다.
이러한 스크럼은 하지만 애자일하게 일하는 하나의 방법론 중 하나에 불과하다.
스크럼 역시 좋은 방법론이고 많은 경우 좋은 결과물을 만들어내고 애자일하게 일을 진행하게 도와주는 것이 사실이다. 하지만 애자일하게 일하는 다양한 방법론이 존재한다는 것을 생각하지 못하게 하는 장애물이 될 수 있고 애자일하면 스크럼만을 떠올리게 하여 다른 시도를 어렵게 하는 요인이 된다.
다양한 조직과 업무 상황에 맞는 방법론은 제각각일 수 있기에 최적화된 방법론을 찾기위해 스크럼 외에 애자일하게 일할 수 있는 방식들을 많이 알아가는 것은 중요하다.
애자일하게 일하는 것에 가장 큰 장애물은 무엇일까?
설문에 따르면 가장 많은 답변으로 나온 것은 변화에 대한 심리적 저항감이다.
어떤 조직이든 사람들은 기존 익숙한 방식을 선호하게 되어 애자일을 도입한다고 했을 때 반감을 가지게 되고 분명 애자일하게 일한다고 하지만 결국 툴만 도입하고 억지로 맞춰가거나 시스템만 구축하다가 결국 애자일하게 일하는 것이 뭔지 각자 알아서 해야되는 조직들을 많이 보게된다.
예를 들어 스크럼을 적용하는 사례에서 자주 듣게되는 부분이 있다. 데일리 스크럼을 진행하게 되면 꼭 멤버들로 부터
“매일 진행하는 것이 불필요한 것 같아요” “시간 낭비 같은데 일주일에 한두번하면 안되나요?” “바쁜데 생략하고 진행하시죠”
등등의 이야기를 듣게 된다.
그러나 스크럼 도입에 주요 레퍼런스로 대표되는 스크럼의 공식 가이드를 보면 이러한 부분에 대해 다음과 같이 언급하고 있다.
즉 스크럼을 일부만 적용하는 것은 스크럼이 아니다라고 경고성 언급이 가이드의 부분을 차지하고 있다.
뿐만 아니라 스크럼 가이드는 이상적 스크럼을 설명하면서 긴밀하게 고객과의 협업을 통해 만들어가며 제대로 역할을 하는 PO와 스크럼 마스터가 존재하는 팀이고 cross-functional한 구성을 잘 이루고 있어야 한다고 이야기한다.
이와같이 심리적 저항감과 싸우며 스크럼을 제대로 적용하지 못한 채 스크럼 방식으로 일한다고 말하는 사례는 심심치 않게 찾아볼 수 있다.
애자일로 가는 또 다른 길, 칸반
또다른 애자일로 가는 방법론로 칸반에 대해 알아보기 위해 먼저 칸반의 원칙 두가지를 살펴보면 다음과 같다.
칸반은 지금 상태 그대로 시작한다가 첫 원칙이고 완벽하게 시작할 수 없다는 전제가 깔려있다. 첫 원칙부터 구성원들의 변화에 대한 심리적 저항감과 싸워야 했고 뭔가 까다로움으로 가득했던 스크럼의 방식과는 다름을 알 수 있다.
이러한 점이 이미 waterfall과 같은 예전방식에 익숙한 조직이지만 애자일하게 일하고 싶은, 그러나 현실적으로 주저하게 되는 조직에 있어서 더욱 매력적인 포인트로 다가오는 방법론이다.
칸반 메소드
먼저 칸반에 대한 인식과 오해를 풀고 가는 것이 좋을 것 같다.
다음과 같은 오해들을 나열하다 보면 제대로 이해한 척, JIRA와 같은 툴에 익숙한 사람들이 말해봄직한 뜨끔한 포인트들이 많을 것이다.
자 먼저 칸반 보드와 칸반은 결코 동일한 개념이 아니다
칸반 보드는 칸반이라는 거대한 메소드의 일부 구성 요소일 뿐 그 자체가 칸반은 아니다. 칸반은 보드를 중심으로 눈에 보이는 부분 그리고 보이지 않는 부분을 포함한 상당히 다양한 매커니즘이 공존하는 방법론이다.
다음으로 JIRA는 칸반이 아니다. 칸반에 대해 잘 아는 분들은 처음 칸반을 도입하는 경우 JIRA를 추천하지 않는다. 일단 JIRA의 기능 자체가 폭넓게 칸반을 지원하고 있지 않고 칸반 보드를 통해 가장 얻고 싶은 한 눈에 팀원들이 어떻게 일하고 있는지 흐름을 보고 싶은 부분이 큰데 JIRA를 통해서는 이 부분이 제한적이고 한눈에 파악하기 어려운 것이 사실이기 때문이다. 결국 한눈에 일의 흐름을 파악할 수 있고 팀원 모두가 같은 시야를 공유하도록 하기에 JIRA는 좋은 툴의 역할을 하고 있지 못하다.
그럼 칸반 메소드에서 정의하는 칸반은 무엇일까?
칸반은 지식 업무를 제공하는 서비스를 정의하고 관리하고 개선하는 방법론이라고 설명한다.
다소 딱딱한 정의에서 조금은 칸반의 시점으로 바라보는 중요한 포인트를 4가지 살펴보면 다음과 같다.
- 첫째로 칸반은 업무를 흐름으로 본다. 고객이 무엇인가 원하는 것을 시작으로 고객에게 그 원하는 바를 손에 쥐어주는 순간까지로 바라본다.
- 둘째로 이 흐름은 일련의 지식을 발견하고 깨달음을 얻는 방향으로 점차 나아간다고 바라본다. 예를 들어 처음 아무것도 모르는 무지의 상태에서 사람이 몇명이 필요하고 비용이 얼마나 들고 얼마나 업무를 이뤄낼 수 있는지 점차 정확하게 알아하는 지식 업무로 바라본다.
- 세번째로 이러한 지식업무를 통해서 고객의 니즈를 발견해나가는 과정을 서비스로 본다.
- 마지막으로 조직은 그 자체로 서비스들이 얽히고 섥힌 일종의 네트워크이다.
잠시 처음으로 돌아가 칸반 메소드의 기원을 살펴보면 도요타의 린 제조의 영향을 받아서 데이비드 J. 앤더슨이 마이크로소프트에서 처음 시도하였다.
또한 생각보다 로펌이나 엔터테이먼트 조직 등 다양한 조직에서 칸반을 도입하고 시도하려고 하고 있다. 칸반은 실제 사례 등을 통해 계속 가이드가 업데이트되고 있고 다이나믹하게 발전하고 있다.
칸반의 6가지 일반 실천법
많은 사람들이 칸반에 대해서 1번에 해당하는 시각화에 대해 집중적으로 알고 있지만 나머지 5개 요소도 매우 중요한 요소이다.
- 시각화
- 모든 흐름의 시각화를 통한 체계화
- WIP (현재 진행 중인 업무) 제한
- Pull 방식의 업무 흐름
- 흐름 관리
- 일할 때의 병목현상이나 지연 현상들을 지표화 하는 것
- 정책 명시화
- 모두가 정한 정책을 애매하게 알고 있는 것이 아닌 명시화 할 것
- 피드백 루프
- 일종의 피드백을 통한 휠 체계 (케이던스)
- 점진적 개선
- 급진적인 변화가 아닌 점진적 개선
실천법을 자세하게 알아보기 전에 칸반의 본질을 이해하기 위해 살펴보면
위의 두 팀 중 더 칸반에 맞는 팀은 어디일까? 한 팀은 간트 차트를 쓰고 있지만 팀의 일하는 진행 상황에 문제가 생기면 그 부분에 대해 진지하게 논의해보려하고 있고 다른 한팀은 칸반 보드를 사용하고 있지만 팀의 일하는 진행 상황이 어긋나도 뭐라고 그냥 하라고 하고 있다. 칸반의 가치관과 더 맞는 팀은 칸반 보드를 사용하지 않더라고 첫번째팀이다. 결국 사용하는 툴이 중요한 것이 아니라는 점을 강조하고 있다.
그럼 좀 더 자세하게 칸반에 실천법에 대해 탐구해보자
칸반 보드를 활용한 시각화에 있어서 레퍼런스와 가이드는 존재할 수 있지만 전세계 모든 칸반 보드는 유니크해야 하는 것이 맞다. 이유는 각자 해결해야 할 문제상황이 다르고 팀원이 다르고 직면한 환경이 다르기에 같은 보드를 사용한다는 것은 적절하지 않기 때문이다.
몇가지 가이드나 특징을 살펴보면
절대적인 규칙은 아니지만 일반적인 칸반 보드는 일종의 흐름이 존재한다.
따라서 이러한 흐름을 잘 표현할 수 있어야 한다.
또한 칸반은 현재 상황에서 시작한다라는 설명에서와 같이 무리해서 완성된 시스템을 한번에 적용하는 것이 아니기에 무리해서 전체 흐름을 다 커버하려고 할 필요가 없다.
앞뒤 상황을 보면서 조금씩 팀원이 감당할 수 있고 파악할 수 있는 부분, 책임지고 있는 범위에서 부터 시작해서 넓혀가는 것이 칸반에 알맞는 방식이다.
칸반 시각화에서 또 하나 중요한 점은 결국 일의 흐름을 위한 것이기에 모든 팀원들이 매일 매일 무언가 진행되고 있다는 느낌을 갖도록 만드는 것이 중요하다. 따라서 그 흐름을 위한 Task 분리 ( ex) sub task 활용 ) 및 스프린트의 사이즈를 정하는 것이 좋다.
업무 흐름을 파악하기 위해서 여러 요소나 시각화 컴포넌트를 활용하는 것이 좋은데 그 중 하나가 블로커이다. 블로커는 일의 흐름을 막는 인터럽트나 다른 작업으로 볼 수 있다. 이는 전체 진행되는 업무 흐름을 막는 요소들을 잘 시각화하고 병목현상에 대한 파악이 용이해진다.
이 부분은 칸반을 제대로 시작하고 싶은 팀이 가장 어려워하는 요소 중에 하나이다.
우리는 일을 하면서 언제나 하나 받아들여야 하는 사실이 있는데 이는 일반적으로 우리에게 요구되는 일의 양보다 우리가 소화할 수 있는 일의 양이 적다는 사실이다. 이러한 문제로 업무 흐름을 원할하게 하는 방식 중 하나가 WIP의 제한이다.
WIP를 제한하는 방식은 Pull System을 통해 이해하면 이해가 더 쉽다.
Pull System은 말그대로 당겨오는 방식이다. 즉 뒤에서 완료되어 앞으로 미는 것이 아닌 고객에서 전달되는 방향에서 일이 필요할 때, 즉 Pull System의 빈자리가 발생했을 때 당겨오는 방식으로 진행된다.
따라서 WIP 제한은 우리가 일을 최대한으로 효율적으로 할 수 있는 방식으로 비효율적 overwork나 context switching으로 인한 낭비 요소들을 제외한 가장 적절한 타이밍에 당겨오는 방식으로 빈칸을 채워가며 일을 진행하는 원할한 흐름을 위한 시스템이다.
흐름을 관리하는 것은 더 빨리 일하는 속도에 대한 것보다 비즈니스 예측력을 높이는 것에 대한 것으로 좀 더 이해하기 쉽게 설명하기 위해서는 일의 흐름 시스템에 대한 구조를 먼저 보는 것이 좋을 것 같다.
고객이 뭔가 원하는 시점부터 고객에 손에 그 서비스가 전달되는 순간까지를 Customer Lead Time이라고 부른다. 칸반에서 주목하는 부분은 일을 시작하고 끝내기까지의 System Lead Time이다.
System Lead Time의 흐름을 관리하기 위한 표 중 하나가 리드타임 분포도이다. 해당 분포도는 나눠진 Task별 걸린 시간을 날에 따라 하루가 걸린 건지 이틀 혹은 이상이 소요되었는지 표로 나타낸 것이다. 분포도의 분포가 하나로 몰릴 수록 비즈니스 예측성이 높아지므로 좋고 왼쪽으로 쏠리는 경우가 짧은 시간에 일이 완료된 것으로 역시 이상적이라고 볼 수 있다.
이러한 표를 통해 흐름을 관리하면 일의 측정이 용이해지고 예측성이 강화된다. 데이터를 base로 플래닝이 가능하고 효율적인 일의 진행이 가능해진다. 설득력도 강화되는 것이 예를 들어 지난 95%의 작업이 며칠 이내로 완료되었으므로 이번 작업도 어느정도 소요될 것이라는 커뮤니케이션과 예측이 가능해진다.
유사하게 런차트라는 구조로 단지 다른 형태의 산포도로 표현한 것으로 이 그래프 역시 시각화를 통한 흐름을 관리하는 것과 동시에 일반적인 방향성과 동 떨어진 outliner를 분석하면 왜 해당 작업은 오래걸렸고 어떤 Blocker와 병목지점을 겪었는지 파악과 재발방지가 가능하다.
마지막으로 누적흐름도는 파란색은 완료한 작업을 초록색은 백로그 작업을 나타내서 일의 양이나 일의 속도 변화를 파악할 수 있는 역시 예측가능한 평균적인 일의 속도를 볼 수 있는 그래프이다.
이와 같이 정량 지표화를 통해 비즈니스 예측성을 높이는 방향으로 일의 흐름을 관리해나간다.
어떠한 룰을 많은 시간의 논의를 통해 정하더라도 명시하지 않으면 여러가지 오해가 발생할 수 있어서 명확하게 글로 남겨서 불필요한 커뮤니케이션 및 문제를 방지할 수 있다.
점진적 발전을 위해 회의, 회고 등을 통한 피드백을 활용하는 방식이다. 칸반은 불필요한 회의가 늘어난다는 오해가 있는데 칸반에서 이야기하는 회의는 사실 칸반 회의, 재보충 회의, 회고이다. 기존 회의에서 추가할 필요도 없이 회의를 변형하거나 칸반에 요소가 담겨있다면 그대로 진행해도 상관없다.
칸반 회의는 데일리 스크럼과 달리 다소 늘어지고 지루해질 수 있는 점을 방지하기 위해 서로 소통을 강조한다. 보드를 중심으로 일을 초점으로 필요한 커뮤니케이션을 하고 현황을 파악하기 위한 이야기를 하고 마치는 회의이다. 보드에 나와있는 정보를 굳이 하나하나 나열하는 방식은 지양한다.
팀 회고는 일하는 방식의 근거 데이터를 통해 더 나가갈 점에 대해 이야기하고 고객 관점에서 더 좋은 방향에 대한 이야기를 한다.
칸반은 다시한번 말하지만 지금 상태에서 시작해서 점진적인 변화를 하는 것으로 무리해서 변화를 추구하는 것이 아니다. 실험을 하면서 개선해가고 의견을 경청하여 모든 칸반 실천 방향을 하는 것이 낫지 않다고 하면 필요한 부분만 적용하고 끊임없이 변화하는 것이 칸반에 맞는 방향이다.
실제 칸반보드의 3년간의 점진적 개선을 통한 변화의 모습
Before
After
전세계의 모든 칸반은 팀에 따라 업무에 따라 고유의 모습을 가지고 있기에 정답은 없다. 이렇게 하면 더 고객이 만족하는 결과물, 이렇게 하면 더 팀으로서 좋은 결과를 얻을 수 있다는 깨달음을 쌓아가며 팀에 맞는 칸반을 구성하면 된다.
칸반 실천 탑
추가적인 칸반 가이드
칸반을 처음 도입한다면?
처음은 칸반 보드를 중심으로 티켓을 설계하고 -> 시각화!
데일리 칸반 미팅과 회고를 중심으로 -> 피드백!
그 이후 WIP 제한 등의 나머지 실천 방법이나 요소들을 추가해나가며 팀에 맞는 칸반을 찾아가면 된다.
Scrum VS Kanban
둘 다 모두 정답은 없고 애자일하게 일하기 위한 방법론의 선택지이다.
주로 전문가들은 신규 프로젝트( 3개월, 1년 기한 내에 프로젝트성으로 결과물을 내는 경우 )는 스크럼의 방식을,
칸반은 끊임없이 개선하고 주로 Maintenence와 같이 프로젝트성으로 끝이있는 작업보다는 계속 진행되는 경우를 더욱 추천하고 있다.
칸반은 지금 상황 그대로 실천하면 되기에 부담보다는 실행하는 작은 실천으로 시도해보자!