스크럼은 럭비에서 어깨걸고 맞서는 모습 바로 그거다. (이름 하나는 기차다)
일종의 Agile 방법론이라 할 수 있지만, 섣불리 XP로 연결지을만한 고리는 별로 없다.
다음의 인용구에 공감이 간다면,
책 앞부분의 목차와 한 두장(chapter)만 일별하고도 스크럼에 대해서 아는 척 할만 하다.
리니지2 개발팀은 2년 전 스크럼을 도입한 후로 아침마다 다 같이 모여 일일 스크럼 회의를 합니다. 일일 회의에서는 책에서처럼,
1. 따로 회의실을 잡지 않고
2. 일어선 채로 최대 15분을 넘기지 않고
3. 어제 한 일과 오늘 할 일, 일하는 데 방해가 되는 것 세 가지를 돌아가며 얘기합니다.
스크럼은 누구나(?) 실무에서 부딪치며 깨닫는 바를 가감없이 풀어놓은 방법론(?)으로 보인다.
"성공적으로 개발 프로젝트를 수행하기 위해서"는?
그냥 개발자(개발팀)가 개발에 전념할 수 있게 해 주면 된다. 이를 충족시키는 것이 가장 자연스럽고 상식적인 방법이며, 그걸 좀더 구체적으로 실천 가능한 프로세스로 정리한 게 스크럼이다.
단행본으로 묶여 나올 만큼 새로운 내용은 아니지만, 그만큼 뻔한 내용을 실천하기가 쉽지 않은 것이 현실이다.
그래서 200페이지가 넘도록 소개되는 스크럼의 개요, 방법, 적용, 영향, 가치 보다는 첫 장에 인용된 다음의 문구가 더 인상적이다.
"기술자들의 문제는 변화를 혼돈으로 받아들인다는 데 있다. 특히나 약간의 오류만으로도 전체 시스템을 뻗게 만들 수 있는 경우에는 더더욱 그렇다. 하지만, 변화란 기회일 수도 있다. 단순하게 생각해 보자. 제품에 원하는 기능을 어렵지 않게 추가할 수 있을 시간이 우리에게 있다면, (약간 더 무리해서) 얼마간의 위험을 감수한다면 더 많은 기능을 추가할 수 있지 않을까? 이런 식으로 프로젝트는 서서히 미쳐 돌아가기 시작하게 된다. 우리는 감당할 수 있는 최대한의 위험을 감수하려는 경향이 있는 것이다.