W8D2 | 스크럼과 스프린트 환경에서 PM/PO는 어떤 역할인가? [코드스테이츠 PMB 12기]

오늘은 1990년대 초반에 스크럼을 개발한 켄 슈와버 & 제프 서덜랜드가 스크럼의 목적과 이해를 위해 쓴 <스크럼 가이드>를 바탕으로 글을 작성 되었다.

---

 

프로덕트 오너는 애자일 개발 방법으로 잘 알려져 있는 스크럼 프로세스에서 탄생하였다.

▶ 애자일은 무엇인가?

2001년, 소프트웨어 업계를 주도하는 리더들이 애자일 소프트웨어 개발을 위한 선언을 다음과 같이 공표 하였다.

애자일 소프트웨어 개발 선언

애자일 개발 방법은 스프린트 스크럼(Sprint Scrum), 칸반(Kanban), 유저 스토리(User story), 익스트림 프로그래밍(Extreme Programming) 등이 있다. 그 중에서 가장 널리 활동되는 방법은 스크럼의 프로세스이다.

---

▶ PM/PO에게 스크럼이란?

PM/PO는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 이 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있다. 

프로덕트 오너는 프로덕트 백로그를 효과적으로 관리하는 것에도 책임이 있는데, 다음 사항들을 포함한다:
⚫ 프로덕트 목표를 세우고 명쾌하게 소통하는 것;
⚫ 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것;
⚫ 프로덕트 백로그 아이템을 우선순위에 따라 정렬;
⚫ 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.

프로덕트 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임을 위임한다. 어떤 식으로 하든지 최종 책임은 프로덕트 오너가 갖는다.

프로덕트 오너가 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중해야 한다. 프로덕트 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라 정렬한 것을 통해 확인할 수 있다. 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다.

프로덕트 오너는 한 사람이지 여럿으로 구성된 위원회가 아니다. 프로덕트 오너는 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다. 프로덕트 백로그를 변경하고 싶은 사람들은 프로덕트 오너를 설득하여야 한다.

가이드를 읽고 느낀점으로 PM/PO가 스크럼을 진행하는데 있어 맡고 있는 일은 다음과 같다.
✅ 다른 사람에게 책임을 위임하여 일을 진행하기도 하지만 최종적인 책임은 PO/PM에게 있다. 
✅ 성공적으로 프로덕트를 만들기 위해서는 조직 전체가 그의 결정을 존중해야 한다.
✅ 책임이 있는만큼 다양한 이해관계자와 소통해야하며, 그만큼 설득을 시켜야하고 이해를 시켜야하는 자리이다.

---

▶ PO/PM에게 스프린트란?

스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다. 

스프린트는 꾸준함을 갖기 위해 한달 또는 그보다 짧은 기간으로 고정된 길이의 이벤트이다. 새로운스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.

스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 프로덕트목표를 달성하기 위해 필요한 모든 업무를 수행한다. 

스프린트 기간 동안에는:

⚫ 스프린트 목표 달성을 저해하는 변경을 해서는 안된다;
⚫ 품질을 떨어뜨려서는 안된다.
⚫ 필요한 수준까지 프로덕트 백로그를 정제해야 한다;
⚫ 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.

스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.

 

진척을 예측하는 데에는 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트, 누적 흐름도 Cumulative flows 와 같은 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다.

스프린트 목표가 효력이 없게 되면, 스프린트를 취소할 수 있다. 오직 프로덕트 오너만이 스프린트를 취소할 결정권을 갖는다.

가이드를 읽고 느낀점으로 PM/PO가 스프린트를 진행하는데 있어 맡고 있는 일은 다음과 같다.
✅ 작성된 백로그 중, 우선순위/중요도/시급도에 따라 스프린트를 진행할 업무를 결정한다.
✅ 팀원들이 협력해 스프린트 목표를 정의하고, 이번 스프린트의 중요한 이유를 공유하고 목표 대비 적절한 기간을 설정해야한다. 
✅ 이해관계자와 소통을 통해 현재 팀이 가지고 있는 장애물을 파악하고 백로그를 세분화해 업무를 계획한다.

 

---

▶ 언제 칸반? 언제 스크럼?

칸반과 스크럼의 업무수행 방식 차이를 살펴보며, 어떠한 환경에서 칸반 또는 스크럼을 사용해야하는지 알아보겠습니다.

칸반은 ‘우선순위와 크기가 다양한 요청들을 가지고, 작업을 시각화하며 진행 중인 작업의 수를 제한하며 효율성을 추구함'.

스크럼은 협업, 작동하는 소프트웨어, 팀 자체 관리, 신속한 대응과 같은 유연성을 강조함.

※ 업무 흐름 - 
시간에 제한이 없고 효율성을 추구한다면 칸반

제한적인 시간을 기반을 둔다면 박스 프레임 워크인 스크럼

 

※ 업무 절차 -
유동적인 업무 진행은 칸반

의존성이 높은 계획과 회고를 원하면 스크럼

※ 회의 -
칸반에서 회의는 daily meeting, risk review, strategy review와 같은 여러 회의

스크럼에서는 회의는 의무적이고 매일 같은 시간에 개최되며 스크린트 계획, 데일리 스크럼, 스프린트 리뷰, 회고와 같은 회의

 

※ 작업 보드 -
작업의 시각화, 효율성과 흐름을 극대화하는것을 목표로 하는 칸반 보드는 병목 지점을 파악하는 작업 흐름을 최적화할 수 있는 도구로 활용되며, 상태/진행 상황/문제를 알리고 공유하는 것이 목적임.

스프린트 백로그는 제품에 필요한 것으로 판단된 모든 항목은 제품 백로그에서 파생되고, 스프린트 백로그의 가장 일반적인 항목은 사용자 스토리를 사용하며, Sprint 중에는 비즈니스 요구 사항, 시장 상황 및 기술의 변경을 제외하고, 새 항목을 추가하거나 변경할 수 없음.

---

짧은 회고

오늘은 제품 기획의 바이블이라 불리는 마티 케이건의 <인스파이어>의 내용에 내 생각을 붙여 회고하겠다.

사람들은 항상 제품을 만드는 마법의 무기를 찾는다. 그리고 해당 산업의 누군가로부터 저서, 코칭, 컨설팅을 언제든 제공받을 수 있는 상황이기를 기대한다. 하지만 마법의 무기 같은 것은 없으며, 항상 스스로 찾아야만 한다. 
린, 워터폴과 애자일은 마법의 무기가 아니다. 하지만 PM/PO는 그것을 현명하게 활용할 줄 알아야 하기에, 알아야 한다. 

최고의 제품팀들은 세 가지 중요한 핵심 원칙을 따르고 있다.
1️⃣ 위험은 마지막보다는 초기에 대응한다.
2️⃣ 제품은 순차적인 방식보다는 함께 협업하며 정의되고 설계된다.
3️⃣ 끝으로, 기능을 구현하는 것이 아니라 문제를 해결한다.