애자일 이야기2015.01.06 11:10

BBC (British Broadcasting Corporation) 방송국은 영국에서 가장 크고 오랜 전통을 지닌 방송국이다. 특히 세계적으로 BBC 뉴스의 위상은 대단하다. BBC의 라디오와 TV 프로그램들은 현재 많은 세계의 방송사들의 채널을 통해서 방영되고 있다. 최근에는 BBC의 웹사이트를 방문하여 모바일, 타블렛, PC에서 TV를 시청하는 경우가 급증하고 있는 상황이다. 이에 맞춰 BBC는 인터넷을 통해서 모든 방송 컨텐츠를 시청자의 수요에 맞추어 제공해야 하는 과제를 진행하게 되었는데 그 과제를 진행하면서 도입했던 애자일에 대한 이야기를 살펴 볼 것이다.



많은 사람들이 대규모 조직에서도 스크럼이 가능한지 여부에 대해 의문을 갖고 있다. 특별히 애자일 개발 방법론에 회의적인 사람이거나 변화자체를 싫어하는 사람일수록 의구심이 클 것이다. BBC에서 스크럼을 도입한 보고서에서는 스크럼이 대규모 조직에서도 활용 가능할 뿐만 아니라, 우려했던 손해나 위험이 없다고 밝혔다. BBC에서 스크럼을 도입하면서 그 팀 멤버들은 스크럼 마스터와 함께 자연스럽게 기존에 보기 어려웠던 리더십이 발휘될 수 있었다. 하지만 그들이 경험했던 문제는 제품 책임자(Product Owner)의 역할이었다. 이번 사례에서는 BBC라는 대규모 조직에서 애자일을 도입하면서 겪었던 크고 작은 시행 착오들을 살펴보도록 하겠다.


프로젝트의 소개

iPlayer 프로젝트는 영국의 많은 시청자들과 해외에서 BBC의 TV프로그램이나 라디오 프로그램들을 듣고 싶어하는 사람들을 위해 진행했던 프로젝트이다. 필자 또한 영국에 거주하면서 실시간 방송과 뉴스들을 보기 위해서 가장 많이 이용하던 서비스이기도 했다. 이 프로젝트는 지난 7일 동안 방송되었던 컨텐츠들을 검색하여 다시 보기를 제공하고자 했다. 이 때, Kontiki 라는 P2P 네트워크를 통해서 데스크탑에 다운 받기 기능도 제공하려 했다.


 


[그림3-1] iPlayer 화면


장기목표는 모든 BBC의 프로그램들을 다운받거나 스트리밍 서비스를 제공하는 하나의 플레이어를 구축하는 것이었다. 마이크로소프트의 윈도우 플랫폼에서 제공하는 것을 시작으로 모바일과  다른 OS까지 확장하는 것이 최종 목표였다.

iPlayer를 개발하기 위해서 BBC는 외부 협력업체 두 곳과 함께 프로젝트 팀을 구성하였다. 협력업체는 주로 인코딩 된 미디어, 메타데이터, 자막, 저장공간 등과 같은 영상을 전달하는 역할을 담당하고 있었다. BBC에서 협력업체들과 더불어 프로젝트를 진행할 사내 조직을 FM&T(Future Media and Technology)라고 작명했다. 이 팀은 주로 UI와 미디어를 검색 같은 핵심 기능들을 맡았다.

FM&T가 프로젝트를 진행하기 위해서 추가적인 팀을 구성할 수도 있었지만, 효율을 위해서 기존에 회사 내 팀들의 협조를 받기로 했다. 그래서 모두 아홉 개의 팀들이 iPlayer에 필요한 컴포넌트를 개발하기 위해서 참여하였고, 중앙의 한 팀이 프로젝트를 관리하였다. 각 팀들은 아래와 같은 기준으로 나누어지게 되었다.


1. 홈페이지 개발

2. “다운로드”,  “지금 보기” 와 같은 사용자 기능 제공 및 액션의 처리

3. 내려 받은 미디어를 관리하기 위한 애플리케이션

4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환경 제공

5. 웹 기반의 프로그램 스케줄과 사용자 가이드

6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리

7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:Sigle Sign On) 제공

