스크럼(Scrum)은 아마도 가장 인기 있는 애자일 기법일 것이다. 스크럼이란 무엇이며, 무슨 이유로 이러한 인기를 얻게 됐는지 이해하기 위해 그 유래와 목적, 변화상을 짚어본다.
스크럼 기법을 도입하는 기업들이 늘고 있다. 그러나 스크럼은 사실 그리 쉽지 않다. 선뜻 이해하기 어려우며, 때로는 오만하다는 소리까지 나온다. 그럼에도 불구하고 스크럼 얼라이언스(Scrum Alliance), 스크럼.Org(Scrum.Org), 스크럼 Inc(Scrum Inc) 등의 기관이 존재하며, 독립적인 트레이너들도 존재한다. 이쯤 되면 스크럼이 정확하게 무엇이며 어디에서 시작됐는지, 또 어떤 문제를 해결할 수 있으며 기업들이 적용을 위해 고군분투하는 이유가 무엇인지에 대한 의문이 생긴다. 이런 의문점들에 대한 답을 찾아보자. (이미지 크레딧 : Sutterstock)
스크럼이 시작된 곳
1990년대 초, 켄 슈웨버(Ken Schwaber)는 인디비주얼(Individual Inc)에서 일하고 있었고 제프 서더랜드(Jeff Sutherland)는 이젤콥(EaselCorp)에서 일하고 있었다.
인디비주얼에는 문제가 있었다. 요건이 너무 빨리 변경됐던 것이다. 서더랜드와 슈웨버는 각각 일본 기업들이 어떻게 통합된 다양한 팀들을 통해 비디오 카세트 플레이어를 개발했는지를 기술한 1986년 하버드 비즈니스 리뷰 기사 "새롭고 새로운 제품 개발 게임(The new new product development Game)"을 읽었다. 그 방법은 당시 대부분의 사람들이 소프트웨어 개발을 떠올리는 방식, 즉 "폭포수(Waterfall)" 방식과 크게 달랐다.
위 이미지는 켄 슈웨버의 1995 OOPSLA 논문 "스크럼 개발법(The Scrum Development Method)"에서 소개된 스크럼 개발법의 초기 버전이다. 슈웨버와 서더랜드는 ‘스크럼 개발 프로세스’(Scrum Development Process)라는 1995 OOPSLA 컨퍼런스를 위한 논문을 작성했다.
스크럼의 창시자들
서더랜드(우측)는 베트남전에 참가한 전투기 조종사로 생물 측정학 박사 학위를 소유한 기술 임원이었다. 그는 현재 스크럼 Inc의 CEO다. 그는 슈웨버(좌측)와 협업해 개발 방법으로써의 스크럼 창시, 스크럼 얼라이언스, 일련의 저작물을 내놓았다. '스크럼을 통한 애자일 소프트웨어 개발'(Agile Software Development With Scrum)이라는 서적도 이 결과물 중 하나다.
2001년, 서더랜드와 슈웨버는 앨리스테어 콕번(Alistair Cockburn)이 개최한 "스노우버드 회의(Snowbird Meeting)"에 참석했고, 여기에서애자일 선언문(Agile Manifesto)가 탄생했다. (두 사람이 최초 서명인이었다). 그리고 서더랜드의 최신 저서 '스크럼: 절반의 시간으로 두 배의 일을 처리하는 미학'(Scrum: The Art of Doing Twice the Work In Half the Time)이 지난 9월에 출간됐다.
스크럼의 본질 
1991년에 출간된 '심각한 문제들, 옳은 해결책'(Wicked Problems, Righteous Solutions)에서 피터 디그레이스(Peter DeGrace)와 레슬리 스톨(Leslie Stahl)은 스크럼을 "일괄 모델(All-at-once Model)"이라 부르고 있다.
이는 선수들이 협력하여 허들(Huddle)을 형성하고 공을 한 번에 몇 걸음씩 상대팀 진영 끝으로 옮기는 럭비 스크럼을 의미한다. 당시 저자들은 지나가는 말로 스크럼을 언급했지만 자세히 거론하지는 않았다.
서더랜드와 슈웨버는 요건과 우선순위가 너무 빠르게 변화하여 개발자들이 아무 것도 할 수 없는 이젤콥에서와 같은 문제를 해결하기 위한 툴로써 스크럼을 사용하면서 세부사항을 완성해갔다.
서더랜드가 설명하는 스프린트 아이디어는 다음과 같다. : 먼저 개발팀이 변화 없이 개발하고 테스트할 수 있는, 방해 받지 않는 기간인 스프린트(Sprint)가 있다. 스프린트는 길이가 일정하며 90일부터 시작한다. 스프린트 후에는 팀이 소프트웨어를 고객에 "시연"(demo)한다. 고객은 다음 스프린트를 위한 아이디어를 제시하게 된다.
이것은 고객으로부터의 피드백 프로세스를 느리게 한다. 고객은 흔히 스크럼의 "아우터 서클(Outer Circle)"이라 일컬어진다. 스프린트 후에는 팀 내부적으로 효과가 있었던 것, 없었던 것, 변경할 것을 논의한다. 이것을 회고(Retrospective)이라 부른다.
한편, 스크럼의 ‘이너 서클’(Inner Circle)은 일일 스크럼으로, 팀이 성과를 가속화하기 위해 진행 중인 작업을 논의하는 기회다. 이 회의를 스크럼이라 부르는 이유는 럭비의 '허들'을 닮았기 때문이다. 이 용어는 하버드 비즈니스 리뷰에서 유래했다.
초기 정의 이후, 스크럼의 순서는 일일 스크럼(또는 "스탠드업(Standup)"), 시연 및 회고(또는 "검토")와 함께 개발 대상을 논의하는 기획 회의를 유지하게 된다.
스크럼 가이드(Scrum Guide)
앞서 언급한 3 개 기관, 즉 스크럼 얼라이언스, 스크럼.org, 스크럼은 모두 출처의 정의를 동일하게 유지하는 것에 목적을 두고 있다. 서더랜드와 슈웨버는 이를 ‘ScrumGuides.org’에서 무료로 배포하는 스크럼 가이드라 부르는 하나의 문서로 보존하고 있다.
16쪽에 불과한 이 가이드는, 회고와 기획 등의 ‘무엇’을 이벤트 운영 등과 같은 ‘어떻게’와 구분하려고 시도하면서 정보와 정보 과부하의 균형을 맞춘다. 그리고 이는 팀이 스크럼을 개인화할 수 있도록 해준다.
백로그(Backlog) 다듬기
스프린트 초기에 스크럼 팀은 향후 30일(또는 그 이하) 동안 개발할 대상을 논의한다. 단 이 "스프린트 기획" 회의 전 누군가가 처리할 잠재적인 업무를 확인해 합리적인 덩어리로 나누고 우선순위를 부여하여 팀이 스프린트 중 초점을 맞출 것을 결정할 수 있도록 해야 한다.
2003년 이후, 공식적인 스크럼 가이드는 ‘다듬기’ 대신에 "백로그 개선"이라는 용어를 사용하고 있다. (기존의 이름이 여전히 인기가 있긴 하다). 이름이야 어쨌든 이것은 비즈니스 부문이 기술 인력과 협업하여 다음에 개발할 대상을 찾아내는 하나의 과정이다.
이 과정은 일일 스크럼 후, 스프린트 중, 스프린트 검토 중, 심지어는 스프린트 자체 기간 동안 등 연속적으로 일어날 수 있다. 연속적으로 형식 없이 발생할 수 있으며, 공식적인 회의 또는 누군가의 역할 중 일부가 될 수 있다. 스크럼은 이를 처리하는 방법을 정확하게 기술하지 않고 있다.
이는 백로그를 스토리(Story)로 "다듬는"(groom) 보편적 활동이다. 이 덕분에 우리가 다음에 논의하게 되는 스프린트 기획이 원활하게 진행된다.
스프린트 기획(Sprint Planning)
2014 스크럼 가이드에 따르면 1개월 스프린트를 위한 스프린트 기획 회의가 1 영업일 전체를 소요할 수 있다고 한다. 이 이벤트는 2가지 질문에 대한 답을 얻고자 한다.
- 다음 스프린트로부터 비롯된 증가분(Increment)에서 무엇이 제공될 수 있는가?
- 해당 증가분을 전달하기 위해 필요한 업무는 어떻게 달성될 수 있는가?
팀들은 과거의 성과, 백로그, 기타 데이터 포인트(Data Point, 휴가 계획 등)를 이용해 예측할 수 있는 일을 파악한다. 이것을 스프린트 목표(goal)라 부른다. 두 번째 조각은 팀이 협력하는 방법이다. 작업을 스토리로 쪼개고 위험을 파악하며 스파이크(또는 어떻게 동작할지를 확인하기 위한 테스트)를 생성하고 디자인 작업을 하는 것 등을 의미할 수 있다.
이 설명은 고객 또는 구매자에게 신뢰감을 주기 위해 개발됐다. 또한 투자 시간이 낭비 시간이 되지 않도록 하는데 필수적이다. 어쨌든, 기술진은 시작하기에 앞서 처리 방법을 파악해야 한다.
일일 스탠드업(Daily Standup)
스크럼에서 가장 오해되는 부분은 일일 스탠드업(daily standup)일 것이다. 신뢰가 없다면 스탠드업은 팀 구성원들이 자신이 얼마나 바쁜지를 증명하는 상태 회의(status meeting)로 발달한다. 이미 보유한 현대적인 툴, 즉 스크럼 게시판과 웹 기반 툴로 이미 알 수 있는 정보다.
일일 스크럼, 일일 스탠드업의 목적은 공이 상대편 진영의 끝으로 이동할 수 있도록 돕는 것이다. 사람들은 도움을 요청할 수 있고 문제를 제기하며 자존심에 대한 걱정 두려움 없이 도움과 조언을 제공할 수 있어야 한다. 초점을 바꾸는 한 가지 방법은 개인 대신에 업무에 관해 이야기하는 것이다. 필자는 이 부분을 기사 "일일 스탠드업 회의를 구제하는 방법(How to Save the Daily Standup Meeting)"에서 상세하게 다룬 바 있다.
스크럼 가이드에서는, 회의의 목적이 마지막 회의 이후 발생한 일을 논의하는 것이라고 밝히고 있다. 즉, 내가 무엇을 했고 무엇을 할 것이며 어떤 문제에 막혀 있는지 등 유명한 "3 가지 질문"을 가이드는 추천한다. 그 목적은 업무의 흐름을 논의하는 것이다.
회고(Retrospective)
스크럼의 테마는 점검과 적응이다. 이 때문에 팀은 멈추고 반영하기 위해 계속적으로 휴식시간을 가져야 한다. 스프린트 회고는 이러한 휴식으로, 모든 스프린트에 이어 이뤄진다. 기술 인력은 물러나 무슨 일이 있었고 무엇이 잘 되었으며 무엇이 잘못 되었고 다음 번에는 무엇을 다르게 해야 하는지에 관해 논의한다.
이 회고는 후기 조치 검토, 사후분석(postmortem), 기타 "교훈"( lessons learned) 같은 회의와 유사하다. 회고와의 주된 차이점은 다음과 같다 : 변화는 항상 실험으로 관측될 수 있다. 차후 모든 팀에 반영될 새로운 정책에 합의하는 대신, 팀은 단순히 다음 스프린트가 끝날 때까지 몇 주 동안 새로운 기법을 시도해 보기로 동의할 수 있다. 이 시간 동안 무엇인가 다른 것을 시도할 수 있는 기회를 얻게 된다.
스크럼 가이드는 스프린트 회고를 위해 다음과 같은 3 가지 목표를 제시한다:
- 사람, 관계, 프로세스, 툴과 관련해 마지막 스프린트가 어떻게 이뤄졌는지 점검한다.
- 잘 된 주요 항목 뿐 아니라 잠재적인 개선을 규명하고 지시한다.
- 개선 사항을 도입하기 위한 계획을 수립한다. 이 계획은 스크럼팀이 업무를 처리하는 방식을 감안해야 한다.
지금까지 스크럼의 필수적인 격식을 논의했다. 이제부터는 다양한 역할에 관해 논의해 보자.
팀 구성원
스크럼은 프로세스를 관리하는 사람(스크럼 마스터), 수행할 업무를 정의하는 사람(프로덕트 오너), 제품 개발을 담당하는 사람(팀 구성원)을 분류한다. 기술 인력 또는 기술진 구성원(Member of the Technical Staff, MTS)라고도 불리는 팀 구성원은 다양한 기능 또는 능력을 보유한다.
스크럼팀 구성의 핵심은 팀이 업무를 처리하기 위해 필요한 것을 모두 보유하는 것이다. 여기에는 제작 지원, 그래픽 제작, 프로비저닝(Provisioning) 시스템까지 포함될 수 있다. 기술 인력 구성원은 흔히 구체적인 직위와 업무 설명에 상관 없이 처리해야 할 일과 그것을 처리할 수 있는 기능을 가진 사람에 대해 우려하곤 한다. 많은 경우, 팀들은 서로 연합해 지식을 조합/확산함으로써 업무를 달성할 수 있도록 한다.
특정한 기능을 가진 팀 구성원에 대한 집중은 비효율로 이어질 수 있다. 자신이 필요하기 전에 새로운 빌드(Build) 또는 스토리가 구성되기를 기다리면서 시간을 보낼 수 있기 때문이다. 하지만 스크럼은 효율(사람들을 항상 바쁘게 하는 것)보다는 효과(필요할 때 기능을 보유하는 것)에 중점을 둔다. 스크럼팀은 종종 태만과 비효율을 목격하는데, 그럼에도 불구하고 이 방식을 선호한다. 즉 팀 구성원들이 복수의 프로젝트를 지원하도록 쪼개는 방식을 선호하지 않는다.
프로덕트 오너(Product Owner)
스크럼은 개발 대상을 결정하는 사람(프로덕트 오너)과 업무를 처리하는 사람(기술 인력)을 구분한다. 또한 그는 백로그를 정의하고 무엇이 가능하고 시간이 얼마나 소요되며 업무를 관리할 수 있는 단위로 분배하는 방법을 파악하기 위해 팀과 협력한다. 일반적으로 "스토리"와 버그 수정으로 업무가 잘 정의된 후에는 프로덕트 오너가 우선순위를 설정하고 팀이 다음으로 처리해야 할 업무를 정의한다. 스프린트 중 프로덕트 오너는 팀과 협력해 스토리가 무엇을 의미하는지 명확하게 하고 범위를 협의한다.
슈웨버는 기술 팀을 차량으로 보고 프로덕트 오너를 운전자로 보았다. 즉, 팀은 속도를 내고 스프린트 목표까지 도달하며 변화에 대응(코너)할 수 있어야 한다. 운전자는 차량이 가는 곳을 책임진다. 운전자가 팀을 제자리에서 맴돌게 하면, 이것은 팀의 잘못이 아니다.
일부 소프트웨어 사상가들은 이런 구분이 굳이 필요하지 않다고 생각한다. 아마존의 2개의 피자팀, 그리고 전통적인 연구 및 개발그룹으로 알려진 일부 팀들은 기술 인력이 개발 대상을 결정할 수 있도록 허용하고 있다. 하지만 마케팅 또는 "비즈니스" 역할을 하는 프로덕트 오너의 역할 구분은 스크럼에 관해 생각하는 방법으로 압도적인 인기를 유지하고 있다.
스크럼 마스터(Master)
스크럼으로의 전환은 상기 4가지 격식과 몇몇 직책을 만드는 것 이상을 의미한다. 바로 사고방식의 전환이다. 스크럼 마스터의 역할은 마음가짐을 바꾸고 이해하도록 하는 것이다. 예를 들어, 프로덕트 오너가 스프린트 목표를 변경하면 팀이 하는 일이 바뀌게 되고 스크럼 마스터는 스프린트 후에 변화가 일어나는 규칙, 또는 의도적으로 이상하고 고통스럽도록 고안된 스프린트를 취소하기 위한 규칙을 실행하게 된다.
스크럼 마스터의 정신은 서비스 리더십 역할이다. 그는 팀을 위해 일일 스크럼을 용이하게 하고 장애를 없앤다. 또한 스크럼 마스터는 백로그를 다듬고 개선하는 기법을 제시하여 프로덕트 오너를 돕는다. 그 외에도 여러 가지가 있다.
스크럼 게시판(Board)
스크럼 게시판은 처리하고 있는 일, 처리하고 있는 일의 상태, 다음 일 등 업무의 상태를 보여준다. 즉 게시판은 병목현상을 규명할 수 있다. 다양한 색상을 이용해 스토리를 표시하는 팀들은 각 스토리가 각 상태에서 얼마나 오래 머무르는지 파악할 수 있다.
보편적으로 팀은 "흐름을 파악"하기 위해서 스크럼 게시판 근처에서 일일 스크럼 회의를 갖는다. 게시판이 상태 보고서인 것이다. TPS(The People's Scrum)에서 토비아스 메이어(Tobias Meyer)는 이것을 스크럼의 "핵심"이라 부른다.
업무와 스토리
스크럼 가이드는 백로그가 어떻게 분류되는지 정확하게 기술하지 않는다. 흔히 유즈 케이스, 스토리, 요건 문서, 구두 대화 등을 선택할 수 있다. 하지만 대부분의 팀들은 스토리로 표준화하고 있다.
스토리는 고객의 관점에서 약간의 기능성을 기술한다. "새로운 사용자 환경을 연구하라"는 스토리가 아니지만 "중간 이름 입력란을 추가하라"는 스토리다.
스토리에 관한 보편적인 대화는 무엇을 통해 사용자가 할 수 있도록 하는지와 그 이유를 기술한다 - "(사용자 타입)으로써 나는 (활동)을 하고 싶기 때문에 (결과)를 할 수 있다." 스토리는 종종 코딩(Coding)을 시작하기 전에 논의하는 텍스트 설명과 수용 기준을 포함한다. 보너스로, 수용 범주가 테스트를 위한 주요 입력 요소일 수 있다.
스크럼 가이드의 초기 버전은 할 일, 세부적인 동작 "메커니즘", 30 분 인크리멘트를 기술했다. 모든 할 일을 1인당 40시간으로 계산해 더하고 생각해보면 결과를 예측할 수 있다는 생각이었다. 더글라스 아담스(Douglas Adams)는 "이 덕분에 많은 사람들이 분노했고 좋지 못한 아이디어라고 생각하는 사람들이 많았다"라고 전했었다.
그러나 지식 노동을 이런 수준에서 예측할 수 없다는 사실이 입증됐다. 스토리 작업에 실제로 할애할 수 있는 업무 시간은 40시간 미만인 경우가 많다. 최근 대부분의 팀들은 할 일 대신에 동일한 크기에 관한 모든 스토리를 만들고 스토리의 수로 스프린트를 예측하려 시도하고 있다. 또한 그들은 상대적인 크기를 이용해 스토리 포인트를 비교하고 계수할 수 있다.
경험적 vs. 정의된 프로세스
스크럼은 경험주의에 입각하고 있지만, 진행하면서 필요하다고 발견하는 아이디어를 시작하기 위해서는 여전히 의사결정이 필요하다. 이는 "업무를 계획한 후에 계획을 실행"하는 정의된 프로세스와는 다르다.
예를 들어, 바비큐 방법을 배우는 것과 굽는 것을 생각해 보자. 케이크를 굽기 위한 특정 요리법이 존재한다. 재료를 더하고 오븐을 특정 온도로 가열하며 컵케이크를 30분 동안 놓아 둔다. 바비큐에서는 "적당해 보일 때 뒤집는다"는 지시사항을 제시할 가능성이 높다. 고기를 살피고 얼마나 빨리 갈색으로 변하는지에 따라 계획을 변경해야 한다.
스크럼은 스프린트의 아이디어를 통해 이를 달성한다. 한 동안은 개발할 필요가 있다고 생각하는 것을 개발한다. 그리고 나서 고객에게 공개하고 다음에 개발할 것에 관한 아이디어를 얻는다는 아이디어다.
심각한 문제들(Wicked Problems)
일부 소프트웨어 프로젝트는 매우 단순하다. 업무를 계획한 후, 계획한 대로 업무를 처리한다. 이런 프로젝트에는 워터폴이 적합할 수도 있다. 하지만 때로는 계획이 잘못되고 팀이 해결을 시도할 때까지 문제를 완전히 파악할 수 없다는 점이 문제다.
이것을 때로는 심각한 문제(Wicked Problems )라 부른다. 프레드 브룩스(Fred Brooks)는 자신의 대표 저서 신비한 인월(The Mythical Man-Month)에서 "한 방향을 계획하더라도 결과는 다르다"라고 말하고 있다. 브룩스는 빠른 프로토타입으로 이행할 것을 주장했다. ‘심각한 문제, 옳은 해결책’(Wicked Problems, Righteous Solutions)에서 스크럼을 제품 인크리멘트를 생성하는 "일괄" 모델로 기술하고 있다는 점을 기억하자.
단순한 제품 모델의 이상인 스크럼은 팀이 아직 개발을 위한 최선의 방법을 모르고 있는 것으로 가정한다. 제품을 점진적으로 개발하려 시도하고 상황을 지켜본 후에 회고에 적용해보라.
새롭고 새로운 제품 개발 게임(The New New Product Development Game)
앞서 언급했듯이 "새롭고 새로운 제품 개발 게임"은 일본 기업들이 전자 제품을 개발한 방식을 다룬 것이다. 여기에서는 (기존의) 제조 비유로부터 도출한 페이즈(Phase)와 핸드오프(Handoff) 대신에 최고의 신제품 개발은 동시 다발적인 활동을 통해 다양한 분야에 걸쳐 있는 팀을 활용했다고 결론 내렸다.
히로타카 타쿠츠(Hirotaka Takeuch)와 이쿠지로 노나카(Ikujiro Nonaka)가 관찰 연구한 팀 구성원들은 자주적 특성을 가진다. : 그들은 해야 할 일을 파악하고 실행한다. 개발 "페이스"는 한 번에 하나씩 벌어지는 대신에 겹치게 된다. 이 논문은 서더랜드와 슈웨버가 주창하고 스크럼이라 부른 소프트웨어 개발 방법에 영감을 제공했다.
스크럼 인증
2000년대 초반에 설립된 스크럼 얼라이언스는 비영리 단체로 스크럼 커뮤니티의 목소리를 대변한다. 이 조직은 인증된 스크럼 마스터(Certified Scrum Master), 인증된 스크럼 프로덕트 오너(Certified Scrum Product Owner), 스크럼 전문가(Scrum Professional), 스크럼 코치(Scrum Coach), 트레이너(Trainer) 등 다양한 자격증을 개발했다.
프로덕트 오너와 스크럼 마스터 인증은 (시험이 수반되는) 2-3일짜리 과정을 통해 얻을 수 있으며, 다른 것들은 학습, 전문적인 개발, 실습, 일반적으로 면대면의 실시간 평가 요소를 포함하고 있다.
자격증은 수준이 높을수록 취득이 어렵다. 인증을 위한 교육은 스크럼 얼라이언스의 글로벌 스크럼 개더링스(Global Scrum Gatherings)에서 제공되고 있다. 글로벌 스크림 개더링스는 또한 협회 자체에서 준비한 스크럼 코칭 리트릿(Scrum Coating retreats)도 제공하고 있다.
2009 년, 슈웨버는 스크럼 얼라이언스를 떠나 스크럼.org를 시작했다. 이는 유사한 인증 체제를 사용하면서 다양한 스크럼 행사를 개최하고 있다.
스크럼의 변화
스크럼은 시간에 따라 변화했다. 스프린트의 초기 목표는 30일이었지만 팀들이 제작을 위한 배치와 짧은 실험의 가치를 실감하면서 스프린트의 이상적인 길이가 바뀌었다. 현재 현장에서의 스프린트 길이는 일반적으로 약 2주다. 마찬가지로 할 일도 스크럼 가이드에서 벗어났으며, 백로그 다듬기는 백로그 개선으로 변모했다.
