실용주의이야기(Pragmatic Story)

스크럼에는 단지 3종류의 역할만 존재합니다.: 제품 책임자, 스크럼 마스터, 팀
제품 책임자는 고객을 대변하면서 팀이 개발할 기능에 대한 백로그를 작성하고 백로그 항목에 대한 우선순위를 결정합니다. 스크럼 마스터는 팀에게 스크럼을 소개하고 팀이 스크럼을 제대로 수행할 수 있도록 장애를 제거해 나가는 조력자입니다.

그럼 기존 프로젝트에서 관리자(PM,PL 등) 역할을 했던 사람들은 어떻게 되는 걸까요? 제품 책임자나 스크럼 마스터의 역할을 맡아야 할까요? 프로젝트를 떠나야 할까요?

Case1: 관리자가 제품 책임자 역할을 하는 경우
관리자는 고객을 만나서 요구사항을 받고, 개발해야 하는 업무를 정의하기 때문에 바람직하다고 여겨 집니다. 다만 우선순위나, 개발 범위를 확정할 수 없다는 문제가 있습니다.

Case2: 관리자가 스크럼 마스터를 하는 경우
기존 관리자의 관리 스타일은 명령하고 관리하기(Command and Control)입니다. 스크럼 팀은 자기 조직적인 팀(Self Management Team)으로서 이런 방식에 맞지 않습니다. 관리자가 스크럼 마스터라는 모자를 쓴다면 형식만 갖추었을 뿐 정작 일은 똑같이 진행되는 경우가 많아 좋은 형태는 아니라고 봅니다.

Case3: 관리자 역할을 그대로 유지 하는 경우
기존 관리자의 권한이 매우 축소 됩니다. 소외감을 느낄 수도 있고, 기득권을 놓지 않으려 하면 스크럼 마스터와 충돌이 일어 납니다. 팀원들의 역량을 높이기 위한 멘토 역할을 해야 하는데 그렇지 못한 경우 팀을 떠나야 할 수도 있습니다.
반대 상황도 벌어집니다. 스크럼 마스터가 관리자의 업무를 일부 맡아서 처리해 주는 형태가 됩니다. 실제로 스크럼 마스터가 개발 관련 이슈나 파트간에 조율해야 하는 일들을 도맡아서 챙겨 주지만, 특별히 자기가 하던 역할에서 달라진게 없으니까 좋아하는 사람도 있습니다.

관리자가 어떤 역할로 자리매김을 하던, 서로 협업을 하는 분위기만 잘 조성된다면, 본인이 그런 상황변화를 잘 받아들일 수 있다면 크게 문제되지 않을거라 생각됩니다.
관리자가 어떤 역할로 자리매김을 하는가는 그 사람의 역량에 따라 다를거 같습니다.

• 개발자가 개발한 코드를 확인할 수 있는가
• 서로 협업하는 분위기를 선호하는가.
• 새로운 방식을 잘 받아들일 수 있는가.
  

이런 조건을 만족한다면 어 크게 문제되지 않을거라 생각됩니다.

참고자료
[1] Manager 2.0: The Role of the Manager in Scrum

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.