몇달 전, 회사에서 개발 프로세스 세미나를 참석하게 되었다. 세미나 주제는 스크럼이었다. 스크럼이라는 용어는 낯설지 않았는데, 전에 '스크럼' 책을 빌려놓고는 정작 읽어보지 못하고 반납하는 일이 많았기 때문이었다.

지금 기억에 정확하지는 않지만, 세미나를 발표했던 사람이 우리 회사 생산성 연구원에서 근무하는 심우곤 선임이 아니었나 싶다. 애자일 관련 번역서를 읽다보면, 어렵지 않게 찾을 수 있는 이름이다. 누굴까하고 궁금했었는 데, 바로 앞에서 보고도 말한마디 나눠보지 못한게 지금에 와서는 조금 아쉽게 느껴진다.
스크럼하면, 럭비에서의 그것이 제일 먼저 생각난다. 스크럼은 아주 단순 명료하다. 기존의 XP 보다도 더 간단하다. 때문에, 현업에 적용하기가 더 쉬울 것 같다. 스크럼에서 가장 강조하는 두 가지는 스크럼 회의와 스프린트 회의다. 스크럼 회의는 아침마다 10 분 정도의 스탠딩 미팅이다. 어제 무얼했고, 현재 장애가 되는 것이 무엇인지 각자 짤막하게 얘기하는 형식이다. 이를 통해 서로의 일의 진행상황을 알 수 있고, 스크럼 마스터는 팀 구성원의 장애요소를 체크하고 최대한 빨리 없애줄 수 있다. 스프린터 회의는 프로젝트를 진행해가는 데 있어서 한달에 한번씩, 고객과 관리자들을 모아놓고, 한달 동안에 구현한 프로젝트를 직접 보여주는 것이다. 이로써, 고객과 관리자들의 궁금증을 해소할 수 있고, 현재 프로젝트 개발 현황을 파악할 수 있다. 또한 다음 스프린터 회의 때까지 해야할 작업들에 대해 논의할 수 있다.
스크럼의 성패는 스크럼 마스터에 의해서 좌우된다. 스크럼 마스터는 팀 특히 개발자들이 맡은 바 개발에만 전념할 수 있도록 대내외 적인 잡무에 대해 과감하게 쳐 낼 수 있어야 한다. 다시 말해 다음 스프린터 회의까지 구현해야할 항목에 대해서 도움이 되지 않는 것들은 하지말아야 한다.
회사에서 스크럼을 도입한다는 얘기를 들었을 때, 책으로만 봤던 애자일한 개발을 직접 경험해볼 수 있다는 생각에 한편으로는 기뻤다. 하지만, 스크럼을 도입하여 성공하기 위해서는 앞에서 말했던, 환경이 구축되어야 한다.
스크럼은 만병통치약이 아니다. 현재의 문제점, 즉 보여주기식의 특허, 일잘법, 낭비제거등이 고치지 않은 상태에서 스크럼은 아무런 효과가 없다. 스크럼의 성공을 위해서는 용기있는 사람이 필요하다.