애자일한 PM이 되고 싶어요
[코드스테이츠 PMB 10기] 스크럼 vs 칸반
Product Manager는
애자일의 도르래를 돌리는 사람이다
1. 스크럼과 PM
오늘은 어제에 이어 애자일에 대한 내용을 학습했다. 그중에서도 대표적인 방식인 스크럼(Scrum)을 집중적으로 공부했다. 스크럼이란 팀이 중심이 되어 개발의 효율성을 높이는 애자일의 대표 관리 Practice이다. 스크럼 자체가 소프트웨어 개발 분야에서 발전해온 협업 방식이다 보니 낯설게 느껴지는 것이 사실이다.
읽기 자료 중에서도 위 유튜브 영상에서 스크럼이 작동하는 방식을 손쉽게 이해할 수 있었다. 위 영상에서는 아이스크림 죠스바를 위해서라면 뭐든지 다 하는 가상의 '죠스바 팀'을 예시로 스크럼 시뮬레이션을 확인할 수 있다.
스크럼의 원리
스크럼은 결국 우리는 고객을 잘 모르기 때문에 → 빠르게, 자주 고객에게 릴리즈하고 새롭게 발견해야 하며 → 그렇게 여러 번의 가설 검증을 거치고 → 우리에게 진짜 필요한 것과 피해야 할 것이 무엇인지 파악하면서 → 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있다는 원리에 따라 작동한다.
전 세계 사람들이 스크럼을 이해할 수 있도록 제작된 스크럼 가이드(참고)에 따르면, 스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법을 활용하여 가치를 창출하도록 도와주는 경량 프레임워크이다. 또한, 스크럼은 관찰한 것을 기반으로 의사 결정을 하고 지식을 획득하는 경험주의와 낭비를 줄이고 본질에 초점을 맞추는 린 씽킹(Lean Thinking)을 기초로 한다.
스크럼에는 이러한 점검과 적응을 위한 이벤트가 존재하는데, 크게 다섯 단계로 나뉜다.
스프린트 계획회의, 사용자 스토리와 백로그
스프린트 백로그(sprint backlog) 작성
데일리 스크럼 미팅(daily scrum meeting)
스프린트 리뷰
스프린트 회고(sprint retrospective)
이와 같은 프로세스에서 PM이 수행해야 하는 역할은 무엇일까? 스크럼 가이드에 따르면 PM은 백로그를 효과적으로 관리하는 데 집중한다고 한다. 그러나 이밖에도 목표 수립, 커뮤니케이션, 우선순위 정하기 등 프로덕트와 연관된 많은 이해관계자들의 요구를 대표하는 역할을 수행할 수 있어야 한다.
여기서의 백로그란 이해관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 의미한다. 쉽게 말해 우리가 해야 할 일의 목록이라고 볼 수 있다. 이때 제품 백로그는 고객이나 개발자가 모두 이해할 수 있도록 사용자 스토리에 기반해 작성된 백로그이며, 이 제품 백로그에서 결정된 우선순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 부른다.
결국 애자일에서의 PM은 참 많은 것을 담당하게 된다. 애자일에서의 업무를 수행하는 방법은 조직, 스크럼 팀, 개인에 따라 다를 수 있지만, 궁극적으로 PM은 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는다. 애자일의 굴레(?) 안에서 개발자, 디자이너, 그밖의 이해관계자들이 제 역할을 하며 데굴데굴 굴러갈 수 있도록 끊임없이 기름칠을 하고 도르래를 돌려야 하는 사람이 바로 PM인 것이다.
2. 스프린트는 단거리 질주가 아니다
그러면 위와 같은 스크럼 이벤트에서의 스프린트는 무슨 뜻일까? 단어 자체는 익숙하지만 스크럼에서의 스프린트라는 개념은 낯설지도 모른다. 우리가 알고 있는 스프린트라는 영단어의 의미는 전력질주이다. 그래서 내가 위에 써놓은 소제목과는 달리, 스프린트 = 단거리 질주가 맞다(ㅋㅋ).
그런데 저런 식으로 소제목을 지은 이유는, 맞으면서 아니기 때문이다. 이건 또 무슨 말인가 하는 생각이 들 수도 있겠지만, 스크럼에서의 스프린트는 일직선으로 곧게 뻗은 트랙을 따라 목표 지점을 향해 앞만 보고 달리기만 하면 되는 단거리 질주와는 조금 다른 부분이 있기 때문이다.
스크럼에서는 최소 일주일에서 최대 한 달이라는 기간 동안 우리 팀이 집중해서 일하는 기간을 스프린트라고 부른다. 모든 팀원이 정해진 기간 동안 정해진 목표를 따라 전력으로 달린다는 의미에서는 단거리 질주와 일맥상통한다고 볼 수 있다. 스프린트 가이드에 따르면, 스프린트를 진행하는 동안에는 다음과 같은 규칙을 따르는 것이 좋다.
스프린트 목표 달성을 저해하는 변경을 해서는 안된다.
품질을 떨어뜨려서는 안된다.
필요한 수준까지 프로덕트 백로그를 정제해야 한다.
범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.
스크럼의 꽃, 데일리 스크럼 미팅
그러나 단거리 질주와는 달리, 스크럼에는 데일리 스크럼 미팅이라는 매우 중요한 요소가 포함되어 있다. 데일리 스크럼 미팅(daily scrum meeting)이란 스프린트 진행 중, 팀원들이 하루 업무를 시작하기 전 다함께 모여서 일의 진척과 직면한 문제가 있는지를 이야기하는 자리이다.
위와 같이 팀원들이 스프린트를 진행하는 동안 매일 빼놓지 말고 꼭 해야 하는 일이 바로 데일리 스크럼 미팅이다. 달리기 선수들이 단거리 질주를 하다가 중간중간 멈춰서 고민하고 점검하는 일은 없다. 그러나 스크럼은 어디까지나 개인전이 아닌 팀전이고, "우리가 제대로 가고 있는가?"를 꾸준히 확인하면서 팀원들이 서로를 도와갈 수 있어야 한다.
3. 스크럼 vs 칸반
스크럼 외에 칸반(Kanban)이라는 이름의 애자일 프레임워크가 존재한다. 칸반은 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 처리할 수 있도록 돕는다. 칸반을 활용하면 우선 순위와 크기가 다양한 요청들을 가지고, 작업을 시각화하며 진행 중인 작업의 수를 제한하며 효율성을 추구할 수 있다.
그렇다면 같은 애자일 프레임워크인 스크럼과 칸반에는 어떤 차이가 있을까? 나에게도 두 개념은 새롭고 낯설기에 비교할 필요가 있다고 생각했다. 그래서 다음과 같이 노션의 표 기능을 활용하여 정리해보았다.
이렇게 정리하고 나니 스크럼과 칸반의 차이가 명확하게 구분된다. 이전까지는 스크럼과 칸반 모두 애자일의 하위 개념이므로 유사한 점이 많아 헷갈렸는데, 우리 프로덕트의 상황에 따라 스크럼과 칸반 중 알맞은 프레임워크를 선택할 수 있는 능력이 길러진 느낌이다.
어쩌다 보니 칸반으로 계획을 짜고 있던 나...스크럼과 칸반은 비즈니스에서뿐만 아니라 우리의 일상에서도 적용할 수 있는 개념이다. 특히 계획 짜기에 진심인 ENTJ로서 나도 모르게 칸반을 통해 목표를 수립하고 달성해왔음을 깨달을 수 있었다. 위 사진은 내가 혼자서 취업 준비를 하면서 장기적·단기적 계획을 작성한 노션 페이지이다. 이처럼 스크럼과 칸반을 이해한다는 것은 일상에서도 프로 계획러로 거듭날 수 있다는 가능성을 내포하기도 한다. 이와 같은 공부를 거듭해서 애자일한 PM으로 거듭날 수 있도록 노력하자!
참고자료
