1장 배경: 스크럼 과학<br/>___경험주의적 프로세스 제어<br/>___복잡한 소프트웨어 개발<br/>___스크럼의 구조와 핵심 <br/>___스크럼 내의 역할<br/>___스크럼의 흐름<br/>___스크럼 산출물<br/>______제품 백로그<br/>______스프린트 백로그<br/>______제품 기능 증가분의 출시 가능성<br/>___정리<br/><br/>2장 관리자의 새로운 책임<br/>___메타에코의 스크럼 마스터<br/>______메타에코 상황<br/>______실전에서의 스크럼 마스터<br/>______스크럼 마스터의 가치 <br/>___메가에너지의 제품 소유자<br/>______메가에너지 상황<br/>______실전에서의 제품 소유자 <br/>______제품 소유자의 가치<br/>___서비스퍼스트 팀 <br/>______서비스퍼스트 상황 <br/>______실전에서의 팀<br/>______팀의 가치<br/>___결론<br/><br/>3장 스크럼 마스터<br/>___트레이 리서치의 훈련 안 된 스크럼 마스터<br/>______무엇이 문제인가<br/>______교훈<br/>___리트웨어의 훈련 안 된 스크럼 마스터 <br/>______무엇이 문제인가<br/>______교훈<br/>___콘토소 닷컴의 과욕<br/>______옳은 것이 전부는 아니다<br/>______교훈<br/>___메가펀드의 늑대들<br/>______늑대의 습격<br/>______교훈<br/>___결론<br/><br/>4장 혼돈 속에서 질서 찾기<br/>___서비스퍼스트 상황<br/>______스크럼 적용 <br/>______교훈 <br/>___트리 비즈니스 출판사 상황<br/>______스크럼 적용 <br/>______교훈<br/>___랩색 상황 <br/>______스크럼 적용 <br/>______교훈<br/>___결론<br/><br/>5장 제품 소유자<br/>___고객과 팀의 협업<br/>___서비스퍼스트 경영진의 현장 복귀 <br/>______스프린트 검토 회의<br/>______교훈<br/>___메가펀드의 엑스플로우 문제 해결 <br/>______문제 제기<br/>______교훈<br/>___테크코어의 목표<br/>______스크럼이 테크코어를 어떻게 도왔나<br/>______교훈<br/>___메가뱅크 이체 시스템의 목표 <br/>______스크럼이 FTS 프로젝트를 어떻게 도왔나<br/>______교훈<br/>___결론<br/><br/>6장 스크럼 프로젝트 계획수립<br/>___메가뱅크의 현금 관리<br/>______2일간 스프린트 계획수립 회의<br/>______교훈<br/>___투자회수율에 관한 공인 스크럼 마스터의 시각<br/>______MLBTix<br/>______각기 다른 팀 반응<br/>______교훈<br/>___결론<br/><br/>7장 프로젝트 보고: 가시성 확보<br/>___메가에너지 타이틀 프로젝트를 위한 새로운 프로젝트 보고<br/>______문제 해결<br/>______교훈<br/>___메가뱅크에서 더 많은 정보 얻기<br/>______문제 해결<br/>______교훈<br/>___서비스퍼스트의 모든 것이 가시적이지는 않다<br/>______현실<br/>______교훈<br/>___결론<br/><br/>8장 팀<br/>___서비스퍼스트의 팀 형성<br/>______누가 책임자인가: 전환<br/>______관리 잘하는 법 배우기: 전환<br/>______자기조직화 배우기: 전환<br/>______업무량 추정하기: 전환<br/>______일하면서 즐기는 법 배우기: 전환<br/>___웹뉴사이트 팀에게 기회 부여하기<br/>______배경<br/>______교훈<br/>___결론<br/><br/>9장 스크럼을 사용한 프로젝트 규모확장<br/>___메가펀드의 확장<br/>______접근법<br/>______교훈<br/>___스크럼 확장<br/>___메드신소프트의 확장<br/>______접근법<br/>______버그 수정<br/>______교훈<br/>___결론<br/><br/>부록 A 규칙<br/>___스프린트 계획수립 회의<br/>___일일 스크럼 회의 <br/>___스프린트<br/>___스프린트 검토 회의 <br/>___스프린트 회고 회의 <br/><br/>부록 B 용어 정의<br/><br/>부록 C 참고자료<br/><br/>부록 D 가격과 날짜가 확정된 계약<br/>___경쟁우위 차지하기<br/>___경쟁우위 무시하기<br/><br/>부록 E CMM<br/>___메가펀드의 CMM<br/>___SEI, CMM, 그리고 스크럼

