[Agile] 칸반

애자일로 가는 또 다른 길, 칸반

데일리 미팅

• 1주~2주 등 스프린트
  • 관리자, 경영자들이 이런 걸 원함
    • 나한테 이런 걸 보여줘
  • PO, 스크럼마스터
• 애자일이란 단어를 들었을 때 스크럼
  • 스크럼은 애자일이다?
    • 그렇지 않다.
• 우리에게 맞지 않은 스크럼을 도입하고
  • 애자일은 맞지 않다. 라는 생각을 할 수 있다.
    • 애자일 != 스크럼

• 스크럼이 맞지 않다면 칸반이라는 방법이 있다.

• 애자일을 도입할 때 가장 큰 장애물?
  • 변화에 대한 저항 48%(State Agile의 2021 조사)
    • 문서를 안만들고 업무하는 방식에 대해 어떻게 될 것인가?
    • 매일 스크럼을 하면 어떻게 대응할 것인가?

개발자들의 나쁜 습관

• 소통이 안되면?
  • 대화를 한다던지, 중재자를 구한다던지?, 인터렉션해본다던지
• 좋은 툴 없는지 찾는다.

애자일의 철학

• 점진적으로 적용하는 것
  • 환골탈퇴 변경할 수 없는 우리의 일

스크럼이 좋은 환경이 있고 안좋은 환경이 있다.

• 칸반은 상대적으로 그렇지 않음

스크럼 가이드

• 스크럼의 핵심 설계와 발상을 변경하는 경우, 특정 요소를 배제하는 경우 또는 스크럼 규칙을 따르지 않는 경우에는 어떤 문제가 있는지 알 수가 없고 스크럼의 이점을 충분히 살릴 수도 없다. 심지어 스크럼을 쓸모 없는 것으로 만들 수도 있다.

• 스크럼 프레임워크는 변경할 수 없다. 스크럼의 일부만을 시행하는 것은 가능하지만, 그것을 스크럼이라고 할 수는 없다. 스크럼 가이드를 완전히 수행하는 것만 스크럼이라 할 수 있다.

스크럼의 적용은 애자일하지 않다.
처음 적용하는 것은 어렵다.
하지만 스크럼은 유연하다.

Framework vs Method

• Framework == Reconstruction
  • 재건축
• Method == Renovation
  • 원래 있던 것에 확장
• 스크럼(Framework)
  • 워터풀 방식으로 업무를 진행했다면 모두 변경해야하기 때문에 적용이 어려움
• Method(칸반)
  • 변화의 과정이 점진적이다.
• 스크럼이 쉽지 않은 환경
  • 많은 고객의 목소리
    • 버그 리포트
  • 경영진의 많은 요구사항
  • 프로젝트 단위와 조직의 단위가 일치하지 않을 때

칸반에 대한 흔한 오해

• 칸반이라고 하기 어려운
  • 지라의 칸반 보드
    • 지라의 장점
      • 개인에게 task를 할당하고 관리하기 좋음
    • 지라의 단점
      • 팀단위의 우리팀의 상황을 보기는 어려움
  • 칠판의 포스트잇
    • 화이트보드에 포스트잇 붙이면 칸반 아니에요?
    • 현황판 하나 만들자고 굳이 공부까지 해야 되나요?
    • 아! 저 칸반 잘 알아요 Jira에서 칸반 기능 사용해 봤어요. 트렐로도 써봤고요.
    • 간판(또는 간반) 시스템은 제조업에서 사용하는 거 아니에요?

여담이지만 지라 회사인 Atlassian도 지라를 모두 활용하지 않고 칠판의 포스트잇을 사용한다고 한다.

• 칸반 보드 != 칸반
• Jira != 칸반
  • 칸반의 기능은 있으나 전문적인 칸반을 활용하기는 어렵다.
• 도요타 칸반 != 칸반

칸반 메소드의 정의

• 지식 업무를 관리하는 “방법”
• 업무를 관리하고 개선하는데 도움이 되는 “원칙 및 실철법”을 함께 제공
• 업무 및 그 흐름을 시각화 하는데 “칸반 보드”를 사용하며
• 업무가 원활하게 흐를 수 있도록 진행 중인 업무의 양을 제어하는 “칸반 시스템”을 사용

