애자일, 스크럼 팀에서의 PM / PO의 역할은?
스크럼과 스프린트 이야기 [코드스테이츠 PMB 16기]
이 글은 Ken Schwaber & Jeff Sutherland의 스크럼 가이드를 기반하여 작성되었습니다.
자세한 내용은 아래의 링크를 방문하여 읽으실 수 있습니다.
스크럼(Scrum)이란?
스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법 (Adaptive solutions)을 활용하여
가치를 창출하도록 도와주는 경량 (Lightweight) 프레임워크이다.
간단히 말해서 스크럼은 다음과 같은 환경을 조성하는 것이다.
1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2. 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분 Increment of value (*증가분은 스크럼 팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미한다.
3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4. 위 과정을 계속 반복한다.
그렇다, 스크럼은 간단하다.
제시한 그대로 시도해 보고, 스크럼의 철학, 이론, 구조가 목표를 달성하고
가치를 창출하는데 도움이 되는지 판단해야 한다.
스크럼 프레임워크는 의도적으로 불완전하게 오직 스크럼 이론을 구현하는데 필요한 부분만 정의하고 있다. 스크럼은 스크럼을 사용하는 사람들의 집단지성을 기반으로 만들어진 것이다.
사람에게 상세한 지침을 주는 것보다는 스크럼 원칙은 사람들 간의 관계와 소통을 안내하는 것이다.
물론 프레임워크 안에서 다양한 프로세스, 테크닉, 방법을 이용해 볼 수 있다.
그래서 기존의 실천법을 스크럼 프레임워크 내에서 수행할 수 있다.
또한 스크럼으로 인해 기존의 업무 방식이 불필요해질 수도 있다.
현재의 관리, 환경, 업무 기법과 관련된 효과를 스크럼을 통해 가시화하여 개선을 할 수 있다.
Scrum 단어의 기원인 럭비 Scrum의 모습 / 사진 출처 = UnsplashScrum의 어원은 럭비에서 왔다, 럭비 경기 중에 경미한 반칙이 있은 후에
이어서 경기를 진행함에 있어 각 팀이 어깨동무를 하고 머리들을 마주 댄 상태에서
서로 밀고 나가려는 자세를 취하게 되는데, 이를 Scrum을 이라고 표현한다고 한다.
팀이 머리를 마주 댄 상태에서 계속 이어서 서비스의 개선 / 구축을 위해 밀고 나가려는 자세와
구체적 목표와 계획, 그것이 IT에서의 스크럼의 모습인 것이다.
PM / PO가 스크럼을 관리하는 방법
프로덕트 매니저 / 오너는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다.
이 업무를 수행하는 방법은 당연히 조직, 스크럼 팀, 개인에 따라 다를 수 있다.
프로덕트 매니저와 오너는 프로덕트 백로그를 효과적으로 관리하는 것에도 책임이 있는데,
다음 사항들을 포함한다.
• 프로덕트 목표를 세우고 명쾌하게 소통하는 것
• 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
• 프로덕트 백로그 아이템을 우선순위에 따라 정렬
• 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.
프로덕트 매니저 / 오너는 위에 나온 일을 직접 하거나 혹은 다른 사람들에게 그 책임과 과업을 부여한다.
어떤 식으로 하든지 결국, 최종 책임은 프로덕트 매니저 / 오너가 갖는다.
프로덕트 매니저 / 오너가 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그들의 결정을 존중해야 한다.
프로덕트 매니저 / 오너가 내린 결정들은 프로덕트 백로그의 내용과 우선순위에 따라
정렬한 것을 통해 확인할 수 있다, 또한 스프린트 리뷰 때에 점검 가능한 증가분을 통해서도 볼 수 있다.
프로덕트 매니저 / 오너는 한 사람이지 여럿으로 구성된 조직이 아니지만,
프로덕트 매니저 / 오너는 프로덕트 백로그와 연관된 많은 이해관계자들의 요구를 대표한다.
프로덕트 백로그를 변경하고 싶은 구성원들은 프로덕트 매니저 / 오너를 대화하고, 설득하면 된다.
PM / PO는 스크럼을 철저히 관리하기 위해 맡은 R&R이 엄청나다고 볼 수 있다.
스크럼은 결국 팀으로 운영되며 같이 걸어 나가지만, 걸어 나갈 방향(목표)은 PM / PO가 명확히 정해야 하며
그 책임과 의무를 다해야 하는 어렵고도 막중한 역할을 담당하고 있다.
목표와 우선순위를 명확하게 정하고 스크럼 팀이 나아가야 할 방향을 설계해야 하는 PM, PO / 사진 출처 = UnsplashPM / PO가 스크럼 팀으로 스프린트를 진행하는 방법
스프린트는 아이디어를 가치로 만들어 내는 이벤트로 마치 스크럼의 심장 박동과 같다.
스프린트는 프로젝트들을 꾸준히 반복하기 위해 한 달 또는 그보다 짧은 기간으로 정해진 길이의 계획이다.
새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.
스프린트 동안 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를
포함하여 프로덕트 목표를 달성하기 위해 필요한 모든 업무를 수행한다.
스프린트 기간 동안에 유의해야 할 사항들은 이러하다.
스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
• 품질을 떨어뜨려서는 안 된다.
• 필요한 수준까지 프로덕트 백로그를 정제해야 한다.
• 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비
진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다.
스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나
복잡도가 늘어나고 리스크가 높아질 수 있다.
더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고,
짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다.
각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.
진척을 예측하는 데에는 번 다운 Burn-downs 차트, 번 업 Burn-ups 차트,
누적 흐름도 Cumulative flows와 같은 다양한 방식이 있다.
이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다.
복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다.
단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다.
스프린트목표가 효력이 없게 되면, 스프린트를 취소할 수 있다.
오직 프로덕트 매니저 / 오너만이 스프린트를 취소할 결정권을 갖는다.
위와 같은 스프린트 과정을 효과적으로 진행시킬 수 있는 훌륭한 프레임워크가 존재한다.
바로 스크럼 프레임워크이다.
스크럼 프레임 워크
스크럼 프레임 워크 / 이미지 출처 = https://www.scrum.org/resources/blog/scrum-framework-illustrated스크럼 프레임워크의 과정은 이러하다.
1. 스프린트 계획 회의 및 사용자 스토리와 백로그 설정
스프린트 계획 회의에서는 제품 책임자가 사용자 스토리를 기반으로 제품 백로그를 작성한다.
제품 백로그는 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나
개발할 제품에 대한 요구사항 목록을 말한다.
사용자 스토리는 고객이나 개발자가 모두 이해할 수 있도록 고객이 작성하거나,
고객이 서술하는 형식으로 작성되어야 한다.
일반적으로 유저스토리의 작성은, '나는 ~로써 ~하기 위해 ~하고 싶다’라는 형식으로 작성하며
who, why, what 정보가 모두 포함되어 있어야 한다.
제품 백로그는 이 유저 스토리를 바탕으로 작성된다.
이런 식으로 유저스토리를 한 문장으로 정의하면, 모든 팀이 커뮤니케이션하기에 용이하다는 장점이 있다.
2. 스프린트 백로그(sprint backlog) 작성
제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안
해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다.
제품 백로그가 할 일 목록이라면, 스프린트 백로그는 짧은 기간 동안 할 일 목록이다.
일반적으로 스프린트 기간은 적게는 1주~2주 길게는 한 달 정도로 설정한다.
그다음엔 스프린트 목표를 구현할 수 있도록 각각의 요구사항을
task 단위로 나누어 개발자들이 나눠서 작업을 수행한다.
많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데
이것을 스크럼 보드(Scrum Board)라고 한다.
3. 데일리 스크럼 미팅(daily scrum meeting)
일일스크럼 미팅은 개발원들이 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다.
매일 정해진 시간에 정해진 장소에 모여 15분~20분 동안 간단하고 빠르게 진행한다.
어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애요인 등을 공유하며 문제가 있으면
미팅 후 바로 해결한다.
일일 스크럼 미팅함으로써 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방한다.
일일 스크럼 미팅 시에 번다운 차트 등과 같은 그래프를 팀원들과 함께 확인하고,
PM은 일이 늦어지는 이유를 찾아내서 이슈를 해결해줘야 한다.
4. 스프린트 리뷰
스프린트 리뷰는 스프린트가 종료되었을 때 개발팀이 스프린트 동안
개발한 기능을 고객을 포함한 이해관계자들에게 보여주고 피드백을 받는 과정을 말한다.
고객은 자신이 요청한 요구사항이 해당 스프린트동안 제품이 잘 반영되었는지 평가한 후
피드백하면 프로덕트 오너는 고객의 피드백이나 여러 사항을 정리하여
다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다.
스프린트 기간에 해내지 못한 것이 있어도, 모두 다시 하는 것이 아니라,
스프린트 리뷰를 통한 피드백과 새로운 우선순위를 정해서,
모두 종합적으로 우선순위를 나누고 스프린트의 기간과 프로젝트 양을 다시 정하게 된다.
스프린트의 한 주당 스프린트 리뷰 시간은 한 시간으로 제약되어 있으며
스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다.
5. 스프린트 회고(sprint retrospective)
스프린트 리뷰가 제품 기능에 대한 회고라면,
스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을
도출함으로써 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다.
스프린트 리뷰는 개발한 기능에 대한 리뷰라면,
스프린트 회고는 전반적인 스프린트 과정에 대한 리뷰라고 보면 된다.
스프린트 회고 과정에서 스크럼 마스터 또는 PO는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator),
촉진자 역할을 하게 된다.
스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라
프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.
그래서, 스크럼 팀에서 PM/PO의 R&R은?
내용을 읽어보면 알 수 있듯, 제품 관리자(PM)와 책임자(PO)가 가지고 있는 R&R의 무게는 어마어마하다.
감히 팀을 조직하고, 운영해야 하며, 모두가 공유하는 뚜렷한 목표를 설정해야 하고,
성과로 이어지게 해야 하며, 그것을 무한히 반복해야 한다.
PM/PO의 R&R 너무나도 가혹하다고 생각할 수 있지만, 해내야 하는 역할은 생각보다 심플할 수 있다.
완벽주의가 아닌 완성주의의 태도와 목표로 애자일 하게 팀을 나아가게 하는 것,
팀이 설정한 목표에 구성원들이 몰입, 몰두할 수 있도록 방해 요소를 최소화시키는 것,
어차피 또 그다음이 있기에, 다 함께 실패에서 배우고 성공에서 성취를 느끼며 팀을 건강하게 만드는 것,
이 내가 생각하는 이상적인 PM / PO의 스크럼 팀에서의 역할이라고 생각한다.
위와 같은 표현들이 이상주의적이라는 것은 나도 동의한다, 하지만 이상을 꾸준히 좇다 보면 언젠가
현실에서 꿈꿔왔던 이상을 마주치게 될 수도, 경험하게 될 수도 있다는 게
나의 생각이고 직접 겪어본 경험이다.
위에 정리한 PM의 역할은 사실 스크럼 팀에서 국한되는 것이 아니라,
내가 평생 가지고 가고 싶은 이상적인 PM의 역할이라고 볼 수 있다.
오늘도 이상적인 PM의 모습을 더 고민해 보고 꿈꾸며, 오늘은 이만 글을 마무리해보려 한다.
참고 문헌 및 아티클
https://www.scrum.org/resources/blog/scrum-framework-illustrated