8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석

9. 사용자 경험과 인터렉션


그럼 이 아홉 개의 컴포넌트 팀들 사이에서 도입했던 애자일 경험과 이 프로젝트에서 제품 책임자의 좌충우돌 경험에 대해 살펴보도록 하겠다.


프로젝트 준비하기

2006년 4월에 총 아홉 개의 개발팀에 80명의 직원들로 구성된 iPlayer 프로젝트가 발족되었다. 각 팀에는 개발자, 테스터, 분석가, 디자이너, 프로젝트 매니저 등 다양한 역할의 팀원들로 구성되었다. FM&T에서는 기존의 프로젝트 매니저들을 모두 스크럼 마스터로 역할을 바꾸기로 했다. 

아홉 팀 중 이미 일곱 팀은 내부적으로 스크럼을 적용하고 있었고 남은 두 팀들은 이번 프로젝트를 통해서 스크럼을 도입하게 되었다. 참여한 모든 팀들이 서로 개발한 결과물을 전달하는데 문제가 없게 하기 위해서 2주 기반 스프린트를 동시에 설정하여 서로 같은 주기로 진행하도록 했다. 미디어 영역에서는 전송환경이 불규칙적이기 때문에 제품 백로그(Product Backlog)가 변경 될 가능성이 높았다. 때문에 2주 기반의 스프린트 기간은 적절한 주기였다.

그들은 의무적으로 일일 스크럼 미팅을 각 팀 별로 진행하기로 했다. 그리고 이와는 별도로 스크럼의 스크럼 즉, 모든 팀들의 스크럼 마스터들이 모여서 각 팀 별로 구현해야 하는 기능들을 공유하기 위한 미팅도 매일 진행하기로 했다. 스크럼 마스터들의 미팅에서는 각 팀끼리의 의존관계를 고려한 구현의 진행 순서 중심으로 논의를 하고 그와 더불어 어제 무엇을 했고 지금 무엇을 하고 있는지도 서로 공유하기로 하였다. 그들은 또한 매주 각 팀의 선임 개발자들이 모여 개발 표준과 개발 방법들에 대한 내용을 공유하기로 했다. 

그 다음 그들이 프로젝트를 위해서 할 일은 바로 제품 책임자를 임명하는 것이었다. 대규모 프로젝트이기 때문에 제품 책임자는 중앙 관리 팀에서 진행해야 된다고 생각했다. 왜냐하면 중앙 관리 팀이 제품 전체의 로드맵과 설계, 요구사항들을 정리하는 역할을 맡았기 때문에 제품 관리자를 중앙 팀에 두는 것이 가장 효과적이라고 생각했다. 뿐만 아니라 중앙 팀은 스크럼에 있어서도 가장 잘 실천하고 있는 팀이었다. 

돌아보면 그들은 이렇게 구성한 스크럼의 스크럼 방식의 접근과 중앙 팀의 장점에 대한 확신이 충분히 없었다. 그리고 “무조건 빨리 만들자” 라는 생각을 가지고 있었는데 이 생각으로는 그 팀을 보다 효율적으로 움직일 수 없다는 것이 결론이었다. 그들이 몰랐던 사실이 하나 있었다. 그것은 스크럼은 개념이 아닌 행동이기에 적용하는데 있어 많은 노력과 시간이 필요하다는 점이다. 결코 짧은 교육만으로는 이것을 이룰 수 없었다. 

이렇게 프로젝트 환경을 설정하고 각 컴포넌트 팀들은 각자 자신의 맡은 바를 진행했다.


무엇이 잘못 되었던 것일까?

무엇이 잘못 되었던 것일까? 두 번째 스프린트를 진행할 때까지 프로젝트는 진척이 잘 되지 않고 있었다. 그들은 백로그(유저 스토리와 업무 리스트가 저장되어 있는 곳) 를 채울 수 없었다. 그나마 백로그에 있는 항목들은 대부분은 불확실한 것들이 대부분이었다. 제품 책임자가 사용자 스토리를 만들고 백로그에 할당하게 되는데 그들이 임명한 제품 책임자가 기능들을 불명확하게 작성한 것이었다. 왜냐하면 그 한 명의 제품책임자가 모든 내용을 다 정확하게 이해하기 어려운 부분이 있었기 때문이다. 

