회사에 조인한지 얼마 되지 않아 한 프로젝트의 난항을 해결하기 위한 회의에 초대됐다. 소프트웨어 팀 전원이 투입되어 반년 이상 진행해온 프로젝트가 결과물을 내놓지 못하고 또다시 일정을 연기하게 된 것이 우려를 샀기 때문이었다. 회사는 상황을 해결할 수 있는 뭔가 근본적인 대책을 바라며 회의를 소집했고 나는 오가는 대화를 들으며 즉각적으로 몇 가지 궁금한 부분이 생겼다.
분위기상 이 질문에 대해 아무도 답을 갖고 있지 않다는 걸 눈치챘기 때문에 아무런 말을 하지 않았다. 많은 인원들이 참여한 긴 논의 끝에(다소 급하고 자연스럽지 않은 과정을 거쳐) 스크럼을 도입하고, 스크럼 팀을 꾸리고 이끌어가는 역할을 맡으라는 제안을 받았다. 애자일은 이렇게 시작하면 안 된다고 하였건만..
스크럼의 아이콘(?)이라고도 할 수 있는 데일리 스크럼부터 시작했다. 나는 방법론의 폐해를 우려했기 때문에 무엇이든 규칙을 제시하는 것이 조심스러웠다. 첫 데일리 스크럼에서 한 분이 서 있기 불편하다고 앉아서 하자고 의자를 끌어당겼다. 하지만 다른 누군가는 회의를 짧게 진행하기 위해 서서 하는 게 좋겠다고 했다. 스크럼을 경험을 해 본 누군가는 각자가 어제 한 것, 오늘 할 것, 방해요소라는 세 가지 내용을 공유해야 한다고 설명을 하기도 했고, 스탠드업 미팅을 슬랙에서 진행할 수 있도록 도와주는 서비스를 찾은 분은 그것으로 대체하자는 제안을 하기도 했다.
위의 의견들은 팀이 어떻게 공감하느냐에 따라 반영이 가능한 것들이지만 나는 그때 팀의 상황을 볼 때 데일리 스크럼을 통해 얻을 유익이 일보다는 사회적 작용인 것 같다고 생각해서 채팅으로 대체하는 것은 우려된다고 했다. 나도 갓 입사한 상태였지만 개발 조직도 팀 구성이 된 지 얼마 되지 않았고 첫 프로젝트를 진행하고 있는 상황이었기 때문이다.
팀은 태스크 관리 시스템으로 MS 제품을 사용하고 있었는데 실제로는 티켓을 생성하지 않고 진행되는 일도 많았고, 주기 안에 해야 할 일감들을 선정하고 관리하는 체계 역시 없었다. 나는 데일리 스크럼에 참석해서 팀원들이 하고 있는 업무들을 손으로 노트에 받아 적기 시작했다.(지금 생각해도 이걸 어떻게 했는지 모르겠다.) 그리고 자리에 돌아오면 그것을 시스템에 생성된 티켓들과 대조하는 과정을 거쳤다. 누락이 있으면 추가를 요청하고, 내가 받아 적은 내용과 티켓의 상태를 비교해보았다. 그리고 그것을 다시 스프레드시트에 옮겨서 모니터링했다. 사용 중인 시스템에는 그런 값들을 저장할 수 있는 기능이 있긴 했지만 전혀 사용하고 있지 않았으므로 팀의 행동을 바꾸기 전에 내가 필요한 정보를 쌓으려고 했다.
이 과정을 통해 소프트웨어 개발 과정을 '알 수 있는 것'으로 만들기 위해 노력하는 분위기가 생겼다. 한 달 정도 지난 후엔 스프린트 형식도 도입되었고 티켓 관리 정책과 스크럼 팀의 건강 상태를 알려주는 주요 지표들의 관리에 신경을 쓰는 방향으로 팀원들의 의식이 움직였다. 어느 날 데일리 스크럼에서 우리가 파악한 지표들로 어떻게 종료일을 추정했는지를 설명하자 한 분이 혼잣말처럼 중얼거렸다. "정말 합리적이다.."
프로젝트가 어느 정도의 일정을 필요로 하는지 추정을 하기 위해서는 일단 전체 업무를 알아야 한다. 일반적으로 기획자가 있는 프로젝트에서는 기획 리뷰라고 불리는 시간을 통해 기획된 내용을 이해하고 그것을 시스템에 반영하기 위해선 어떤 작업들이 필요한지를 분석해보는 시간이 필요하다. 이미 완성된 기획의 범위가 클수록 오차도 함께 증가하긴 하지만 이 과정에서 각 과제 단위의 추정 시간을 산출하고 팀의 추정 정확도와 포커스 팩터를 그 값에 반영하면 대략적인 추정치를 얻을 수 있다.
WBS를 작성해본다던가 스프린트 플래닝을 한다던가 하는 일이 없었으니 팀은 앞으로 어느 정도의 일정이 필요할 것인지를 단순히 '감'에 의존해서 파악할 수밖에 없었고, 그것이 수차례나 어긋나면서 결국 일이 이렇게 됐다. 이제는 모두가 추정의 필요에 대해 느끼게 됐고 우리는 긴 시간을 들여 그 작업을 했다.
일부는 '절대로 추가 티켓을 생성하지 말아야 한다'라고 주장하기도 했다. 하지만 해야 할 일이 발견되었는데 완고한 스프린트의 규칙을 내세워 그 일은 하지 말아야 한다고 하는 것은 일과 방법론의 주객이 전도된 상황인 것 같았다. 우리가 인정해야 할 것은 완벽한 계획이란 없으며 우리가 이 과정에 미숙했고 실제로 우리가 할 일에 대한 이해도도 낮았다는 것이다. 해야 할 일을 발견하는 과정이 스프린트 플래닝에서 모두 이뤄지면 좋았겠지만 그렇지 않은 현재의 모습을 받아들이고 필요한 과제들을 충분히 뽑아내고 수행하도록 했다.
스크럼 마스터로 나의 가장 큰 성취는 원하는 데이터를 얻기 위해 주도적인 방법들을 취하고 거기서 긍정적인 결과를 이끌어냈다는 것이다. 만약 이런 링크를 하나 채팅방에 던지고 팀을 소집해서 velocity, capacity, focus factor와 같은 지표가 필요하니 이런저런 데이터를 기록하라고 하고 툴 사용을 강제하고 스프린트를 즉각 도입하고 업무 방식을 바꿨다면 스크럼은 팀에 정착하지 못했을 것 같다. 거기서 내가 스스로 할 수 있는 방법을 찾아 필요를 증명하고 설득하고 공감을 만들어 낸 것이 긍정적인 결과를 가져왔던 것 같다.
개인이 과제와 자신의 퍼포먼스에 몰입할 수 있도록 환경을 구성한 것도 좋은 방향이었다. 시스템 대시보드에 팀의 번다운 차트를 게시하고, 각자의 추정 정확도를 볼 수 있도록 위젯을 추가하고, 정기적으로 스크럼 팀의 상태에 대해 리포트를 제공하고 개인적으로 성취에 관한 피드백을 함으로 팀원들이 자기목적적 상태에서 일할 수 있도록 도왔다. 내가 어디에 있고 어디까지 가야 하고 그 과정에서 무엇이 필요한지, 어떤 도움을 받을 수 있는지를 분명히 알게 하는 것보다 동기를 충분히 부여할 수 있는 방법은 없다고 생각한다.
사람들은 누구나 자신의 능력으로 조직에 기여하고 싶어 하며 필요한 환경이 갖춰지면 충분한 역량을 발휘할 수 있다고 가정한 것도 큰 도움이 되었다. 조직에서는 일이 제대로 진행이 되지 않으면 반사적으로 '그들의 능력'을 의심하게 되는 경우가 많다. 하지만 능력은 어떤 환경에 있느냐에 따라 크게 달라질 수 있다고 보고 그런 환경을 구축하는 데 집중한 것이 개인의 능력 유무를 판단하고 있는 것보다 나은 선택이었다.
그리고 이 프로젝트는 이제 끝이 났다. 처음 회의가 소집되었던 날이 '감'으로 추정한 개발 종료 예정일 즈음이었다는 것을 생각해보면 그로부터 약 3달의 시간이 더 필요했다. 굳이 스크럼을 취하지 않았어도 지금쯤이면 종료가 됐을지도 모르겠다. 하지만 스크럼은 우리 스스로와 우리가 하는 일을 더 정확하게 볼 수 있는 힘을 길러주었으니 단순히 일이 되고 말고는 부차적인 성과 중 하나라고 생각할 만하다.
