팀의 목표는 스크럼이 아니라 프로젝트의 성공이다. - 스크럼이나 애자일의 함정

예전에 한창 게임 개발을 하던 개발자 시절에 K팀장을 통해서 처음으로 스크럼 개발론이라는 것을 접하게 되었다. 물론, K팀장도 완벽한 팀장은 아니고 우리 역시 완벽한 팀원은 아니었기 때문에 스크럼이라는 것을 도입했을 때 어떻게 일이 이루어질 것인가에 대해서는 예측할 수 없었다. 일단 시도 해보는 수밖에 없었다. 

그 때 접한 스크럼 개발의 느낌은 다음과 같았다.

장점. 

1. 개발의 진척이나 프로세스가 시각화 된다.

2. 전체적으로 위에서 내려다 보면 뭔기 일이 진행되는 느낌이다.

3. 우리가 해야할 일에 대해서 놓치지 않는다.

단점.

1. 인간을 도구로 인식하게 되는 것 같다.

2. 정이 없는 커뮤니케이션이 이루어지다 보니 조직에 금방 질린다.

3. 아무래도 일정에 시달리는 느낌이 든다.

4. 컨트롤 받고 있다는 느낌이 들면서 생산력의 저하가 이러난다.

우리의 목표는 무엇인가

처음에는 바뀐 개발 환경에 대한 부담감이 클수밖에 없었다. 어느정도 팀원들이 나름대로 우리가 스크럼이라고 불리우는 어떤 개발 프로세스에 적응해나갈 무렵부터, 슬슬 팀원들의 누수가 일어나기 시작했다. 

적어도 내 생각으로는 우리의 프로젝트 개발이 메인 주제라기 보다는 스크럼이나 애자일이 팀의 목표가 되고 있다는 생각이 들었다. 그런 부분들이 나를 굉장히 힘들게 했었다. 뭔가 항상 보고하고 리포트 하는 과정에서 조직이 사실 적당히 숨겨야 할 것들도 있고 여론화 시켜서 가져갈 부분들도 있는데 스크럼은 그런 것들이 너무 적나라하게 드러났다.

중요한 것은 커뮤니케이션

이 와중에서 정작 우리가 놓친 것이 무엇이냐면 커뮤니케이션이었다. 커뮤니케이션 없이 일의 진척과 진행 과정만 리포트 한다면 기계를 돌리는 일꾼에 불과하다는 느낌을 지울 수가 없었다. 결론적으로 가만히 둬도 알아서 움직이는 목표지향형 인재들에게는 이것 조차 하나의 굴레를 씌우게 되는 셈이다.

오히려, 다소 수동적이지만 업무지향형 인재들에는 이런 부분들이 필요했다고 본다. 누군가 스크럼이나 애자일 프로세스를 시도해보자라고 이야기를 한다면, 과연 왜 그런 이야기가 나왔는지부터 먼저 생각해 봐야 한다는 것이 내 생각이다. 전제의 전제부터 살펴보니 그랬다. 

역시 도입해본 결과

새로운 회사에 가서 초창기에 나도 역시 비슷한 스타일로 스크럼을 도입해봤다. 프로그래머 S군과 서브기획 C군을 데리고 수행해봤다. 처음에는 나름 진행되는 양상은 비슷했고, 나름 소기의 목표들도 이루어낼 수 있었다. 적어도, 조직력을 강화하는 측면은 있었다. 하지만, 어느 시점이 되자 바로 스크럼 개발을 치워버려야겠다는 생각이 들었다. 

이미 조직내에 충분한 커뮤니케이션과 개발이 가능했고, 그 상태에서 스크럼이 도입되어야할 목표는 이미 달성했다는 느낌이 들었던 것 같다. 자연스럽게 스크럼은 이미 불필요한 프로세스가 되어가고 있었다.

프로젝트의 성공을 위해 존재할 뿐이다.

곰곰히 생각해보면 팀의 목표는 프로젝트의 성공이지, 스크럼이나 애자일을 얼마나 잘 수행했는지가 중요한 것은 아니다. 어떨 때는 전통적인 폭포수 모델의 개발 방식이 프로젝트의 성공에 더 적합할 수도 있었다.

정말 새로운 방법을 도입해서 프로젝트를 성공시키고 싶은 것인지, 아니면 더 이상 야근을 하기 싫다는 것인지 살펴 봐야한다. 무엇이든 팀원들에게 충분한 이해와 상황에 대한 대화가 먼저이다. 결국에 스크럼이든 애자일도 궁극의 목표는 더 많이, 더 자주, 더 꾸준히 피드백을 주고받자는 취지에서 출발한 것이라는 것이다.