아홉 팀들은 모두 스프린트 주기를 동기화 시켰기 때문에, 동시에 중앙 팀의 제품 책임자에게 다음 스프린트 계획을 물어봐야만 했다. 하지만 많은 팀과 불확실한 업무들 때문에 제품 책임자가 스프린트 계획을 세우는데 많은 시간이 걸렸다. 한 팀당 이터레이션 계획미팅에 소요되는 시간이 보통 네 시간 정도 걸렸다. 거기에 불확실한 백로그 항목들을 상세화 하는데 네 시간이 더 소요되었다. 영국에서는 근로시간이 7시간이기 때문에 하루에 한 팀을 끝내기도 힘들었다.

그들에게 나타난 문제들을 정리해 보자면 다음과 같다.


• 제품 책임자는 너무 바빴고 결정을 제 때 내리는 것이 불가능 했다.

• 제품 책임자가 정신 없이 바쁘기도 했지만 그는 어떤 결정도 단독으로 내릴 수 없었다. 결국, 그 결정은 각 팀으로 넘겨졌다. 대부분의 팀들은 이런 이유로 개발 속도가 매우 느려졌고, 심지어 어떤 일도 진행하지 못하는 팀이 생겨 나기도 했다. 그래서 혼잡한 상황이 조금 진정이 된 상황에서만 제품 책임자가 정확한 방향을 제시해주는 것이 가능했다. 

• 백로그 항목들의 우선순위가 정해지지 않았기 때문에 각 팀은 자신이 원하는 항목부터 처리했다. 팀에서 꺼려하는 항목들은 가장 나중에 처리했다. 

• 백로그 항목들의 우선순위를 정할 때마다 제품 책임자는 고군분투 했다. 그 이유는 각 항목을 작성한 팀만 이해가 가능했기 때문이다.

• 제품 책임자가 결정을 내릴 수 없었기 때문에, 시간이 지날수록 미팅의 참석범위는 넓어지고 횟수는 잦아졌다.



이 상황은 그렇게 오래 지속되지 않았다. 그 동안 애자일에 비판적이던 사람들이 “스크럼으로는 결코 프로젝트를 성공할 수 없다”는 반대 목소리를 내기 시작했기 때문이었다.

스크럼 마스터들은 함께 모여서 현재의 상황을 파악하고자 하였다. 그들은 교육을 받았고 관련 서적들을 읽었으며, 타사 사례를 찾아봤다. 그들은 자신들의 스크럼이 책이나, 타사 사례와 크게 다른 점을 찾지 못했다. 하지만 분명한 점은 이대로가면 프로젝트가 실패할거라는 사실이었다. 다른 관점에서 그 스크럼은 잘 동작했지만 잘 안되었던 부분은 분명하고 빠른 결정이었다. 이는  백로그의 우선순위를 정할 권한이 제품 책임자에게 없고 결정을 내리기 위해서는 복잡한 절차가 필요했기 때문이었다. 

그들은 그 당시의 제품 책임자가 어떤 기능을 결정하는데 걸리는 시간을 소요될지 알 수 없었다. 그리고 가끔 제품 책임자는 이상하다고 생각이 들 정도로 현명하지 못한 결정을 내리고 있었다.



해결방안의 모색

한 명의 제품 책임자가 처리할 수 있는 업무는 제한되어 있다는 것을 깨닫게 되면서 그들은 중앙 팀에서 갖고 있는 제품에 대한 책임을 두 개의 조직으로 나누어서 관리하였다. 그들이 이런 결정을 내릴 수밖에 없었던 것은 한 명이었던 제품 책임자의 일에 부하가 너무 심했기 때문이다. 빠른 의사 결정을 위해 중앙 팀을 둘로 나누고 각 팀에 제품 책임자를 둠으로써 각자의 팀에서 독립적으로 결정을 내릴 수 있게 하려는 것이었다. 이 방법은 효과가 있었다. 제품 책임자에게 이전 보다는 제품 책임자에게 쉽게 접근하는 것이 가능해진 것이고 어떤 결정도 보다 쉽게 내릴 수 있었다. 그에 따라 제품 개발도 다시 진전이 있었다. 

