이 글은 회원 관리 플랫폼 관련 Startup인 Strompath가, Scrum에서 Kanban으로 성공적으로 변경한 경험에 대한 포스팅의 번역입니다. 오,탈자나, 의, 오역, 비문이 있을 수도 있으니 잘못된 부분은 리플이나 쪽지로 제보해주시면 감사하겠습니다 :)
잘 가요 스크럼, 반가워요 칸반
BY ALEX SALAZAR ON JANUARY 20 2014, 번역 조민규
작년 Stormpath에서는, 스크럼에서 칸반으로의 큰 변화가 있었다. 우리는 애자일 원칙을 사랑했지만, 스크럼은 우리가 일하는 방식과 맞지 않았다. 칸반은 우리의 조직들을 더 효율적이고, 행복하게 만들었고, 소프트웨어의 품질에 더 집중할 수 있도록 도와줬다. 결국 그것은 우리 기업 문화의 핵심적인 부분이 되었고, 지금은 마케팅, HR과 같이 비기술적 조직들에서도 사용하고 있다.
칸반은 한 번에 진행되는 일의 수를 제한함으로써 지속적인 배포에 초점을 맞추고, 더 효율적으로 만들어준다. 칸반은 Toyota에 의해 만들어졌고, David J. Anderson에 의해 소프트웨어 개발에 적합하게 수정되어, 연속적인 환경에서 클라우드 소프트웨어를 제공하는 조직들에 큰 영향을 수 있다.
스크럼, 네가 아니라 나 때문이야 ^1
Stormpath에서 애자일 원칙은 항상 중요하고, 우리는 기술 조직에서부터 마케팅까지 모든 팀에 적용하고 있다. 스탠드-업^2은 팀을 투명하게 해주고, 방해요소를 제거한다. 구현 가능한 최소의 단위로 업무를 분류하는 것은 개발자들에게 일이 잘 진행되고 있다는 느낌을 준다. 이런 (고객으로 부터 나온 유저 스토리를 바탕으로 하는) 작은 단위의 이터레이션들은 사람들이 어떻게 Stormpath API를 사용하는지 알게 해줌으로서 그것을 발전시킨다.
그러나 스프린트 기반 스크럼은 그러나 우리의 업무에 적합하지 않았다. 그것은 유연하지 않았고, 많은 오버헤드를 만들고, 팀의 번아웃 원인이 되기 시작했다.
오버헤드
우리는 제한된 리소스로 아주 빨리 움직이는 벤처 기업이다. 스크럼은 많은 오버헤드를 가지고 있었다: 스프린트 플래닝은 제품 팀의 미팅준비와 더불어, 전체 기술 조직의 시간을 반나절이나 잡아먹었다. 그것은 모두가 업무에 포함되고 도움이 된다고 느끼게 만들었지만, 모두가 힘들어 했던 부분은 그게 아니었다. 우리는 이미 협동적인 조직이었다. 스프린트 플래닝은 개발자들이 관계가 없는 기능의 토론을 끝까지 앉아서 보게 만든다.- 몇 시간 동안이나. 게다가 긴 시간을 전체 조직에 연관된 문제와 우선순위에 대하여 이야기 하는데 (종종은 무의미한 토론을 하는데) 소비할 것이다.
추정의 미신
스크럼은 업무 시간에 제한을 둠으로써 생산성을 끌어내는 것이 핵심이다. 스프린트는 당신이 작업들을 완료하는데 걸릴거라고 생각하는 시간들을 가득 담아둔 양동이다. 대부분의 팀들과 같이 우리도 추정을 크거나 작게 할 때가 있다. 나는 우리가 추정을 정확하게 하지 못한다는 것을 100%확신한다. 많은 시간들이 기능의 사이즈를 나누고 토론하기 위해서 낭비된다고 느끼는 것은, 아마 우리가 틀렸기 때문이다. 그래서, 무엇이 문제일까? 그것이 우리의 고객을 위해 중요하다면, 그것은 크기에 상관없이 완성해야하며, 일반적으로 우리는 항상 가장 작은 가능한 범위로 쪼개고 있다.
스크럼은 당신이 추정에 익숙하다고 가정한다
많은 애자일 기술 조직에 만연한 틀린 추정이 대부분의 문제를 만들어낸다. 이슈들이 예상한 것보다 커진다면, 스프린트에 과부하가 걸리게 된다. 우리는 아주 작은 비즈니스 이득을 위해, 프로세스를 속이면서, 인공적으로 만들어진 스프린트에 맞추기 위해 계속해서 작업 범위를 조정하는데 시간을 허비했다-심지어 플래닝 미팅보다 더.
변경 관리 전골^3
기민하게 움직이고 불확실한 환경에서 동작할 필요가 있는가? 스크럼은 그것을 복잡하게한다. 스프린트 플래닝이 한번 완료된 후라면, 스프린트의 변경은 더 많은 플래닝 미팅들을 필요로 한다. 확실히, 당신이 사업팀으로부터의 방해를 방어하면서 진행 중인일을 변경하는 것은 고통스러울 것이다. 그러나 아직 진행하기로 하지 않은 작업에 대한 변경은 어떤가? 큰 버그가 발견 됐다면? 스프린트 내에 하기로 약속한 기능이 고객의 요청에 의해 다시 생각해봐야 한다면? 이런 일반적인 상황들이 많은 회의들과 불만과 복잡성들을 만들어 낸다.
사기와 번아웃
비현실적인 예측과 끊임없이 빈번하게 발생하는 틀린 추정들은 팀의 스프린트의 계획을 흐트릴 것이다. 회고는 우리가 한 실수들에 대한 비평으로 변할 것이다. 틀린 추정, 우선순위와 스펙의 변경. 사업팀은 기술팀이 목표를 놓치고 있다고 느낄 것이고, 기술팀은 사업팀이 계속해서 목표를 바꾸고 있다고 느낄 것이다. 모두의 사기가 꺽인다. 2주 단위의 이터레이션은 길었다. - 우리는 항상 무언가를 배포를 해왔기 때문에 속도가 느껴졌다. 그러나 우리의 생산성 그래프는 끝이 급격하게 뾰족해졌다. 스프린트 막바지에 “최선을 다했다고”말하기 위해 미친듯이 달리는 시간들은, 사람들이 그 다음주에 회복할 시간을 가져야 하기 때문에 생산성을 망가트린다. 더 짧은 스프린트 주기는 생산성 그래프의 끝을 완만하게 만들어 줄지도 모르지만, 하나의 스프린트 내에 완료할 수 있는 작업들을 제한한다. 여유있는 스프린트는 압박을 감소시키지만, 관리에 대한 리스크에 노출 된다.우리는 대안을 찾기 시작했다.
칸반을 시작하다
스탠포드 비즈니스 스쿨에 다니는 동안, 나는 Toyota의 “Just-in-Time” 또는 칸반 제조 공정에 대하여 많이 공부하였다. 그것은 놀랍도록 단순하며, 더 중요한 것은 우리의 속도적 목표를 지원한다는 것이다. 그것은 유연하게 설계되어 우선순위를 빠르게 변경 가능하다. 간단한 구글 검색을 통해서 나는 칸반 소프트웨어 개발에 대한 수많은 문서, 책, 영상들을 찾을 수 있었다. 우리의 Atlasssian 슈트 역시 그것을 지원했다.
칸반이란?
칸반은 연속적 흐름 처리 방식이다 : 이슈는 큐에 입력되고, 개발 프로세스의 단계에 따라 “당겨”진다. 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시된다. 이슈들은 “수영 레인(Swimlane)”으로 불리는 행으로 나눌 수 있다. Stormpath는 이슈들의 우선순위를 나타내기 위해 수영 레인을 이용하기로 결정했고 - 우선순위가 낮은 이슈들을 아래에 배치했다. 칸반의 핵심은 Work-In-Process(WIP)가 동시에 개발이 진행 될 수 있는 아이템의 수를 제한하는 것이다. 작업자는 WIP에 여유가 있을때만 작업을 왼쪽에서 오른쪽으로 당길 수 있다. 스크럼이 스프린트에 이용할 수 있는 작업 시간을 제한함으로써 생산성을 제어하는 반면, 칸반은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 생산성과 벨로시티를 제어한다. 추정은 더이상 프로세스의 일부가 아니다.
벨로시티는 여전히 중요 목표지만 지금 우리는 이슈 레벨에 따라 최적화 시켰고, 사이클 타임이라고 부르고 있다. 보드의 오른쪽에 있는 아이템은 그 뒤의 아이템들보다 더 높은 우선순위를 가진다. 이것은 팀의 중요한 핵심 가치를 만들어 낸다. 당신이 더 많은 작업을 하기 전에, 지금 하고 있는 작업부터 끝내라. 멀티 테스킹을 그만둬라. 이 일 저 일을 번갈아가면서 하지 마라.
사업적 요구에 따른 우선순위의 변동? 사라졌다. 칸반과 함께라면, 사업팀은 “To Do” 열을 소유하고, 기술팀은 나머지 모든 열을 소유한다. 사업팀은 작업들이 To Do에 있는 동안 야생 동물처럼 날뛰게 할 수 있지만, 다른 열로 이동된 이후에는 큰 노력 없이 그것들을 바꿀 수 없다. 결과적으로, 개발자들은 작업을 선택하는 순간 사업적인 영역과 단절 된다.
행복한 팀
칸반은 우리의 팀을 매우 행복하게 했다. 스크럼은 개발자에게 규범적이고 유연하지 못한 규칙을 부과하여 관리되는 것 처럼 느껴지게 만들었지만, 칸반은 탄력적이고 절차 지향적이고 기술 조직에 의해 관리된다. 우리는 Stormpath에서 어떻게 칸반을 통해 프로세스를 넘어서서 오너십과 성공을 부여할 수 있을 것인지에 대해 구현하고 개발했다. 전환은 매우 부드러웠다 : 의미있는 토론과 플래닝에 2일 정도.
게다가, 연속적인 흐름 모델은 “데드라인”이 없다는 것을 의미한다. 그러나 “속도”에 대한 압박은 늘 존재한다. 이것은 우리가 겪고 있었던 번아웃을 현저하게 감소시켰다. 심지어 전체적인 생산성은 더 향상됐다. 우리는 전체 팀 플래닝 스프린트로 격주에 한번씩 반나절을 허비하지 않았다; 우리는 스프린트와 일치시키기 위해 개발 범위를 속이지 않았다; 칸반은 생산성과 코드 품질 모두를 향상시켰고, 한번에 여러 업무를 진행하는데서 오는 혼란을 감소시켰다. 거기다, 모두가 칸반 보드만 보면 무엇이 누구에 의해, 얼마정도 진행되고 있는지, 다음 작업을 위해서 무엇이 필요한지, 병목이 어디인지 알 수 있기 때문에, 프로젝트 관리 오버헤드를 감소시켰다.
품질에 대한 조직적 목표
계획적이지 않은 칸반의 주요 이점은 소프트웨어 품질에 초점을 맞출수 있게 해주는 것이다. 스크럼에서는, 스프린트 내에 있는 것을 하기 위하여 코드리뷰를 건너뛰고, 코드 커버리지 표준인 95%에 못미치는 70%를 승인하는 등 기술적 부채를 늘려가는 경우가 많았다. Stormpath는 코드 품질을 매우 중요하게 생각했기 때문에, 이렇게 지속되는 리스크는 모두를 불편하게 했다.
칸반에서는, 코드 품질 보증 단계는 프로세스에 포함된다. 우리는 거의 데드라인이 없기 때문에, 이런 단계를 건너 뛰어야 할 만한 압박이 없다 . 사실상, 기술 조직이 프로세스를 소유하기 때문에, 프로세스에 전념하게 하는 강한 압박이 있다. 개발자들은 100%의 코드 리뷰와 95%가 넘는 코드 커버리지를 만들기 위해 분투할 것이다.
거의 없는 오버헤드
스프린트 플래닝? 사라졌다. 프로젝트 관리? 적다. 추정 포커? 없다. 스크럼 마스터? 없다. 우리는 여전히 스탠드-업을 하지만, 많은 시간을 들이지 않는다. 기술 조직은 제품을 개발하는데 시간의 대부분을 소비한다. PO^4는 다음에 무엇이 “To Do”으로 들어갈 지 결정하고, 기술 조직은 거기서 그것을 가져온다.
개선(카이젠) VS 회고
칸반에서, 스크럼 회고는 개선 회의(카이젠은 일본어로 “개선”)로 대체된다. 그 차이는 미묘하지만 강력하다. Stormpath는 매 2주마다 개선 회의를 가지고 있다; 개발자와 PO는 오버헤드를 감소시키면서, 속도와 품질을 향상시키기 위해 프로세스가 어떻게 수정되어야 하는지 논의한다. 우리가 한 것을 뒤돌아보고 비판하는 대신, 진취적으로 프로세스를 개선하는데 모든 에너지를 쏟는다. 방어적인 태도는 줄어들고, 협동력은 향상된다. 프로세스 안의 모든 것은 좋은 목표이고 새로운 아이디어들은 테스트 하기 위한 실험들로 간주된다. 대부분의 아이디어들은 시도해볼 수 있고, 매우 일부만 탈락한다. 그 결과, 개선 회의에서는 긍정적이고, 창조적인 느낌을 받을 수 있고, 프로세스는 아주 부드럽게 수행된다.
칸반은 완전하지 않다
우리는 성공적으로 칸반을 적용했고, 그로인해 정말로 행복하지만, 그것이 완벽한 솔루션이라는 의미는 아니다.
칸반을 위한 소프트웨어 도구들의 미흡
우리는 Atlassian Jira와 Greenhopper를 이용하고 사랑한다. 그들은 칸반을 위한 좋은 기능들을 가지고 있지만, 그들의 칸반 보드는 상대적으로 새롭고, 우리가 기대하는 것에 비해 유연스럽지 못하다(예를 들면, 수영 레인에서 WIP 한계를 가질 수 있도록).그 결과, 우리의 프로세스 일부를 Jira와 Greenhopper에서 가능하도록 맞춰야 했다. 당신이 칸반 보드를 팀의 특별한 요구에 따라 모델링 할 수 있다면, 칸반을 통해서 더 많은 이점을 얻을 수 있기 때문에, 그러지 못하는 것은 불행한 일이다.
신속함에 대한 조직의 동기부여 상실
스크럼에서는, 스프린트 시계가 큰소리로 똑딱거린다. 모두가 스프린트 안에 일을 완료하기 위해서 압박을 느낀다. 마음을 급박하게 만든다. 칸반에서는, 신속성은 더 추상적이고 그러한 감정적인 압박이 없다. 우리는 문화부터 관리에 걸쳐 계속 열심히 해야 조직이 건강하게 유지될 수 있다는 긴장감을 부여해야만 했다.
진정하시고 칸반하세요
칸반의 힘은 진행 하는 일의 제한을 두어 더 적은 아이템을 더 빨리 만들어 내는 것에 집중하는 것에서 나온다. 다른 모든 것들 처럼, 그것은 완벽하지 않고, 모든 상황에서, 모두를 위해 완벽히 적합하지 않을 수는 있다. 하지만 우리는 결국 행복한 팀, 더 높은 생산성, 사업과 기술조직 간의 더 적은 긴장감, 더 높은 소프트웨어 품질, 그리고 더 훨씬 적은 오버헤드를 얻었다.이겼다!
칸반에 관련된 유용한 링크들:
- Agile Chalk Talk: Kanban and Scrum
- David J. Anderson’s Kanban Book
- What is Kanban? Kanban + Scrum
- Do Agile Right (Kanban)
- What is Kanban?