"슈와버가 기록을 또 하나 세웠다. 우리가 모든 애자일 방법론의 핵심 기법과 개념을 이해하도록 이 책을 써준 것이다."<br/>- 로버트 C. 마틴(엉클 밥) / 오브젝트 멘토 사의 사장이자 창립자 <br/><br/>"이 책을 통해 켄은 전 세계의 스크럼 팀을 멘토링하고, 공인 스크럼 마스터를 가르치며 쌓은 경험을 확실히 보여준다. 소프트웨어를 개발하는 방법을 향상시키고자 하는 모든 이에게 훌륭한 지침서다."<br/>- 마이크 콘 / 공인 스크럼 마스터이자 애자일 얼라이언스 이사 <br/><br/>"이야기를 들으며 배울 수도 있나요? 저는 그래요. 진짜 애자일이 무엇인지 이야기로 풀어 쓴 완전한 책을 마침내 얻을 수 있었어요. 놀라워요."<br/>- 브라이언 매릭 / 프리랜서<br/><br/>복잡한 프로젝트를 관리하는 간단한 체계인 스크럼에 대한 규칙과 실천방안은 간결하고 직설적이며 배우기도 쉽다. 하지만 구체적 방안이 없는 스크럼의 간결함 때문에, 많은 전문가가 오래된 프로젝트 관리 습관이나 도구로 다시 돌아가 좋지 않은 결과를 얻기도 한다.<br/><br/>스크럼의 공동 창시자이자 전도자인 켄 슈와버는 이 책에서 제시하는 여러 실제 사례를 통해, 애자일 프로젝트 관리를 수행했던 여러 회사에 대한 수많은 코칭 경험을 바탕으로 성공과 실패에 대한 살아있는 교훈을 들려준다. 독자는 이 교훈을 통해, 스크럼으로 복잡한 문제를 해결하고, 더 빠르고 더 가치 있는 소프트웨어를 만드는 방법을 이해할 수 있을 것이다.<br/><br/>스크럼 이론과 실천사항을 이해하면,<br/>■ 아주 복잡하고 다루기 힘든 프로젝트라도 통제할 수 있다.<br/>■ 드러나지 않았거나 변하는 제품 요구사항을 효과적으로 관리할 수 있다.<br/>■ 스스로 관리하는 개발팀을 통해 명령체계를 단순화할 수 있다. <br/>■ 고객으로부터 명확한 요구사항과 피드백을 받을 수 있다. <br/>■ 프로젝트 계획수립에 필요한 시간과 도구를 획기적으로 줄일 수 있다. <br/>■ 제품을 30일 주기로 개발, 배포하므로 고객은 제품을 더 신속하게 인수할 수 있다. <br/>■ 주기적으로 제품 검사, 보고 및 세심한 조율을 통해 실수를 피할 수 있다. <br/>■ 지리적으로 분리된 대규모 프로젝트를 함께 수행하는 다수 팀을 지원할 수 있다. <br/>■ 투자 대비 효과를 극대화한다.

새로 온 상관이 이상한 사람은 아니었지만, 그 당시에는 그렇게 보였다. 그때 우리는 회사의 대용량 콜 센터에 적용할 새로운 소프트웨어를 개발하는 중이었다. 개발 기간이 12개월 정도 소요될 것이라고 보고했지만 상관은 겨우 4개월만 허락했다. 물론 4개월 후에 바로 새 소프트웨어를 사용해야 할 필요는 없었지만, 그때부터 상관이 해준 일이라고는 실행일 30일 전이라는 통보뿐이었다. 처음 4개월이 지난 후부터는 소프트웨어를 30일 내에 배포할 수 있도록 유지해야 했다. 상관은 4개월 후에 모든 기능이 완성되지 않으리란 걸 알고 있으면서도 가능한 한 빨리 많은 것을 얻고 싶어했고, 나는 그 일을 가능하게 해줄 프로세스를 찾아야 했다. 가능한 모든 소프트웨어 개발 프로세스를 찾아보다가, 마침내 스크럼과 켄 슈와버의 초창기 저서를 접할 수 있었다.