하지만 여기서 빨라지고 쉬워졌다는 뜻은 이전과 비교해서 그렇다는 것이다. 여전히 문제가 남아 있었다. 사용자 스토리들이 제대로 되어 있는지 점검하고 또 다시 고치고 하는 부분이 반복되었고 결국 만족할 만한 산출물이 나오지 않았다. 그래서 그들은 다시 직면한 문제를 고민하게 되었는데 한가지 놓친 것이 있었다. 바로 한 주에 36시간 일할 수 있는 2명의 제품 책임자가 각 그룹의 계획을 커버 하려고 하고 있었지만 그들은 여전히 각 팀들의 스프린트들을 동기화 시키는 작업을 진행하기에는 너무 버거운 일정이 이었다는 것이다.

확실한 것은 두 명의 제품 책임자가 물리적으로는 일을 나눠서 처리하고 있었지만 정신적으로는 그 일이 나눠지지 않은 것이다. 즉, 그 둘 모두가 전체 제품에 책임이 있다고 생각한 것이다. 그래서 제품 책임자들은 여러 팀간의 의존성에 대해서 항상 고려해야 했다. 이러한 잘못된 생각이 팀간의 충돌을 야기할 수 밖에 없었다. 그래서 제품 책임자는 여기에 대해서 말이 안되고 비효율적인 결정을 내릴 수 밖에 없었다. 이런 일들이 매일 같이 있었다. 

결국에는 어떤 지시도 없는 것이 더 낫다고 생각될 정도였다. 왜냐하면 지시가 있어도 그것이 올바른지에 대한 확신이 없었고 그런 이유로 팀의 사기를 저하했기 때문이다. 두 제품 관리자의 의견이 대립 되었을 때, 개발팀들이 할 수 있는 것은 그저 잠시 회의를 멈추고 지켜보는 것뿐이었다. 

그들은 다시 한번 현재의 상황을 다음과 같이 정리했다.


• 제품 책임자에게 접근 하는 것이 확실히 접근하기 수월해 졌다.

• 두 제품 책임자의 의견대립이 자주 발생하였고 이는 업무진행을 힘들게 만들었다.

• 이러한 결과로 개발 팀들은 제품 책임자를 무시하기 시작했고 자기 팀이 원하는 대로 제품을 만들기 시작했다. 그래서 제품 책임자들은 프로젝트의 우선순위를 결정하는 책임자와 백로그에 있는 각각의 업무에 대한 책임자로서의 역할 보다는 팀간의 애매한 부분을 정리해주는 역할을 하게 되었다.



이렇게 시도한 새로운 구조에서 거의 4개월 동안 프로젝트를 진행하였다. 그 기간 동안 격한 토론을 비롯하여 팀 간의 갈등이 많았다. 일부 팀들은 다른 팀과의 협업을 거부하고 혼자 일하기도 하였다. 그러다 보니 스프린트 범위도 지켜지지 않았다. 결국, 2개의 그룹으로 나눴던 제품 책임자구조를 해산하고, 다시 중앙 팀에 한 명의 제품 책임자를 두기로 결정하였다. 그리고 가장 중요한 결정이었던 것은 각자 팀 별로 제품 책임자를 임명하기로 한 것이다.



자기 주도적으로 일하기

각자 팀에서 제품 책임자를 두는 방안을 실행한 후에 중앙 팀의 역할이 많이 축소되었다. 그저 몇몇 공통된 지시를 내리고 제품의 전체 로드맵을 그리는 정도였다. 그들은 각 팀에 임명된 제품 책임자를 개발 프로듀서라고 호칭했다. BBC는 다른 기업들과 다른 부분이 하나 있는데, BBC가 이익을 추구하는 사기업이 아닌 공기업이기 때문에 제품 책임자에게 자금 부분은 큰 고려사항이 아니었다. 그 보다 그들은 모든 사용자들에 유용한 제품을 만드는 것에 집중하였다. 그렇기 때문에 비즈니스 분석가의 관점이 BBC의 제품 책임자 역할에 있어서 이상적이었다. 

