칸반이 작동하는 이유 — 그리고 팀이 준비되었는지 알 방법

대부분의 팀은 누군가 블로그 게시물을 읽었기 때문에 칸반을 채택합니다. 더 똑똑한 질문은 칸반이 해결하는 문제가 실제로 팀이 가진 문제인지 여부입니다.

대부분의 팀이 인식하는 순간이 있으며, 보통 8명 또는 9명 이상의 사람들이 있을 때입니다. 일이 진행 중입니다 — 이메일이 전송되고, 기능이 배송되고, 클라이언트가 관리됩니다 — 그러나 아무도 다른 모든 사람이 무엇을 하고 있는지에 대한 명확한 감각이 없습니다. 프로젝트는 쌓입니다. 것들은 약속하고 조용히 잊혀집니다. 모든 회의 전에 업무가 실제로 어디에 있는지 파악하는 데 20분을 소비합니다. 답변은 보통 "어딘가"입니다.

그것은 칸반이 해결하도록 설계된 문제입니다. 전략을 설정하거나 올바른 사람을 고용하거나 문화를 구축하는 문제가 아니라 — 당신의 팀이 무엇을 하고 있는지, 그리고 무엇이 방해하고 있는지 알고 있는 구체적이고, 험난한, 운영 문제입니다.

그것은 이렇게 많은 관심을 받은 것에 대한 놀랍게도 겸손한 도구입니다. 칸반은 당신의 조직을 고치겠다고 청구하지 않습니다. 그것은 단지 일을 시각화합니다. 그리고 일관되게 적용되는 가시성은 다운스트림에서 놀랍게도 많은 것들을 바꾼다는 것이 밝혀졌습니다.

칸반이 실제로 어디서 왔는지

이 단어는 일본어이며 "사인보드" 또는 "빌보드"를 의미합니다. 이 시스템은 1940년대 후반 도요타에서 제조 공장의 인벤토리를 관리하는 방법으로 개발되었습니다. 아이디어는 간단했습니다: 고정 일정에 따라 부품을 생산하는 대신, 공장은 다운스트림 스테이션이 필요한 신호를 받을 때만 생산합니다. 물리적 카드 — 칸반 — 라인을 통해 요청으로 다시 이동합니다. 아무것도 추측으로 만들어지지 않았습니다. 아무것도 불필요하게 쌓이지 않았습니다.

도요타가 가진 인사이트, 그리고 소프트웨어 팀이 나중에 빌려간 것은 시스템의 대부분의 비효율은 사람들이 너무 천천히 일하는 것에서 비롯되지 않으며, 잘못된 일을 잘못된 시간에 하는 것입니다. 한 번에 너무 많은 것이 시작되었습니다. 아무도 알 때까지는 깨닫지 못하는 병목. 한 장소에서 완료된 업무는 다음 단계가 다른 곳에서 압도당하는 동안 앉아 있습니다.

소프트웨어 개발자들, 특히 2000년대 초 Microsoft 같은 회사에서, 이 아이디어를 지식 업무에 적응시키기 시작했습니다. 카드는 작업이 되었습니다. 공장 스테이션은 워크플로의 단계가 되었습니다. 그리고 사인보드는 보드가 되었습니다 — 처음에는 물리적, 나중에는 디지털 — 팀의 누구나 한눈에 진행 중인 것, 대기 중인 것, 완료된 것을 볼 수 있는 곳입니다.

칸반 보드가 실제로 당신에게 보여주는 것

기본 칸반 보드에는 3개의 열이 있습니다: 할 일, 진행 중, 완료. 많은 소규모 팀에게 충분하며 시작하기 좋은 장소입니다. 하지만 실제 가치는 이 단계를 당신이 일하기를 원하는 방식이 아니라 실제로 흐르는 방식을 매칭하도록 사용자 지정하기 시작할 때 나타납니다.

콘텐츠 팀은 아이디어, 브리프, 초안, 검토, 예약, 게시를 사용할 수 있습니다. 소프트웨어 팀은 "진행 중"을 개발, 코드 검토, QA를 위한 별도 열로 나눌 수 있습니다. 컨설팅 팀은 발견, 제안, 활성, 클라이언트 대기, 종료를 추적할 수 있습니다. 단계는 실제 핸드오프 및 실제 대기 시간을 반영해야 합니다 — 일이 손을 바꾸거나 뭔가 다른 일이 일어날 때까지 앉아있는 곳.

