우리 팀에 스크럼을 적용했어요 - 1편

2009/10/12 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 1편
2009/10/13 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 2편
2009/10/19 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 3편
2009/10/28 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 마무리
2009/12/12 - [Agile Experience] - 회고 : 스크럼 돌아보기
2010/01/21 - [Agile Experience] - 팀 자리를 이동하고 스크럼을 위한 War Board도 이동했습니다!

은근 슬쩍 시작하기

나와 아주 친한 연구원(L씨)는 니코틴 충전시간을 활용하여 현재 우리 팀의 문제점에 대해 고민하였다.

우리 팀은 전형적인 한국의 개발팀과 대동소이했다.

• BMT 준비로 인한 잦은 밤샘
• 빈번히 변경되는 요구사항
• 유지보수 지원으로 인한 신규 프로젝트 지연

그와중에 알게된 해결책 중의 하나가 스크럼이었다. 방법은 매우 단순 했다. 

(스크럼에 대해 알기 : Agile Process, SCRUM!!! 호기심 탐구 결과 by YUZI)

우리는 금방이라도 팀에 적용할 수 있을 것 같은 환상에 빠졌다. 

결국, 둘이 협공하여 팀장님을 설득하였다.

적용 첫주에는 티타임을 가장하여 은근 슬쩍 데일리 미팅을 진행하였다. 

물론 스크럼, 제품 백로그, 스프린트 등의 전문 용어는 일체 사용하지 않았다.

출근시간이 자유롭기 때문에 한번에 모이기가 힘들어서 데일리 미팅의 시간은 매우 유동적이었다.

팀원들이 데일리 미팅에 익숙해 질 쯔음(약 일주일정도 지난) 스크럼에 대해 언급하기 시작하였다.

팀 서고에 스크럼 관련 책을 비치 하였으며 독서를 독려하였다. (하지만, 실제 책을 읽은 사람은 매우 적었다.)

• 스크럼 : 팀의 생산성을 극대화 시키는 애자일 방법론 (Ken Schwaber, Mike Beedle)
  
• 스크럼과 XP : 애자일 최전선에서 일군 성공 무용담 (헨릭 크니버그)
  

개인적으로 "스크럼과 XP" 책이 더 따라하기 쉽다고 생각한다.

첫번째 스프린트 회의

얇은 지식을 바탕으로 첫 스프린트 회의를 개최하였다. 프로덕트 백로그는 엑셀로 정리하였다.

프로덕트 백로그 하나씩 짚어가며 정리하다 보니 시간이 매우 오래걸렸다. 

2시간이 걸렸음에도 반도 끝내지 못하고 다음 날을 기약한채 회의를 종료하였다.

(스프린트 기간을 4주로 결정하는 것 조차 오래걸렸다.)

그 결과, 스크럼 도입에 회의적이었던 팀원들은 여러가지 불만을 토로하였다.

"저의 작업 진행 방식(요구사항 검토하고, 개발 계획 및 스케쥴링을 하는)과 크게 차이를 못느끼겠습니다. 

왜 이걸 해야 하죠?"

이유는 간단 했다. 서로 잘 알지 못하면 서로 도움을 줄 수 없기 때문이다. 

(하지만 그당시 난 상대방을 적절히 설득하지 못하였다ㅠㅠ)

결국, 회의 이후에 팀장님께서 일일이 스프린트 백로그를 정리하셨다. OTL

본격적인 스프린트 진행

매일 시간은 달랐지만 하루도 빠지지 않고 데일리 미팅을 진행하였다.

팀원은 8명이었고, 평균 진행 시간은 20~25분이었다. 

고정된 데일리 미팅 시간 갖기, 평균 진행시간을 20분 이하로 줄이기 위해 노력하였으나 실패하였다.

이유는 불행히도 우리 팀은 "개인의 자유"라는 가치를 매우 크게 생각했기 때문이다. (팀장님 포함)

가치에 기반하지 않은 실천방법은 어떤 방법으로도 설득하기 힘들다는 것을 깨달았다.

데일리 미팅에서 언급되는 내용은 한 팀원이 팀내에 비치된 화이트보드에 작성하였다.

백로그별 예측되는 남은 시간은 팀장님이 엑셀을 통하여 정리하였다.

이때까지만 해도 업무 담당자의 의도와 작성자(화이트보드 혹은 엑셀)의 정리 내용에 차이가 발생할 수 있음을 알지 못하였다.

엑셀로 정리한 스프린트 백로그

데일리 미팅에서 가장 어려웠던 점은 "예측되는 남은 시간"만을 적는 것이었다. 

우리는 왜 남는 시간만을 남겨야 하는지 이해하지 못했다.

그리하여 우리는 남은 시간을 예측하지 않고, 최초 예측 시간에서 실제 작업시간을 뺀 값을 정리하는 쪽으로 의견을 모았다.

실제 작업 시간을 남김으로써 프로젝트를 제대로 관하고 있다는 느낌과 그 히스토리를 통해서 무언가 피드백을 받을 수 있다는 상상은 쓸모없는 것임을 매우 나중에 깨달았다.

마지막으로, 나는 팀내 스크럼 도입을 주도하면서 내 지식 혹은 직감을 남에게 전달하는 것이 얼마나 어려운 일인가를 다시 한번 깨닫게 되었다.

다음 편에서는 스크럼 도입 중기에서 겪었던 일들을 정리해보겠습니다. 감사합니다. ^^