각 팀 별로 우선순위를 만들게 되었다. 중앙 팀은 업무목록을 제공했는데 단지 목록일 뿐 하나의 통일된 제품의 모습으로 준 것이 아니었다. 중앙 팀은 단순히 각 팀들이 필요한 요구 사항들을 정리했다. 즉, 하나의 제품을 개발함에 있어 각 팀들이 필요한 것들을 요구하고, 중앙 팀에서 이를 조율한 것이다.

각 팀에 소속된 새로운 제품 책임자들은 애자일에서 설명하고 있는 제품 책임자 역할을 큰 어려움이 없이 수행하였다. 예상치 못했던 점은 BBC 내부팀이 아닌 외부 협력업체와의 대화가 지속적으로 증가 했다는 것이었다. 프로젝트 준비하기에서 두 협력업체와 BBC 사내 팀으로 프로젝트 그룹을 형성했다고 설명했다. 중앙 팀은 바로 이 집단들과 대화를 진행하는 역할을 맡았다.

스크럼을 도입할 때 가장 중요한 것 중 하나는 애자일의 기본원칙에 기반하여 도입해야 한다는 점이다. 그리고 애자일 원칙 중 하나가 바로 팀 안에서 상호적인 대화가 열려있어야 한다는 것이다. 아쉽게도 팀을 변형하기 전에는 외부 협력업체를 포함한 여러 팀들이 모였을 때, 각 팀에 필요한 것을 정확히 몰랐었다. 때문에 서로 무엇을 요청해야 하는지 몰랐던 적이 많았다. 하지만 팀이 바뀐 뒤에 팀의 요구를 정확하게 알 수 있었기 때문에 전체 그림을 같이 공유하는데도 원활하였다.

이러한 제품 책임자의 변화를 통해서 그들은 다음과 같은 효과를 얻을 수 있었다.


• 각 팀들은 보다 분명한 제품의 책임 의식이 있었다.

• 프로젝트 요구사항이 명시적으로 정의 될 수 있었다.

• 질문에 대한 빠른 답변을 얻을 수 있었다.

• 각 팀들이 명확한 제품 백로그를 생성하고 스프린트 계획수립이 가능해졌다.

• 해야 할 업무의 배분이 적절이 이루어졌고 새로운 기능들을 매 스프린트마다 고객에게 전달할 수 있었다. 

• 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가가 되었다.  

• 일관성이 없었던 제품 백로그 항목들이 각 팀들에 의해서 완화될 수 있었다.



독립적인 팀들로 나누고 나서 앞에서 언급한 효과들을 체험할 수 있었다. 하지만 여전히 부족한 부분이 있다고 말하는 사람들이 있었다. 전체적으로 프로젝트가 진행되는 상황을 파악하기가 복잡했고 릴리즈 계획을 세우고 여러 팀들의 결과물을 하나의 제품으로 통합하는 과정에 여러 날이 소모되기도 했다. 전체 프로젝트가 진행되는 상황들은 팀들이 일하는 공간에 업무보드, 포스트잇, 카드를 이용해서 관리했고 제품 릴리즈 계획의 경우 피벗 테이블(엑셀의 기능)을 통해서 만들어졌다.

그래도 이러한 구조가 완벽한 것은 아니었다. 두 가지 아쉬운 부분이 있었다. 먼저, 누구의 업무인지 명확하지 않은 경우 누구도 그 업무들을 하려고 하지 않았다. 다른 하나는 아홉 팀이 제품 로드맵을 각자 다르게 해석하고 있었다는 것이었다. 

후자의 경우 팀들이 그들의 백로그의 항목의 우선순위를 정할 때, 다른 팀들이 필요여부가 고려되지 않고 각자의 이해관계에서 정하고 진행했기 때문에 문제가 되었다. 이것은 심지어 가까운 공간에서 일하고 있는 팀들 간에게도 발생되었다.

그들이 진행상황을 점검하고 다시 반영하는 주기를 통해서 많은 개선을 가져 올 수 있었고 전체적으로 제품을 효과적으로 만들어 낼 수 있었다. 이러한 방법으로 약 6개월을 일을 지속했고, 각 팀이 독립적으로 일하면서 보다 성공적인 모델이 되었다. 



