블로그 리스트
이 블로그 포스트는 시리즈로 작성되어 있습니다. 다른 내용을 확인하고 싶으신 분들은 아래에 링크를 참고하시기 바랍니다.
- 목차
- (1) 스크럼, 칸반 그리고 도구
- (2) 역할, 이터레이션 그리고 WIP 제한
- (3) 고유의 프로세스, 할일 추가, 보드 초기화
- (4) 교차 기능 팀, 작업 쪼개기, 측정하라 그리고 예측하라
- (5) 일일 미팅, 업무 프로세스의 최적화, WIP 제한을 잘 이용하자
- 칸반과 스크럼을 읽고 나서
고유의 프로세스
스크럼과 칸반은 둘 다 경험적이다. 스크럼과 칸반을 사용하여 업무 프로세스를 운영하고 있다면, 기본적으로 이 프로세스를 실험해 보고 환경에 맞게 프로세스를 수정하기를 기대하기 때문이다. 스크럼과 칸반은 모든 정답을 제공하지 않는다. 단지, 기본 프로세스와 방법론을 제공하고 있기 떄문에, 우리는 스크럼과 칸반을 사용하여 현재 상황에 맞게 프로세스를 개선해야 한다.
책에 있는 예를 들면 다음과 같다.
- 스크럼은 교차 기능 팀을 운영해야 한다고 말한다. 그렇다면 누구를 어떤 팀에 배치해야하는가? 알 수 없다. 실험해 봐야 안다.
- 스크럼은 한 스프린트에서 해야 할 일의 양을 팀이 선택한다고 말한다. 그렇다면 얼마나 가져야 하는가? 알 수 없다. 실험해 봐야 안다.
- 칸반은 WIP를 제한해야 한다고 말한다. 그렇다면 얼마로 제한해야 할까? 알 수 없다. 실험해 봐야 안다.
칸반은 스크럼에 비해 제약 사항이 적다. 이는 우리가 칸반을 사용하여 프로세스를 만든다면, 스크럼에 비해 생각해야 할 것들이 더 많다는 것을 의미한다. 이는 장점이 될 수 도 있고, 단점이 될 수 도 있다.
소프트 웨어 도구의 설정 대화창을 열었을 때 조절할 수 있는 옵션이 3개인 것과 100개인 것 중 어떤 것을 선호하는가? 십중 팔구 그 사이 어딘가일 것이다. 조절할 필요가 있는 것이 얼마나 있는지, 그리고 도구를 얼마나 잘 이해하고 있는지에 따라 다를 것이다.
일단 우리는 우리의 프로세스가 개선될 것이라는 가설을 세워야 한다. 그리고 WIP 리밋을 줄여보고, 처리 용량, 리드 타임, 품질 등이 어떻게 바뀌는지 관찰해야 한다. 그 결과를 바탕으로 다른 것들을 변경해 보면서 지속적으로 우리의 프로세스를 개선해 나아가야 한다.
이를 일컫는 말로 린의 지속적인 개선을 의미하는 카이젠, 스크럼에서의 관찰과 적응, 경험주의적 공정 제어 또는 과학적인 방법들이 있다.
여기서 핵심은 피드백 루프이다.
- 피드백 루프: 무엇인가 변경한다 > 관찰한다 > 학습한다 > 다시 변경한다.
일반적으로 피드백 루프가 짧을 수록 프로세스를 빨리 적응 시킬수 있다고 한다. 스크럼에서는 기본적으로 스프린트가 피드백 루프의 역할을 한다. 칸반에는 피드백 루프를 정의하고 있지 않다. 하지만 칸반에서도 피드백 루프는 필요함으로 우리는 스크럼의 스프린트와 같은 피드백 루프를 칸반에 넣어야 한다.
칸반에서는 다음과 같은 지표를 알 수 있다.
- 평균 리드 타임: 아이템이 “완료”에 도달할 때마다 갱신
- 병목 지점: 한 컬럼에 아이템이 잔뜩 들어있는 전형적인 증상
칸반에서는 이런 지표를 사용하여 피드백 루프를 만들 수 있으며, 프로세스를 개선할 수 있다.
칸반 실험의 예
책에서 나온 칸반 실험의 예를 간략히 옮겨 적어본다.
칸반에서 조절 항목중 하나는 WIP이다. 그럼 현재 프로세스가 우리에게 적합한지, WIP는 몇이 정확한지 어떻게 알 수 있을까? 우선 실험을 위해 WIP를 1로 줄여본다고 가정해 보자.
WIP를 줄여보니, 팀원들이 모두 함께 작업하지 않아도 되는 일들이 있어 일을 하지 않고 쉬는 팀원들이 생겼다. 이런 일들이 가끔 생긴다면, 큰 문제가 없지만, 정기적으로 자주 발생한다면, 평균 리드 타임이 증가하게 될 것이다.
WIP 1은 아이템이 들어오면 아주 신속하게 “진행 중” 칼럼을 통과한다는 것을 의미하지만, 필요 이상으로 “할 일” 칼럼의 정체를 초개할 것이고, 결국 전체 워크플로 상의 총 리드 타임은 불필요하게 높아질 것이다.
그렇다면 WIP를 8로 증가 시켜보면 어떨까?
잠시 동안은 이전보다 나아진 것을 알 수 있었다. 계속 관찰한 결과 평균적으로 팀원 2명이 짝을 이뤄 작업하면 일이 더 빨리 끝난다는 것을 발견했다. 따라서 팀원이 4명인 이 팀은 “진행 중” 아이템에는 통상 2개의 아이템이 존재하게 된다. WIP는 상한선에 대한 제한이므로 그보다 적은 것은 괜찮다.
그러나 통합 서버에 문제가 발생하여 어떤 아이템도 “완료”로 이동 시킬 수 없는 상황이 발생했다고 가정해 보자.
통합 서버에 문제가 발생하여 D나 E 아이템을 완료할 수 없어서 팀원들은 “할 일”에서 F와 G를 “진행 중”으로 가져와 작업을 하였다. 하지만 여전히 통합 서버에 문제가 있으므로 F와 G도 “완료”로 이동 시킬 수 없다. 이런식으로 반복적으로 “할 일”을 가져오게 되면 WIP의 리밋에 도달하게 된다.
이제 더는 “할 일”을 가져올 수 없으니 통합 서버의 문제를 해결해서 “진행 중”인 아이템들을 “완료”로 옮겨야 한다. 이렇게 WIP 리밋은 병목 지점을 찾고 해결할 수 있도록 유도해 준다.
하지만, WIP가 4였다면, 8이였을 때보다 훨씬 빨리 통합 서버의 문제를 대응할 수 있었지 않았을까? 이를 위해 WIP를 4로 줄여서 프로세스를 최적화할 수 있다.
현재 프로세스가 최적화되었다고 생각할 수 있지만, 어느 순간 “할 일” 칼럼에 아이템이 많이 쌓이는 것이 확인 되었다. 그럼 이제 WIP 리밋을 조절하여 “할 일” 칼럼의 아이템이 쌓이지 않도록 해야할 순간일 수 있다.
이 세상에는 무수한 프로젝트와 무수한 환경, 각기 다른 멤버들이 존재한다. 이 모든 상황에 완벽하게 맞는 하나의 도구는 존재하지 않는다. 스크럼과 칸반이 모든 프로젝트에 완벽하게 맞는 도구도, 모든 프로젝트에 완벽한 정답을 제공하는 것도 아니다.
실험하라! 또는 스크럼 연구자가 말하듯이, 관찰하고 적응하라!
우리는 현재 상황에 필요한 도구를 선택하고, 그 도구가 현재 상황에 맞지 않는다면 고치고 수정해서 사용해야할 것이다.
할일 추가
스크럼과 칸반에서 새로운 할일을 추가하는 방법에 대해서 살펴보자.
스크럼에서 할일 추가
예제로 소개할 스크럼 보드는 다음과 같다.
만약 누군가 스크럼 보드에 “E” 아이템을 추가하려고 하면, 전형적인 스크럼 팀에서는 다음과 같이 말할 것이다.
“죄송하지만 안됩니다. 우리는 이번 스프린트에 A, B, C, D를 하기로 승인받았습니다. 하지만 제품 백로그에 E를 넣는 것은 괜찮습니다. 제품 책임자가 E에 높은 우선순위를 둔다면 다음 스프린트에서 우리가 가져와서 작업할 수 있습니다.”
적절한 길이의 스프린트는 뭔가를 완료할 수 있도록 집중할 수 있는 충분한 시간을 팀에 제공한다. 또한 제품 책임자에게는 여전히 장기적으로 우선 순위를 갱신하고 관리할 수 있게 한다.
스크럼에서 응답 시간은 평균적으로 스프린트 길이의 절반이다.
스크럼에서는 제품 책임자가 스크럼 보드를 건드릴 수 없다. 이는 해당 이터레이션 내에 특정 아이템을 진행하기로 팀과 약속했기 때문이다.
칸반에서 할일 추가
예제로 소개할 칸반 보드는 다음과 같다.
만약 누군가 칸반 보드에 “E” 아이템을 추가하려고 하면, 칸반 팀은 다음과 같이 말할 것이다.
“할일 칼럼에 자유롭게 E를 추가하세요. 하지만 그 칼럼의 리밋이 2이므로 그 경우에는 C나 D를 제거해야만 합니다. 우리는 지금 A와 B를 작업하고 있지만 여력이 생기는 대로 할일 칼럼의 우선순위가 가장 높은 아이템을 당겨올 겁니다.”
칸반에서 응답 시간은 여력이 생기는데 걸리는 시간으로, WIP 리밋 원칙에 의거하여 한 아이템이 빠져나감 = 한 아이템이 들어옴이 된다.
칸반에서는 누가 보드의 내용을 변경할 수 있는지 고유의 기본 규칙을 설정하는게 좋다. 전형적으로 제품 책임자는 “할일” 또는 “준비”, “백로그”, “제안” 같은 맨 왼쪽 칼럼을 할당받는데 이 칼럼은 원할 때마다 변경이 가능하다.
하지만 필요하다면 할일 추가 규칙을 변경할 수 있다. 스크럼에서는 일반적이진 않지만 제품 책임자가 스프린트 중간에 스프린트 백로그의 우선 순위를 변경할 수 있게 한다던지, 칸반에서 우선순위를 변경하는 결정을하는 타이밍을 제약하는 항목을 추가할 수도 있다. 또한 칸반에서 스크럼처럼 이터레이션 도입과 이터레이션 내에 할 일을 확정하는 스크럼 방식을 따를 수도 있다.
스크럼과 칸반의 기본 규칙은 중요하다. 하지만 스크럼과 칸반은 단지 도구일 뿐이고, 현재 상황에 맞지 않는다면 과감하게 변경할 필요가 있다. 현재 상황에 도구가 맞지 않는다고, 현재 상황을 억지로 도구에 맞추는 불상사는 피해야 한다.
보드 초기화
스크럼과 칸반에서는 모두 보드(스크럼 보드/칸반 보드)를 사용한다. 이 보드들이 언제 초기화되는지 살펴보자.
스크럼 보드 초기화
전형적인 스크럼 팀의 스크럼 보드는 다음과 같은 특징을 보인다.
새로운 스프린트가 시작되면 스프린트 계획 회의를 하고, 맨 왼쪽 열에 새로운 아이템들을 추가한 새로운 스크럼 보드가 생긴다. 한 스프린트가 끝나면 모든 아이템을 제거하여 보드를 정리한다.
기술적으로 보면 이러한 작업은 낭비이지만, 스크럼 경험이 쌓이면 이런 시간은 얼마 걸리지 않는다. 또한 보드를 초기화하는 과정에서 뭔가 완료했다는 기분이 들어 팀에 활력이 생길 수 있다.
칸반 보드 초기화
칸반에서는 일반적으로 보드 초기화가 이뤄지지 않는다. WIP 리밋에 맞추어 꾸준히 업무가 나열되므로, 초기화하고 다시 시작할 필요가 없다.
개인적으로는 칸반에도 리듬감을 만들 필요는 있는거 같다. 스크럼 보드가 초기화되면, 무언가를 끝냈다는 기분이 들고 팀에 활력이 생기는데, 업무 효율을 떠나 팀에 이런 달성감을 안기는 건 중요한 것 같다. 그러므로 칸반을 사용한다면, 정기적인 회의를 갖고 “완료” 칼럼을 비우면서 이런 리듬을 만드는 것을 추천한다.
인사이트
- 프로젝트를 진행하는 환경도 다르고, 멤버도 다르다. 이런 상황에 맞는 완벽한 도구는 존재하지 않는다.
- 스크럼과 칸반을 사용해서 실험하고, 업무 프로세스를 최적화하라. 물론 최적화를 위해 스크럼과 칸반의 사용법도 수정할 수 있다.
- 실험하라! 그리고 관찰하고 적응하라!
- 도구는 도구일뿐! 현재 상황을 도구에 맞추는 것이 아니라, 현재 상황에 맞게 도구를 변경해야 한다.
- 업무 효율을 떠나서 프로세스에 리듬감을 만들고, 팀에 달성감을 안기는 것은 중요하다.