2장. 팀#6
#2-5 자신감(쇼케이스)
#2-5 자신감(쇼케이스)
앞선 몇 번의 프로젝트에서 애자일 방식으로 일한 뒤, 필자는 스스로를 책에서 본 스크럼 마스터라는 명칭으로 부르기 시작했다. 스크럼 마스터는 팀에 스크럼 프로세스를 지키도록 도우면서, 팀 내/외부 병목을 해결하는 역할이다. 당시 회사에서는 거의 모두에게 익숙하지 않은 호칭이었다. 하지만 스크럼마스터 역할은 개발 리더, 품질관리, 사업관리 등과는 분명히 다른 역할이었기에 다른 역할 호칭이 필요했다.
문제는 그러면서 스스로를 애자일 전문가라고 얘기했던 것인데, 열정이 지나쳤던 것일까...? 당시 필자는 모든 프로젝트를 애자일로 할 수 있다고 믿었다. 3개의 성공케이스를 만든 후 자신감이 컸다.
* 쇼케이스의 의미
쇼케이스는 필요한 이해관계자(Stakeholder)에게 동작하는 소프트웨어를 시연하는 것을 말한다. (때문에 고객 시연, 고객 데모 등으로도 불린다) 필자는 애자일 기법 중 쇼케이스가 '애자일 선언(2001년)'과 가장 애자일에 걸맞은 기법이라 생각한다. 이를 함께 생각해 보면 다음과 같다.
공정과 도구보다 개인과 상호작용을 → 쇼케이스를 통해 소프트웨어의 방향에 대하여 보다 직접적으로 의사결정자들과 소통할 수 있고,
포괄적인 문서보다 작동하는 소프트웨어를 → 쇼케이스를 통해 문서 중심으로 과정에 대해 고민하기보다 결과 중심 즉, 제품의 가치에 대해 얘기할 수 있고,
계약 협상보다 고객과의 협력을 → 계약에만 집착하기보다, 쇼케이스를 통해 제품의 실효성에 대해 토의하며 보다 협력적인 방향을 이끌 수 있으며,
계획을 따르기보다 변화에 대응하기를 → 쇼케이스를 통해 이해관계자의 관심사 변경이나 환경 변화에 따른 변경을 소프트웨어에 피드백으로 조기에 반영/적용할 수 있다.
하지만, 이 쇼케이스를 실제로 어떻게 해야 제품을 만드는데 도움이 되는지에 대해서는 이야기하는 전문가들이 국내에 거의 없다. 이를 시도하려는 분들을 위해 이번 사례를 통해 주의해야 할 점에 대해 이야기하려고 한다.
필자가 애자일을 처음 시작했을 때 당시, 애자일을 아는 사람도 실행해본 사람도 거의 없었다. 때문에 여러 애자일 책에서 제시하던 기법들을 맹목적으로 따라 했다. 필자는 운이 좋아, 그럼에도 불구하고 정말 좋은 쇼케이스를 할 수 있었다. 두 개의 팀 모두 우리는 2주 단위 8개의 이터레이션 내내 고객에게 시연을 했다. 2개의 팀은 격주로 번갈아가며 시연을 했다. 첫째 주 금요일에 한 팀이 하면 다음 주 금요일에는 다른 팀이 시연을 했다. 고객 시간이 행사나 휴가로 금요일 시간이 안 될 경우 다른 날을 잡았다.
[A 프로젝트 현황판 그림]당시 쇼케이스는 매우 성공적이었다. 동작하는 기능으로 데모를 통해 설명하기 때문에, 고객은 본인이 나중에 실제 사용자들에게 설명해야 하는 기능에 대해 정말 잘 이해하게 되었고, 개발팀이 하고 있는 일에 대해 투명하게 알고 있다고 이야기했다. 이는 고객과 개발팀 간의 신뢰로 이어지게 되었다.
한번 신뢰가 쌓이고 나니, 심지어 고객은 우리의 방패막 역할을 해주게 되었다. 가끔 다양한 이해관계자로부터 개발팀에 무리한 요구가 있을 때, 개발팀의 상황을 차근차근 설명하며 프로젝트의 성공을 위해 이를 막아주려고 애썼다.
심지어 개발팀 인력 한 명 한 명이 이 프로젝트 속에서 얼마나 배우고 성장하는지를 내게 설명한 적도 있었다. 그는 정말 이 팀을 아끼고 있었다. 자연스레 개발자들도 그를 좋아하게 되었고, 그와 함께 계속해서 일하고 싶어 했다.
* 쇼케이스의 함정(비즈니스 vs. 기능)
이 여세를 몰아 난 두 번째 프로젝트에서도 동일한 방식으로 쇼케이스를 진행했다. 두 번째 프로젝트의 전체 구성원은 20명 정도였으며, 9명과 11명의 두 개의 팀으로 나뉘어 있었다. 이 중 필자는 9명의 팀을 맡는 PL이었다. 당시 그들이 만드는 시스템은 6개의 공공기관에서 쓰고 있는 시스템이었는데, 각 기관마다 6명의 고객이 담당하고 있었다.
[고객사 공공기관 X의 담당자들과 개발팀의 구조 그림]이 6개의 기관은 5개의 공통 기능 업무를 수행하고 있었고, 필자가 맡은 팀은 이 5개의 기능 업무를 개발하는 팀이었다. 개발팀이 프로젝트를 시작하기 전 가지고 있던 비즈니스 가정(Assumption)에는 이 5개의 공통 기능 업무가 6개 기관에서 거의 동일하다는 것이었다. 개발팀은 6개 기관의 고민이 비슷할 것이라는 생각에 1개의 기관 화면을 중심으로 개발하고 시연한 뒤 다른 5개의 관화면을 개발하는 전략을 택했다.
쇼케이스를 할 때마다 6개 기관의 고객 모두를 불러야 하는 것부터 실제 문제가 불거졌다. 첫 쇼케이스 때부터 5개의 기능 업무가 공통이라는 가정이 잘못된 것이라는 것을 깨달았다. 6개의 기관은 거의 모든 기능에 각자의 다른 특성을 가지고 있었고, 이들을 각각 반영해야 했다. 첫 시연부터 요구 변경이 급격하게 늘어나기 시작했다.
[최초 대비 3배가량 늘어난 업무의 프로젝트 그래프 그림]개발팀은 당황하기 시작했다. 공공사업의 특성상 요구 변경이 늘어나도 기간이 늘어나거나 추가 계약을 하기 어려운 구조였기에, 개발팀은 시간이 갈수록 고객의 요구에 대해 방어적이 되고 있었다. 고객들은 자신들의 요구가 제대로 개발팀에 반영되지 않고 있다는 생각을 하게 되었다.
심지어, 쇼케이스를 진행할 때, 특정 기관에 집중되어 이야기가 진행되면 다른 5명의 고객들은 그들의 시간을 낭비하고 있다는 생각을 했고, 특정 기관에만 특별한 기능을 넣으려면 다른 5개의 기관에서도 비슷한 형태의 기능이 필요하다는 주장을 하기 시작했다. 이때마다 개발팀은 울상이 되었다. 고객들은 별도로 쇼케이스를 해달라고 요청했다.
쇼케이스를 할수록 고객과의 신뢰가 무너지기 시작했다. 이를 극복할 수 있는 유일한 방법은 정해진 기간과 공수하에서 많은 규모의 요구사항을 수용하는 것이었다. 결국 일하는 시간을 물리적으로 늘리기 위해 야근과 주말근무를 해야 했다. 프로젝트 종료까지 진행된 이 고단한 일들로 대부분의 프로젝트 팀원이 행복하지 않았다.
무엇이 문제인가? 과연 무엇이 잘못되었던 것일까? 우선 쇼케이스가 성공적으로 진행되려면 다음의 전제조건이 있어야 한다. (스크럼 프로세스에서는 제품 책임자(Product Owner)라는 역할로 위 3가지를 하는 담당자를 정의한다.)
기능 업무 단위가 아닌, 비즈니스 단위의 제품 책임자가 존재하고 이를 담당해야 한다.
제품 책임자는 1명이 가장 좋으며, 해당 업무에 대한 오너십을 가져야 한다.
제품 책임자의 성공이 개발팀의 성공과 동일한 것이어야 한다.
위 프로젝트는 5개의 기능 업무 조직으로 구성된 개발팀과 6개의 업무(비즈니스) 단위의 구성된 고객의 조직이 매트릭스로 엮어 불일치가 생기는 구조였다. 개발팀은 효율을 최대화하기 위해 기능 업무 단위로 인력을 나누었고, 계약을 진행한 고객은 예산을 줄이기 위해 이에 동의하였지만, 실제 실무 기관을 담당하는 다른 고객은 이에 동의할 리가 없는 구조였다.
또한 프로젝트 총책임자였던 특정 고객은 이들 6개 실무기관의 고객 담당자들과 사이의 좋은 관계를 유지하는 것을 프로젝트 성공보다 중요하게 생각했다. 때문에 그들이 쏟아내는 요구사항에 대해 제어하거나 이야기하며 설득하려고 하지 않았다.
결국 위의 세 가지 조건 중 아무것도 지킬 수 없는 구조였다. 이러한 경우 쇼케이스는 프로젝트에 매우 좋지 않은 영향을 줄 수 있다. 이 글을 읽고 그래도 쇼케이스를 통해 고객의 요구를 모르는 것보다 낫다는 주장을 할 분도 있겠으나, 첫 단추를 잘못 꿰어 놓은 상태에서는 그 단추를 풀지 않는 한 옷이 제대로 입을 수 없다. 이러한 상황에서 고객과 개발팀이 함께 실수를 인정하고 다시 계약을 하는 일은 현실적으로 어렵다.
또한, 쇼케이스에 대한 전략을 세울 때, 주기 또한 중요한 요소가 된다. 7~12명 정도의 작은 팀에서 주기를 3주보다 크게 선택하면, 시연할 내용이 너무 많아져, 쇼케이스 자체에 너무 많은 시간을 소모할 수 있다. 이 경우 이해관계자들의 집중력이 흩어져 효과적인 쇼케이스가 되기 어렵다. 또한 주기가 너무 길어지면, 이해관계자들이 자주 확인하지 못하기 때문에 물리적인 기능 변경의 수는 줄어들 수 있으나, 기능 자체에 대해 이해관계자들의 이해가 부족하여 향후 문제가 될 리스크가 커질 수 있다.(반대로 주기가 짧아지면, 물리적인 변경은 늘어나더라도 이해관계자들이 기능에 대해 만족하는 리스크가 작아질 수 있다.)
2008년 와세다 대학에서 작성된 논문에 따르면, 불확정성이 높은 프로젝트의 경우 이터레이션을 짧게 가져가는 것이 좋고, 복잡도가 높은 프로젝트 일 수록 이터레이션을 길게 가져가는 게 좋다는 내용도 참고하면 좋겠다.
그리고 모든 기능을 쇼케이스에서 모두 시연하려는 욕심은 버리자. 언제나 테스트할 수 있는 접근 방법을 제시하되, 비즈니스 우선순위가 높은 기능을 시연하고 피드백을 받는 것이 보다 효과적이다.
필자는 이 경험을 통해 많은 것을 배웠다. 그동안 그가 알던 애자일이 현실과 엮어 다양한 환경에서 어떻게 맞물려야 되는지에 대해 고민하기 시작했다.
