제품 책임자, 제품에 대한 요구사항 즉 백로그(Backlog)를 작성하는 주체다. 팀이 개발할 소프트웨어에 대한 모든 요구사항에 대한 오너쉽을 가진다. 또한 백로그가 준비가 되었으면, 어떤 백로그부터 개발을 해야 할지 우선순위를 정하는 유일한 사람이다.
PO는 팀에 소속되어 있지만, 팀 밖에 있는 여러 이해관계 당사자들(Stakeholders, 고객, 사용자 등)과의 대화를 하는 유일한 사람이 되어야 한다. 보통 이 역할은 소프트웨어 개발 영역에 있는 사람보다는 제품을 사용할 고객이 직접 하거나 비즈니스 요구사항을 정의할 수 있는 사람이 좋다. 소프트웨어 개발 역량은 없어도 된다. 필자 역시 현재 개발하고 있는 제품의 내부 고객에게 해당 역할을 위임한 상태이다.
스크럼 마스터, 스크럼 팀의 스크럼이 잘 수행될 수 있도록 도와주는 역할이다. 간혹, 스크럼 마스터가 과제 리더와 같이 모든 의사결정을 내리는 주체라고 생각할 수 있는데, 그렇지 않다. 스크럼 마스터는 최대한 객관적인 시각에서 스크럼에 정해진 원칙들이 팀에 잘 적용될 수 있도록 도와주고, 문제가 생겼을 때 해결하는 역할을 한다.
여기서 말하는 문제란, 팀 구성원 간의 오해나 이해의 부족으로 인해 생기는 여러 가지 분쟁이나, 하는 일에 대한 우선순위 선정, 일이 끝났을 때 정말로 일이 잘 끝났는 지 내려진 정의를 확인해 보고 투명하게 의사결정을 할 수 있게 가이드하는 역할을 한다.
SM은 스크럼을 잘 아는 사람이 하는 것도 좋지만, 스크럼 팀마다 가지고 있는 성향이나 개성, 일하는 방식이 모두 다르기 때문에 해당 팀에서 애자일, 스크럼 적용에 열려있고 스스로 현재 작업 문화를 개선하고자 하는 의지가 강하다면, 누구나 돼도 상관없겠다. (물론, 하기 싫은 사람 시키면 잘 될 리 없다.)
팀 구성원, 위 두 역할을 제외한 모든 팀원들을 말한다. 일반적으로 스크럼 팀은 Cross-functional 한 롤을 가진 사람들로 이루어져야 한다. 여기서 말하는 Cross-functional이라 함은 제품이 만들어지기 위해서 필요한 모든 인력, 개발자뿐만이 아니라 디자이너와 테스터, 제품을 만들기 위해 참여하는 모든 사람들을 뜻한다.
필자가 본 해외의 한 스크럼팀은 기획자나 예산을 담당하거나 결정할 수 있는 사람도 포함되어 있는 경우를 보았으나, 이는 조금 오버인 듯하다. 제품 개발에 참여하는 모든 사람을 집어넣는 것이 좋겠다. 실은, 이렇게 팀을 구성하는 것도 쉬운 일은 아니다.
필자는 필자가 프로젝트 리더로 있는 프로젝트의 소프트웨어 개발에 참여하는 자사 엔지니어와 협력 업체 엔지니어 전원이 스크럼 팀원에 들어와 있고, 비즈니스 영역의 인력 중 제품의 오너쉽이 있는 부서를 제외한 타 부서들은 제품에 대한 영향력이 많지 않아 팀 안에 배치하지 않았다.
또한, 이런 인력들은 물리적으로 떨어져 있기 때문에 함께 스크럼 팀을 이끌어가기에는 제약 사항이 많다. 꼭 필요한 PO를 제외하고는 스크럼을 함께 하지 않고, 월간으로 진척 현황 리뷰 및 이슈가 있을 때마다 협의하고 있다.
이렇게 구성된 스크럼팀의 크기는 제각각 일 수 있으나, 일반적으로 2개의 피자를 한 끼 식사에 먹을 수 있는 인원(Two-pizza team)인 7~8명을 넘지 않는 것이 좋다. 그리고 필자 생각에는 아무리 인원이 적어도 3명 이상이라면 스크럼을 하는 것이 좋다고 본다. 필자의 현재 스크럼팀은 현재 PO 1명, SM 1명, 팀원 3명이며, 2~3 명 정도의 개발자가 추가될 예정이다.
스크럼에는 이렇게 3가지 롤만이 존재한다. 우리가 흔히들 아는 프로젝트 매니저(PM)나 프로젝트 리더(PL)는 존재하지 않는다. 실은 여기서도 기존의 조직과의 괴리가 느껴지는 곳이기도 하다. 필자는 현재 회사에서 수행하는 작은 프로젝트의 리더이다. 처음 스크럼을 시작하였을 때는 모두 스크럼이 낯설었고, 그나마 경험해본 사람이 필자 밖에 없었기 때문에 PO 및 SM을 프로젝트 리더인 필자가 수행하였으나, 실은 두 역할 모두 스크럼이 아닌 일반적인 프로젝트의 리더가 수행하는 그것과는 차이가 많다. 특히, 함께 하면 문제가 많다.