비즈니스 제품 책임자

그들은 이렇게 다양한 제품의 책임 구조를 통해서 많은 것을 배울 수 있었다고 말한다. 그들은 추가적으로 중앙 팀에서 일하는 “비즈니스 제품 책임자”의 역할을 만들었다. 즉, 기존의 제품 책임자 대신 비즈니스 제품 책임자로 일하는 것이다. 이 비즈니스 제품 책임자는 기능에 대한 결정을 내리지 않는다. 대신에 각 팀들의 제품들과 비즈니스 전체적으로 유지되어야 할 것들에 대한 책임을 갖고 있다. 뿐만 아니라 팀 사이에 갈등 발생하거나 협업이 원할지 진행되는지 관찰하고 각 팀 별로 우선순위가 적절한지 확인하는 것이다. 그 팀 내 제품 책임자들은 백로그 항목의 우선순위를 부여하는 제품 책임자의 역할을 넘어서 각 제품의 전문가로서의 역할을 할 수 있었다.

이러한 조직구조를 유지하고 모든 계층의 사람들에게 리포트를 작성하기 위해서 그들은 “테마”라는 컨셉을 작성하기로 했다. 즉, 사용자 스토리의 상위 레벨이라고 보면 된다. 예를 들어 “사용자가 검색이 가능해야 한다” 와 “사용자에게 추천 검색 단어를 알려줄 수 있어야 한다” 라는 검색에 대한 사용자 스토리들이 있다면 우리는 이것을 “검색”이라는 테마로 묶는 것이다. 그렇게 해서  비즈니스 제품 책임자는 이런 테마들의 우선 순위를 결정했다. 그렇게 함으로써 모든 팀들에게 무엇을 해야 할지를 명확하게 전달하는 것이 가능했고, 각 팀 별로 이에 맞는 자신들의 우선순위를 정할 수 있게 되었다. 모두 총 45개의 테마를 만들었고 이것은 총 828개의 제품 백로그들과 연결되었다.

예로 몇 개만 소개하자면 아래와 같은 테마들이 존재했다. 


• 사용자 가이드

• 설치, 업그레이드 그리고 언인스톨

• 접근성 – 자막


팀 안에서 스프린트를 계획하는 동안에 팀 내의 제품 책임자는 제품 전문가로서 제품에 대한 질문에 대해 답하는 것이 가능했고 팀의 스프린트 목표를 전체 프로젝트의 목표에 비춰 설명하는 것이 가능했다. 

마지막으로 팀들 간의 커뮤니케이션을 개선하기 위해서 진행했던 제품데모와 테마리뷰와 미팅을 진행했다. 각 팀들은 제품데모 미팅을 통해서 프로젝트의 청사진을 쉽게 확인할 수 있었고 최근 특정 기능에 변화를 주었을 때 그것을 쉽게 전달이 가능했다. 그리고 이 미팅은 최대한 간결하게 진행하고 끝내도록 노력했다. 각 팀들은 제품데모에서 합쳐진 하나의 제품을 보여주는 것이 아니라 각자 자신의 제품 그대로 보여주었다. 그렇기 때문에 각 팀이 발표한 내용은 대부분 기술적 이었다. 따라서 비즈니스적으로는 이해하기 어려운 부분이 있었다.

지금은 제품데모를 할 때 항상 사용자 중심으로 데모를 진행하고 있다. 이를 통해서 비즈니스 사람들에게뿐만 아니라 다른 팀들도 더 깊은 이해를 할 수 있었다.

테마리뷰 미팅의 경우도 처음부터 잘 진행되었던 것은 아니었다. 처음에 테마미팅에서 어떤 구현을 하기로 결정한 것이 있으면 그것들이 각 팀들 여러 이유들 때문에 결정을 수월하게 진행하지 못했다. 즉, 한 팀이 A라는 기능을 구현하기 위해서 다른 팀이 B를 구현해주어야 하고 그 B를 구현하기 위해서는 또 다른 팀이 무엇을 해주어야 하는 식의 의존성 때문이었다. 그래서 그들은 스크럼 마스터들과 함께 의존성 미팅을 매주마다 진행해야 했다. 이것은 팀끼리의 기술적 의존성만 논의하기 때문에 비즈니스 결정을 필요로 하지 않았다.