첫 번째 스크럼 프로젝트를 수행한 이후 수년간 나는 상업 제품, 내부용 소프트웨어, 컨설팅 프로젝트, 그리고 ISO 9001 요구사항을 갖춰야 하는 프로젝트에까지 스크럼을 사용해왔다. 프로젝트 하나하나가 다 독특했지만 긴급하고 중요한 프로젝트라는 점에 있어서는 모두 같았다. 스크럼은 조직에 중요한 긴급한 프로젝트에서 그 진가를 발휘한다. 또한 요구사항이 알려져 있지 않거나, 요구사항 자체를 알 수 없거나, 혹은 요구사항이 변하는 경우에 효과적이며, 팀이 뛰어난 능력을 발휘하게 해주는 데도 탁월하다.

이 책에서 켄 슈와버는 스크럼이 어렵다고 정확히 지적한다. 우리가 하는 일 때문에 어려운 것이 아니라 하지 않는 일 때문에 어렵다고 한다. 프로젝트 관리자라면 스크럼에는 전통적인 도구가 몇 가지 빠져 있음을 쉽게 알 수 있다. 스크럼에는 간트 차트가 없고, 보고 시간도 없고, 프로그래머에게 작업을 할당하지도 않는다. 대신 스크럼이 가진 몇 가지 단순한 규칙을 배우고, 좀 더 중요한 소프트웨어를 더 빨리 만들어내기 위해 상황을 자주 점검하고 조정하는 법도 배워야 한다.

켄 슈와버는 스크럼 초기부터 활동해왔다. 켄은 제프 서덜랜드와 함께 스크럼의 창시자이며 지금까지도 최대 지지자다. 켄이 지금까지 참여해온 여러 스크럼 프로젝트에 대해, 이 책을 통해 읽어볼 수 있다. 켄은 산업 관련 컨퍼런스에 빈번하게 출연하는 인기 강사인데, 혹시 그의 강연을 듣는다면 그가 필요 없는 말을 부풀려 하지 않는다는 사실을 알 수 있다. 이 책도 마찬가지다. 켄은 과거의 스크럼 프로젝트 중에서 성공한 프로젝트와 실패한 프로젝트 모두를 제시한다. 켄의 목표는 프로젝트를 성공시키기 위한 방법을 가르치는 것이므로, 우리가 따라 할 수 있는 예제는 물론, 피해야 할 반례도 제시한다.

이 책은 지금까지 스크럼 팀을 멘토링하고, 전 세계에서 공인 스크럼 마스터 과정을 가르쳐온 켄의 경험을 반영한다. 이 책에 담긴 많은 이야기를 통해 켄은 혼자서 터득한 수많은 교훈을 우리에게 나눠준다. 소프트웨어 개발 방법을 향상시키고자 하는 모든 사람에게 훌륭한 가이드임이 분명한 이 책을 강력히 추천하는 바다.
마이크 콘 (공인 스크럼 마스터이자 애자일얼라이언스 이사)

스크럼은 왜 통하는가?

내가 비행기를 타고 시카고에서 보스턴으로 여행하고 있다 치자. 비행 전이나 비행 중 조종사는 항공관제센터에서 지시를 받는다. 명령에 따라 이륙하고, 정해진 루트를 따른다. 항공상에서는 컴퓨터가 보스턴에 언제 착륙할지 분(分) 단위까지 예측해준다. 대기가 불안정한 경우처럼 변경사항이 생기기라도 한다면, 조종사는 고도를 달리할 수 있도록 관제센터에 허락을 구한다. 공항에 접근하면 조종사는 어느 활주로에 착륙할지, 그리고 몇 번 게이트로 가야 하는지도 지시받는다.

하지만 내가 자동차로 보스턴을 간다면, 내가 원하는 루트로 내가 원하는 때에 갈 수 있다. 정확히 언제 도착할지 모르고, 어떤 경로를 택할지, 숙박은 어디서 할지 전혀 계획하지 않을 수도 있다. 하지만 가는 도중 나는 교통법규를 따라야 한다. 빨간 불에는 멈추고, 정해진 규칙에 따라 교통흐름에 합류하고, 그 흐름에 맞춰 속력을 유지해야 한다. 자동차 안에서는 내가 독립적인 주체이므로, 운전이라는 게임의 규칙에 따라 내 관심사에 최대한 맞춰 의사결정을 한다.

중앙 통제나 배차 서비스 없이도 단순한 교통 규칙에 따라 수천 수만 명의 사람들이 목적 달성을 위해 매일 차로 이동하고 있다는 사실은 경이로운 일이다. 물건을 보내고자 할 때도 택배회사의 웹사이트에 접수 요청을 하면 택배기사가 내가 정한 시간에 우리 집 문 앞에 도착한다는 것도 놀라울 따름이다. 택배기사가 각 가정에 배치되어 있진 않지만, 주소와 배달 시한이 지속적으로 갱신되는 목록을 받는다. 하지만 모든 배송 물품을 제시간에 접수할 수 있도록 경로를 정하는 것은 택배기사의 몫이다.

