스크럼(Scrum)과 애자일(Agile)

매일 스크럼을 활용하여 프로젝트를 운영해 나가면서 느끼게 되는 점들이 있습니다.

전반적인 관점에서 보면 스크럼을 제대로 적용하고 있느냐 나아가 스크럼이나 애자일프로세스를 사용하고 있느냐는 크게 문제가 아닐 수 있습니다. 프로젝트의 방향타를 잡고 있는 선장과 그 배를 실제로 움직이는 선원들이 얼마나 하나로 뭉쳐져 있느냐, 일을 통해 얼마나 즐거움을 느끼느냐(일하는 분위기가 즐거운 것일수도 있지만 매일매일 발전하는 스스로를 볼 때 느끼는 자부심측면이 더 강합니다), 옆의 동료들이 얼마나 자신들의 업무에 몰입하고 있으며 진지한가 등이 실제적인 성공요소라고 생각합니다.

문제는 그러한 것들의 요소중에 많은 부분이 프로세스나 방법론으로 만들어지기는 어렵다는 것입니다.(특정 방법론들이 도움을 주기는 하지만 그럴 자세가 되어 있는 사람들이 우선 있어야 한다는 전제가 있습니다) 서로 교감하고 있지 않은 사이의 개발자들 혹은 개발자-관리자 사이에서 Daily Scrum을 한다고 저절로 모든 문제가 해결되지 않습니다. 오히려 개발자들의 시간이 더 낭비되고 더 많이 체크당한다는 피해의식에 사로잡히기 쉽습니다.

사실 현실세계에서는 7~8명의 팀을 만들면 거의 항상 1명 정도는 문제가 되는 인원이 생깁니다. 그 사람이 마침 Project Leader인 경우도 있고(그럼 상대적으로 고통의 시간이 줄어들고 빨리 망하게 됩니다) 모든 팀회의에서 드러내지 않고 패배의식을 전파하는 팀원인 경우도 있습니다. 방법론이나 프로세스가 그러한 1명의 어려움을 쉽게 극복하게 도와주면 좋겠지만 무슨 방법을 쓰던 그 문제가 되는 인원으로 인하여 전체적인 퍼포먼스나 팀 분위기, 팀 비젼에 대한 공유가 어려워지고 목표달성이 어렵게 됩니다.

너무도 당연한 이야기라서 무슨 방법론이나 프로세스, 철학의 근처도 못가지만 제가 지금까지 체험한 바로는 높은 Intelligence를 가진, 서로 신뢰할 수 있고 존경할 수 있을 정도로 믿음이 가는 사람들로만 팀이 구성된다면 심지어 폭포수형 방법론을 채택하더라도 실제로 동작하는 것은 그 방법론을 처한 상황에 최적화하여 사용하고 있을 것입니다. 왜냐하면 그러한 사람들의 집합이라면 본인들이 처한 상황을 그대로 받아들이는 것이 아니라 개선시킬려고 끊임없이 고민하고 노력할 것이며 목표를 달성하는 데 가장 어울리는 방법이라면 굳이 무슨 무슨 방법론에 그다지 구애받지 않을 충분한 집단지성이 발휘될 것이기 때문입니다.

실용주의 프로그래머에서 제시한 많은 팁이나 XP나 스크럼같은 애자일 방법론, 각종 Spring이나 Ruby on Rails같은 개발Framework들은 그러한 집단지성이 성과를 Maximazation할 수 있도록 도와주는 타인들의 공통적인 경험이나 Tool로써 사용될 수 있습니다.

책을 번역하면서 우려되는 바는 혹시 우리가 지금까지 써온 방법으로는 잘 안되었으니 "스크럼"이라는 새 방식을 쓰면 좀더 좋아질까하는 방식으로 접근할까봐 걱정됩니다. 체중을 감량하지 않으면 아무리 다른 색깔의 옷을 입어도 멋있게 보이지 않습니다. 툴이나 방법론 등에 책임을 전가하기 보다는 자신의 팀, 더 나아가 자신을 되돌아보면서 내가, 우리가 이 소프트웨어 개발이라는 업무에 얼마나 진지한지 물어볼 필요가 있습니다. 이런 근본적인 문제가 어느 정도 해결된 후에야 여러 방법론이나 툴이 도움이 될 것입니다.

Agile Process, SCRUM!!! 호기심 탐구 결과.