---

협력하여 Kanban을 개선하고 실험으로 발전시키기

팀은 진정한 협력과 열린 실험을 바탕으로 자기 평가, 학습 및 개선의 문화를 만들어야 합니다.

장애물 해결은 Kanban 팀에게 예외적인 업무 상태가 아닙니다. Kanban은 오류를 애초에 일어나서는 안 될 잘못된 예외로 취급하지 않습니다. 오류는 조직과 기업 전체의 지속적인 학습 및 개선에 기여하는 일상 실천의 일부로 받아들여집니다. 팀은 해결한 문제와 해결책을 조직 전체에 투명하게 공개하고 쉽게 이용할 수 있도록 하여 그 효과를 배가합니다.

문제를 일으킨 사람을 손가락질하고 비난하며 모욕하는 대신 장애물을 드러내는 행동을 소중히 여깁니다. 팀원은 오류와 비효율에서 조직이 배우도록 장려하여 회사의 누구나 장애물, 해결책 및 노하우를 발견하고 이익을 얻도록 합니다.

구성원이 오류의 세부 내용을 알리는 데 안전함을 느끼면, 자기 작업 현장뿐 아니라 가치 흐름의 다른 현장에서도 비슷한 문제가 재발하지 않도록 기꺼이 더 노력하고 에너지를 쏟습니다. 엔지니어가 실수했을 때 처벌받거나 처벌받는다고 느끼기만 해도 실수를 두려워하게 됩니다. 최종 결과는 다음과 같습니다.

1. 실수를 줄이기 위해 활동을 적게 수행합니다.
2. 업무, 어려움 및 결과를 공개하지 않습니다.
3. 어려움의 해결책을 조직 학습으로 전환할 동기가 없습니다.
4. 문제와 해결책을 배우고 공유하고 알리며 드러내는 데 아무도 시간과 노력을 쓰지 않으므로 같거나 비슷한 문제가 반드시 반복됩니다.

사고에 관련된 팀원과 비즈니스 이해관계자는 다음을 온전히 받아들여야 합니다 "비난하지 않습니다. 우리는 배우기 위해 여기에 있습니다"라는 모델을.

많은 조직이 이런 안전한 업무 환경을 만들기 위해 상당한 노력을 합니다. 예를 들어 NASA는 FAA와 협력하여 항공 안전 보고 시스템을 운영합니다. 자발적인 안전 보고는 학습을 지원하며 조건을 충족하는 보고는 정해진 상황에서 제한적인 제재 보호를 받을 수 있습니다. 보고가 포괄적인 면책을 뜻하지는 않습니다. Kanban 조직도 투명한 업무 및 오류 문화를 위해 이런 장치를 만들어야 합니다.

Kanban 프로세스와 비즈니스 결과를 실험적으로 발전시키기

완성된 제품을 만들고 조직 전체에 모범 실천을 공유하기 전에 팀원은 다음을 물어야 합니다. "왜 이것을 만들어야 하지?", "시간과 자원을 쓸 가치가 있을까?". 프로세스, 제품 및 기능 개선 아이디어가 예상한 비즈니스 성과를 충족하는지 검증하기 위해 합리적인 범위에서 가장 빠르고 저렴한 실험을 만들고 수행해야 합니다.

직감과 지금까지 팀이 습득하고 관찰한 모범 실천에만 의존하는 대신, 실제 환경의 실제 사람이 실험에 참여하도록 하는 데 집중해야 합니다.

Kanban 프로젝트 관리자와 비즈니스 이해관계자는 제품 및 기능 아이디어와 프로세스 활용 개선 계획을 검증할 가설로 봐야 합니다.

가정을 계속 시험하고 결과를 점검하면서, 증거가 뒷받침하는 가설을 종합적으로 계획하고 개발하고 제공할 수 있습니다.