일이 복잡해질수록, 중앙 통제와 배차 시스템은 허물어진다. 누군가는 좀 더 엄격히 적용해 통제 시스템이 작동하도록 노력을 기울일 수도 있고, 그렇게 해서 시스템이 한시적으로 작동하게 만들 수도 있다. 하지만 결국에 승리하는 사람은 바로 적절한 규칙하에 운영되는 독립적인 체계로 변환시키는 방법을 알아내는 사람이다. 하루 일과의 시작 시간에 기사의 루트를 계획해주는 배차 시스템이 있다면 당일 배송도 가능하다. 하지만 고객이 언제라도 원하는 접수 시간을 요청할 수 있다면 물품 접수 루트를 미리 계획하는 일은 훨씬 더 어려워진다. 그래서 택시회사는 주로 중앙통제센터에서 관리를 하고, 택배회사는 해당 지역을 담당하는 기사에게 접수 요청을 한 후, 기사가 현재 상황과 기타 요구사항을 토대로 최상의 노선을 스스로 결정하게 한다.

시스템이 복잡할수록, 중앙 통제 시스템이 허물어질 확률은 높다. 이런 이유로 기업은 분산을 택하고 정부는 규제를 철폐한다. 독립적 조직으로 통제권을 이양하는 것은 복잡함을 다루는 전통적인 접근 방법이다. 스크럼은 통제권을 중앙 일정 관리와 권한 분배에서, 현업의 개별 팀에게 이양하는 방법을 통해 이미 잘 다져진 경로를 밟아간다. 프로젝트가 복잡할수록, 현업에 가까운 독립적 조직에게 의사결정권을 이양하는 일이 더 필요하다.

스크럼이 통하는 또 다른 이유는 고객과 개발자, 요구사항과 구현, 투자와 투자수익률 간의 피드백 주기를 현저하게 줄여주기 때문이다. 다시 말하자면, 복잡함이 그 사이에 존재한다는 의미다. 시스템이 단순할 때는 무엇을 해야 할지 미리 알기가 그리 어렵지 않다. 하지만 항상 변화하는 시장 경제와 정체되지 않은 기술을 다룰 때는, 짧은 주기 발견을 통해 배우는 것이 시도를 통해 알아가는 적극적인 문제 해결 방법이다.

우리 모두 이 사실을 알고 있다. 그래서 다양한 마케팅을 실시해보고 어떤 방법이 효과가 있는지 파악해낸다. 자동차를 설계할 때는 자동차 보닛의 최상의 곡선과 최상의 무게 배분을 알아내기 위해 자동차 움직임을 시뮬레이션해본다. 거의 모든 프로세스 향상 프로그램은 문제를 조사하고, 해결방안을 시도해보고, 결과를 측량하고, 검증된 향상 방법을 수용하는 데 데밍(Deming) 주기를 사용한다. 우리는 이와 같은 방법을 사실에 근거한 의사결정법이라 하는데, 이 방법이 미리 예측하는 방법보다 훨씬 효과가 있다는 사실도 잘 알려져 있다.

스크럼은 완전한 비즈니스 개념을 구현하는 30일 학습 주기에 기초해 만들어졌다. 모든 것을 알고 있고, 알아야 할 게 아무것도 없다면 스크럼을 사용할 필요가 없다. 하지만 무엇인가 배워야 한다면, 비즈니스 가치를 점진적 결과로 배포하는 것을 강조하는 스크럼은 신속하고 완전한 배움이 이뤄지는 데 도움을 준다. 완전한 점진적 결과가 중요한 이유 중 하나는 불완전한 답은 실제 자세히 살펴보면 접근법이 효과가 없는데도 마치 그 접근법이 효과가 있는 것처럼 착각을 불러일으키기 때문이다. 소프트웨어를 테스트하고, 통합하고, 생산을 위해 배포하기 전까지 해당 소프트웨어가 목적하는 비즈니스 가치를 가져다줄 것인지 누구도 확신할 수 없다. 스크럼은 우리가 만든 것을 테스트하고, 통합하고, 제품을 출시하도록 권장하므로 30일마다 완전한 학습 주기가 이뤄진다.