칸반 메소드의 기원

• 도요타의 린 제조에서 깊은 영향을 받음
• David J. Anderson 이 2004~05년에 마이크로소프트에서 첫 시도
• 칸반 메소드는 지식 업무에 적용되어 왔음
• 현재는 다양한 서비스 업계에서 활용되고 있음

칸반 적용 시 주의 사항

• 평소에 이상적으로 생각했던 프로세스를 추가 하지 않는다.
  • 일단 현실의 프로세스를 반영한다.
  • “이게 있었으면 좋겠다” 라는 것을 추가하지 않음
    • 실제 사람들이 프로세스를 옮겨야 할 때 혼란이 오며 악순환 반복
• 칸반보드의 항목은 쉽게 변경할 수 있어야 한다.
• 내 영역에 대한 Visualization을 하고 범위를 조금씩 넓혀나가야 한다.
  • 특히 모르는 업무의 영역을 보드를 관리 할 경우

칸반의 6가지 일반 실천법

• 업무 및 프로세스를 칸반 보드에 시각화한다.
  • 가장 중요
  • 온라인/오프라인 싱크를 맞춰서 활용하기도 한다.
  • 매크로한 관점/마이크로한 관점을 볼 수 있으면 더 좋다.
    • 전체적인, 세부적인 업무를 볼 수 있어야 함(Zoom 기능이 있다면 더 좋다.)
• 진행 중 업무(WIP)를 제한하며 밀기 방식을 당김 방식으로 바꾼다.
  • 동시에 진행 중인 업무를 줄인다.
• 고객 가치 전달을 최대화하고, 리드 타임을 최소화하며, 예측성을 높일 수 있도록 흐름을 관리한다.
  • 측정과 지표
    • 업무 유입 경로, 업무가 머무르는 시간, 처리되는 시간 등
• 정책을 명시화하며 프로세스를 분명하게 설명하고 정의한다.
  • 사람이 변경되면 규칙들이 변경되게 된다.
    • 합의한 규칙을 시각화하여 사람이 변경되더라도 유지하도록 한다.
• 다양한 피드백 기회를 적절한 케이던스로 실행하는 피드백 루프를 만든다.
  • 회의 방식
  • 스크림 스프린트를 2주에 한번 하기로 했다면, 칸반은 그 케이던스를 따로 가져갈 수 있다.
    • ex) 스프린트는 2주에 한번, 플래닝은 1주에 한번, 회고는 4주에 한번
• 현재 상태 그대로 시작해서, 함께 개선하고 실험을 통해 프로세스를 발전시킨다.
  • 팀내의 일하는 방식을 점진적으로 바꾼다.

시각화한다.

• 좋은 시각화는 효과적인 협업과 개선 기회의 탐색의 핵심이다.
• 대부분의 조직에서는 업무가 눈에 보이는 것이 아니기 때문에, 업무와 그 업무의 흐름을 시각화하면 투명성을 크게 높일 수 있고, 모든 이들이 같은 그림을 볼 수 있도록 해준다.
  • 이슈를 시각화하고, 공론화 한다는 것은 팀원 입장에서는 용기가 필요한 일이다.
    • 이 용기를 알아주는 리더 또한 필요하다.
• 업무와 관련된 거의 모든 것을 시각화 할 수 있다.
• 평소에 희망하던 바람직한 모습이 아니라, 진짜 현재 상태를 현실적으로 시각화한다.

가장 기본적인 칸반 보드 패턴

• 선택(TO-DO)는 backlog
• 우리팀에 맞는 보드는 직접 만들어야 한다.
• 프로세스의 단계가 있다.
• 포스트잇의 색깔이 다른 것이 있다.
• 모르는 업무이지만 협업을 해야하는 업무라면 빈 공간을 두어 (Planning, Dev Ready) 등의 항목을 두어도 좋다.

칸반 보드 티켓 색상으로 업무를 구분

• 파란색
  • 긴급한 업무
  • 보드 위에 파란색이 많다면 위험 신호
• 노란색
  • 기본 티켓
• 빨간색
  • 외부의 요소에 의해 지연되고 있음
• 사소한 업무(진행하는데 1시간 업무 등)은 스티커등을 통해 칸반보드 외 공간을 통해 체크하도록 한다.