WIP 제한: 이를 작동시키는 규칙

칸반을 제대로 사용하는 팀을 더 예쁜 할 일 목록을 가진 팀과 구분하는 개념이 있다면, 그것은 진행 중인 업무 제한입니다 — WIP 제한. 아이디어는 각 열이 한 번에 있을 수 있는 최대 아이템 수를 가진다는 것입니다. 열이 가득 차면 뭔가 빠져나올 때까지 더 많은 일을 추가할 수 없습니다.

이것은 직관적이지 않게 느껴집니다. 진행 중에 더 많은 작업을 넣을 수 있다는 것은 더 많은 것이 완료되지 않습니까? 아닙니다. 사람들이 너무 많은 것에 동시에 일할 때 실제로 일어나는 것은 모든 것이 더 오래 걸린다는 것입니다. 컨텍스트 전환은 비쌉니다. 반쯤 완료된 작업은 조정 오버헤드를 만듭니다. 그리고 10개의 것이 "진행 중"일 때, 실제로 어떤 것이 이동하고 어떤 것이 단지 갇혀 있지만 표시되지 않는지 알기가 매우 어렵습니다.

진행 중인 열에 WIP 제한 3은 네 번째 것이 누군가의 책상에 올 때 팀의 누군가가 결정을 내려야 한다는 의미입니다: 어느 기존 작업이 먼저 완료됩니까? 이것은 우선순위를 강제합니다. 이것은 대화를 강제합니다. 그리고 새로운 항목을 시작하는 속도가 느려지더라도 개별 항목을 더 빨리 완료하는 경향이 있습니다.

칸반 대 스크럼: 팀이 항상 묻는 질문

소프트웨어 팀이나 현대 운영 생각에 어느 정도 시간을 보낸 경우, 아마도 스크럼을 만났을 것입니다 — 고정 2주 스프린트, 계획 세션, 회고, 스크럼 마스터, 제품 소유자 같은 정의된 역할로 일을 구성하는 프레임워크. 많은 팀은 스크럼과 칸반을 경쟁하는 방법론으로 취급하고 선택해야 한다고 느낍니다. 구별은 실제로 그보다 간단합니다.

칸반은 작업이 예측 불가능하게 또는 지속적으로 들어올 때 당신에게 더 잘 맞습니다 — 마케팅, 운영, 고객 성공. 스크럼의 고정 스프린트 구조는 순수 엔지니어링 일에 더 잘 어울립니다.

많은 팀은 둘 다 결합합니다. 그들은 제품 개발을 위해 스프린트 스타일 계획 사이클을 사용하는 동시에 스프린트 중이든 관계없이 유입되는 운영 및 지원 작업을 위해 칸반 보드를 실행합니다. 그것은 완벽하게 합리적인 하이브리드입니다.

칸반 보드를 시작하는 방법 — 3일 워크숍 없이

제가 본 최고의 칸반 구현은 작게 시작하고 진화했습니다. 최악의 경우 컨설턴트, 2일 오프사이트, 그리고 3주까지 아무도 사용하지 않은 아름답게 설계된 보드가 관련되었습니다.

실제로 있는 팀으로 시작합니다, 실제로 가진 작업으로 시작합니다. 3개의 열을 만듭니다: 백로그, 진행 중, 완료. 팀과 30분을 소비하여 현재 모든 작업 항목을 카드에 넣습니다. 한 가지 규칙에 동의합니다: 뭔가를 시작할 때, 그것은 보드에 갑니다. 이동하면 카드를 이동합니다. 2주 동안 다른 작업을 하지 마세요.

2주 후, 함께 보드를 보세요. 일은 어디에 쌓였습니까? 무엇이 백로그에 남아있었는데 모두가 우선순위라고 말했습니까? 예상보다 빨리 움직인 것은 무엇입니까? 갇혀있던 것과 이유는 무엇입니까? 관찰한 내용을 사용하여 열을 개선하고 특이성을 추가합니다. 아마도 "진행 중"을 "진행 중" 및 "외부 대기"로 나누어야 합니다. 아마도 "검토 중" 열이 필요할 수도 있습니다. 보드는 방법론 책이 말하는 것이 아니라 실제 업무가 드러내는 것에 대응하여 진화하도록 하세요.