Small Steps Blog

애자일블로그의 복리의 비밀에 언급되듯이 팀과 워크그룹은 서로 다르다.

"Implementing Lean Software Development"에서도 그 차이를 간단히 묘사한 부분이 있다.

워크그룹과 팀

1. 아침 일일회의에서 전원이 전날 한 일을 보고한다. 한 사람 씩 보고가 끝날 때마다 프로젝트 관리자가 이렇게 말한다. "좋아요, 조이. 그럼 오늘은 이것, 이것을 해주세요." 각자 그 날의 과제를 받아 자리로 돌아간다.

워크그룹의 모습이다. 업무를 할당함으로써 모든 일을 완료하는 책임은 프로젝트 관리자가 가지게 된다. 팀원들은 프로젝트의 목표를 달성하기 위해 상호 협력하는 등의 책임을 지지 않는다. 

2. 아침 일일회의에서 전원이 전날 무엇을 했고, 오늘 무엇을 할지, 어떤 도움이 필요한지를 보고한다. 산지브는 다른 팀원들에게 어려운 기능이 아직 미처리 상태임을 상기시킨다. "아직 누구도 그 기능을 손대지 않았다면 시간 안에 그 기능을 마치기가 어려울 것 같습니다. 제가 한 번 해보겠습니다." 산지브는 다음을 덧붙인다. "그런데 먼저 이 문제를 해결해야만 합니다."

마이크가 대답한다. "그 문제라면 제가 작업 중인 것보다 더 중요한 것 같습니다. 하지만 제가 아직 익숙치 않은 부분이네요."

산지브는 마이크가 시작할 수 있도록 두어 시간 정도 도와주기로 제안한다.

그리고 나서 스크럼마스터는 팀이 현재 펌웨어 인터페이스를 가지고 씨름하고 있음을 지적하고 오후에 펌웨어 팀의 개발자와 두 명 정도가 같이 회의를 하면 도움이 되겠냐고 물어본다. 세 명이 회의에 참석하겠다고 한다.

팀의 모습이다. 회의는 팀원 전체가 공동으로 합의한 목표를 어떻게 달성할 것인지에 초점을 맞추고 있다. 스크럼마스터는 팀이 도움을 필요로 하는 부분을 찾아 돕는데 초점을 맞추고 있다.

- Implementing Lean Software Development, Poppendieck, p.127

본문에는 분명 "워크그룹이 나쁜게 아니다"라고 말하지만, 팀이 필요한 상황에 워크그룹이 있다면 문제임에는 틀림없다. 그리고 대부분의 소프트웨어 개발 조직이라면 팀이 필요하다.

예전에 마이크로소프트에서 한 명의 수석개발자에 다수의 개발자를 붙여 의사소통 채널의 단순화를 꾀한적이 있다는 얘기를 들었다. 개발자들은 자신이 개발할 부분에 대해 수석개발자하고만 대화를 나눈다는 것인데, 그것이 성공적이었는지는 잘 모르겠다.

이러한 특수한 상황을 제외한다면 대개의 경우 무자르듯 깔끔하게 작업을 나눌 수 있는 경우란 많지 않다. 개인의 능력이나 전문 분야도 제각각이다. 공동의 목표를 달성하기 위해서는 서로의 능력을 한데모아 곱하기 할 수 있어야 할 것이다.

개인적으로는 '공동의 목표', '곱하기' 이런 이유들보다 '즐거움' 측면에서 봤을 때 워크그룹보다는 팀에서 일하는 것이 더 즐겁기 때문에 나는 팀에서 일하고 싶다.