스크럼과 기민함의 본질 서문

DALL.E 가 이 글을 읽고(?) 그려준 썸네일

 

개발을 막 배우기 시작했을 때 정보처리 국가 공인 시험을 준비하면서, 나선형 개발 프로세스, 애자일이라고 불리우는 개발 프로세스를 처음 알게 됐었다. 개발자로서 첫 취업을 준비하면서는, 당시 우아한형제들이었던것으로 기억하는데, 추천 도서 목록이 주어졌던 것으로 기억한다. 그 외에 많은 개발쪽의 구루라고 하는 사람(주로 페이스북 인플루언서)들이 추천하는 많은 책들이 애자일에 관한 내용을 다루고 있었던 것으로 기억한다. 그렇게 소프트웨어 업계에서 일하는 방식이 일반적으로 그렇다라는 것을 알게 됐었다.

 

애자일의 본질부터 이야기하고 가자면, 짧게 반복되는 주기마다 가치를 더하는 것이 애자일의 핵심이자, (앞으로 이 블로그에서 애자일과 스크럼에 이야기 하게 된다면) 이것이 하고 싶은 이야기의 전부이다. 개발 프로세스가 짧은 반복 주기를 가져야 하는 것은 빠른 피드백을 받기 위해서다. 가치라는 것은 다양하게 정의할 수 있겠지만, 기업에서 제품을 개발하는 입장에서의 정의는 '고객에게 제공된 가치를 통해 수익이 창출'될 수 있어야 한다.

 

보통 폭포수 모델과 비교되며, 개발자의 이상향처럼 애자일이 이야기되곤 했던 것 같다. 그래서 상징적으로 애자일을 개발자들의 핑곗거리로 전락시키는 경우도 많이 봐왔다. 개발자들 스스로든, 개발자와 함께 일하는 유관 부서든 그 시각은 어디서나 존재했다. 그 와중에 '애자일을 앞세워' 일을 하는 구성원들이 애자일 또는 스크럼이라는 대상에 대해 공통된 정의라도 가지고 있었다면 한결 나았을 것 같은데, 슬프게도 조직 구성원 대부분은 애자일과 스크럼을 제대로 이해하고 활용하고자 하는 의지가 없다는 것도 알게 되었다.

 

그렇다면, 조직에 애자일, 스크럼 전문가가 있다면 어떨까? 아마 전문가니까 조직에 그런 문화를 제대로 이식해줄 수 있으리라고 막연히 상상해보곤 했다. 수년이 흐른 지금, 그런 문화를 갈망하는 조직 자체의 열망이 중요하단 사실을 여러 주변 사례들을 통해 점점 명확하게 느껴 가고 있다.

 

'출근했더니 스크럼 마스터가 된 건에 관하여'라는 책이 있다. 내가 딱 그랬다. 어느 날, 회의실로 불려 들어간 나는 스크럼 마스터라는 직책을 맡게 된다. 처음에는 그저 데일리 스크럼을 주도하고, (약간은 팀장처럼 팀원들을 매니징하는 일을 곁들여서) 스프린트 리뷰 회의를 준비하여 진행하는 것이 전부라고 생각했다.  그러다가 수개월 동안 사용하고 있던 개념이 실제로는 다른 걸 의미하는 개념이었다는 것을 알게 되었었다. 이를 계기로 스크럼의 요소들의 정의를 알아보기 시작했는데, 그 용어뿐 아니라 전반적으로 잘 못 이해하고 사용하고 있는 용어나 개념이 은근히 많다는 사실까지 알게 되었다. 용어가 제대로 정의되지 않은 상태에서 이루어지는 커뮤니케이션은 모래 위에 지은 성과 같아서, 그렇게 이루어진 합의는 언제든 무너질 수 있기에 용어의 정의는 매우 중요하다. 나름 스스로를 이성적인 사람이라고 생각하는 걸 자존감의 원천으로 삼던 캐릭터인 탓에, 용어를 잘못 사용하고 있었다는 사실은 개인적으로 꽤 충격이었다. 그래서 개발 자체와는 어느정도 거리가 있음에도 '진짜 스크럼 마스터'가 되어보기로 결심을 했다.

 

주변에 애자일을 제대로 하고 있다는 사람을 만날 기회는 없었기에, 애자일을 제대로 이해하기 위해 할 수 있는 최선은 애자일 선언문을 그냥 외워보는 것이었다. 나는 애자일의 4가지 원칙을 '공포계획'이라고 앞글자를 따서 다른 사람들에게 소개하는 걸 좋아한다. 실제로도 이걸 외우고 나니 보이는 것들이 있었다. 그리고 회고 시간에 애자일 선언문을 근거로 더 많은 주장을 제시할 수 있었다.

 

스크럼은 애자일이라는 철학(?)을 구현해놓은 일종의 프레임워크이기에, 스크럼을 제대로 이해하기 위해서는 애자일 선언문을 먼저 이해할 필요가 있다. 이 4가지 내용을 현재 프로세스를 되돌아보는 데 체크리스트로 사용한다면 언제나 유효하다. 애자일 문화를 정착하고자 하는 팀에게 가장 먼저 해주고 싶은 부분이 있다면 바로 이 부분이다. 프로세스는 어떻게 운영해도 상관 없으니, 주기적으로 회고 시간을 갖고, 이 4가지만 원칙을 가지고 지난 프로세스를 판단해보라는 것이다.

 

회고 때 이런 상황을 그려볼 수 있다. 만약 스프린트 리뷰 회의가 장표 위주의 구두로만 전달되는 정적인 회의였다면, 회고 시간에 '동작하는 소프트웨어'를 직접 보여주는 게 필요하다고 주장해야 한다. 여기서 더 나아가, 리뷰 회의에 참여한 고객들(회사 내 제품 관계자 포함)이 제품 시연만으로 기능을 파악하기에 어려움이 있었다면, 이번에는 직접 제품을 사용해볼 수 있도록 데모 시간을 가져보자는 주장을 해볼 수도 있다.

 

애자일 선언문 자체를 팀 차원에서 자주 들여다보고 피드백 해보는 것 만으로도 매 주기마다 제품에 가치를 더하는 행위에 많은 도움을 줄 수 있다. '스크럼'  프레임워크는 애자일의 가치를 보다 실천적으로 실현할 수 있도록 도와주는 도구다. 스크럼을 잘 살펴보게 되면, 결국 애자일의 4가지 철학이 모두 담겨 있음을 알 수 있다. 종종 스크럼 프로세스만 좇다가 애자일의 본질을 놓치는 경우도 많은데, 이런 상황이 발생했을 때 애자일의 본질을 놓치지 않도록 균형을 잡아 주는 역할이 스크럼 마스터다.

 

지금은 스크럼 마스터를 하지 않고 멀찌감치 떨어져서 침을 튀기고 있지만, 팀의 프로세스를 가이드해줄 수 있으리라고 (스스로) 생각하여, 가끔은 기민함이라고 번역되는 애자일과, 스크럼에 대해서 이야기를 해보려고 한다.