스크럼은 비즈니스 가치의 점진적 결과가 무엇이든 그것을 전달하는 데만 중점을 두는 게 아니라, 고객이 정의한 최고 우선순위의 비즈니스 가치를 전달하는 데 초점을 맞춘다. 제품 책임자와 팀이 정의된 요구사항이 무엇인지 상의하고, 팀은 최우선순위의 비즈니스 가치를 전달하기 위해 30일 내에 무엇을 할 수 있는지 결정한다. 그러면 짧은 피드백 주기는 비즈니스 피드백 주기가 된다. 스크럼은 테스트를 일찍 수행하고, 개발 중인 시스템이 가치를 만들어낼 것인지, 그리고 그 가치가 정확히 어떤 형태로 나타날지 점검한다. 스크럼은 그 가치를 제대로 이해하는 데 도움을 줄 뿐만 아니라, 이해한 상태 그대로의 가치를 전달하기 위한 체계를 형성한다.

스크럼이 통하는 또 다른 이유는 한 가지 문제에 여러 사람의 두뇌를 촉발시키기 때문이다. 문제가 생기면 문제가 있다는 사실을 아는 누군가가 있겠지만 어찌된 영문인지 이들의 생각은 종종 무시된다. 예를 들어, 우주비행선이 재돌입 시점에 폭파됐을 때 이 재앙의 원인을 여러 가지로 보고한 해석에 따르면, 문제가 생길 수도 있음을 간파한 엔지니어가 있었지만 그 엔지니어에게는 문제를 심각하게 피력할 능력이 없었다. 완성해야 할 업무에 가장 근접해 있는 사람의 경험과 생각, 그리고 관심사를 활용하기 위해 어떤 관리 시스템을 사용할 수 있을까?

켄터키 주재 도요타 자동차 공장의 사장인 개리 콘비스(Gary Convis)에 따르면, 건전하고 번영하는 업무 환경에 있는 관리자의 역할은 "의견이나 명령의 힘이 아니라, 본보기와 지도, 그리고 다른 이들의 목표를 이해하고 성취할 수 있도록 도와줌으로써 조직의 틀을 형성하는 것"이라고 했다.

스크럼은 소규모 팀을 스스로의 운명을 책임지는 관리자로 바꿔준다. 보스턴으로 가는 경로를 스스로 선택하는 책임감을 갖는다면 목적지로 도달하는 길을 찾게 될 것임을 우리는 알고 있다. 상황에 따라 의사결정을 하고, 다른 운전자의 판단에 맞춰가며, 공사현장은 우회하고, 출퇴근 시간대는 피해간다. 이와 마찬가지로, 스크럼 팀은 문제를 받아들이고 문제를 해결할 방법을 파악해서, 중앙통제와 배차센터로는 계획할 수도 없는, 창의적인 방법으로 장애물을 우회해간다.

팀의 모든 멤버가 참여하도록 서로를 격려하고, 팀원이 스스로의 운명을 책임질 수 있다고 느낀다면 개인의 경험과 생각, 그리고 관심사를 억압하는 대신, 이들을 활용할 수 있다. 팀원 모두가 믿음을 갖고 공통의 목적을 서로 공유한다면 모두 목적을 성취할 방법을 함께 찾아낼 것이다. 팀이 고객의 비즈니스 가치를 이해하고 이를 전달하고자 노력하고, 태스크를 수행할 방법을 스스로 찾아내며, 필요한 자원을 배정받는다면, 팀은 반드시 성공할 것이다.

개리 콘비스는 도요타의 지속적인 성공이 "밑바탕에 깔려 있는 서로 맞물린 세 가지 요소, 즉 철학적 토대, 관리 문화, 기술적 도구"로부터 나온다고 했다. "철학적 토대는 협력하고, 고객을 위하고, 사람을 중시하며, 지속적인 향상을 위한 노력을 하는 데에 기반을 둔다. … 그리고 관리 문화는 … 여러 요소에 뿌리를 두는데, 팀워크, 모두에게 공정하고 평등한 대우, 마지막으로 사실에 근거한 의사결정과 장기적인 사고에 영향을 받는 사람을 참여시키는 일을 통해, 신뢰를 쌓고 유지하는 일을 말한다."

스크럼은 이와 같은 이유로 성공적으로 적용할 수 있다. 철학적 토대는 개발팀에게 권한을 부여하고 고객을 만족시키는 데 중점을 둔다. 관리 문화는 목표를 달성하도록 남을 돕는 데 근거한다. 기술적 도구는 학습 과정을 통해 사실에 기반한 의사결정을 중시한다. 이와 같은 모든 요소가 준비됐다면, 스크럼이 실패하는 일은 쉽게 일어나지 않을 것이다.
메리 포펜딕 (포펜딕.LLC)