그들이 중앙 팀에 비즈니스 제품 책임자의 역할을 만든 다음부터 기존의 의존성 미팅 없이도 자연스럽게 진행할 수 있었는데 그 이유는 바로 테마라는 항목이 존재했기 때문이었다. 그 뒤에 의존성 미팅은 사라지고 테마미팅이 그 역할을 대신하게 되었다. 테마미팅 참여자는 각 팀의 제품 책임자, 비즈니스 제품 책임자, 스크럼 마스터, 테크니컬 리드 정도였다. 그리고 그 미팅에서는 다음과 같은 일들을 진행했다.


• 우선순위의 점검

• 특정 테마에 해당하는 각 팀들의 백로그 점검

• 테마 별 예상 개발기간

• 각 작업의 팀별 의존성

• 팀 단위에서 작성할 수 없었던 백로그 항목의 추가


이러한 방식의 접근을 진행한 뒤에 효율이 높아졌을 뿐만 아니라 각 팀 별로 전달해 주어야 할 기능을 정확하게 정의 할 수 있었다. 물론, 특정 작업들은 이 미팅 외에도 추가적인 미팅들이 요구되기도 했지만 대부분의 기능들은 이 미팅만으로 진행되었다.



정리


이 BBC의 사례를 살펴봤을 때 대규모 조직의 경우 올바른 비즈니스 방향과 더불어 각 개인 팀들 또한 같은 목표를 가지는 것이 어렵다는 사실을 알 수 있다. BBC에서는 다양한 팀들 사이에서 단 한 명의 혹은 두 명의 제품 책임자를 둠으로써 프로젝트를 정상적으로 진행할 수 없었고 이 문제를 단번에 알아채기도 어려웠다. 즉, 한 명의 제품 책임자를 두면서 그들은 결국 일관성 있는 방향을 제시하는 것이 어려웠고 빠트린 기능들도 많았던 것이다.

여기서 우리가 되짚어봐야 하는 이슈는 BBC에서 누구도 스크럼의 문제라고 보지 않고, 제품 책임자만의 문제로 접근하고 해결하려 했다는 것이다. 하지만 애자일 원칙을 볼 때 애자일 팀은 자기 주도적 팀이 되기를 요구한다. 만약 이 점을 토대로 접근했다면 보다 일찍 각 팀에 제품 책임자를 배치하지 않았을까 생각한다.

만약 대규모 조직에서 다양한 팀들이 함께 일을 진행해야 하는 경우라면 다음 BBC가 전하는 팁을 참고해 보도록 하자.


• 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와 함께 할 수 있는 시간을 고려해야 한다. 

• 한 명의 제품 책임자에 의존하다 보면 결국 일 진행이 늦어지고 프로젝트의 올바른 방향을 설정하는 것이 어렵다.

• 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목표를 동시에 고려하다 보면 줄어든다.

• 조직적이지 못한 팀이 하나의 프로젝트에서 같이 일하면 비즈니스 목표와 다른 제품이 만들어 질 수 있다.


대규모 스크럼 프로젝트를 성공시키기 위해서는 다음과 같은 요소들을 필요로 한다. 


• 스크럼의 스크럼

• 같은 공간에서 일하는 개발 팀들

• 팀 안에서 적절한 역할의 사람들 

• 권한이 있는 스크럼 마스터



BBC는 명확한 비즈니스 목표와 주관적인 역량이 잘 조화되었을 때, 프로젝트 내 여러 팀들이 효율적으로 일할 수 있다고 말한다. 스크럼은 BBC에게 간단하고 반복적으로 프로젝트 결과를 조금씩 완성시킬 수 있는 방법을 전달해 주었다. 하지만 성공적인 스크럼을 위해서 모든 구성원들의 역량과 업무처리 속도를 고려해야 하고 제품 책임자가 프로젝트를 완벽하게 지원할 수 있는지를 고려해야 한다. 

BBC에서처럼 80명의 구성원들이 일하는데 단 한 명의 제품 책임자를 두는 오류를 범하지 않도록 하자.




Posted by 박경훈