어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

저는 서비스 기획자로 시작해서 현재는 Product Manager로 총 6년동안 일을 하면서 6개의 프로덕트를 런칭하고 운영해오고 있습니다.(사이드 프로젝트는 제외했습니다.) 프로덕트를 개발하면서 워터폴과 애자일 환경을 모두 경험해보았고, 스크럼 팀 역시 다회 운영하고 있습니다.

하지만 고백컨데 주니어 시절의 저는 경험 기반의 직관에 의존하는 Product Manager이자 기획자였습니다. 고객에게 제품의 핵심 가치를 잘 전달하기 위해 필요한 개선점들을 백로그화하고 스프린트를 운영하긴 했지만, 이 제품 개발 프레임워크를 이론적으로 공부한 적은 없었죠.

이런 상황에서 실제 스프린트를 운영하다보니 프로세스적으로 비효율이 발생했고 심지어 비효율이 누적되는 것이 체감되기 시작했습니다. 그리고 몇 번의 이직을 하면서 느낀 점은 스크럼(Scrum)이라는 프레임워크를 제대로 교육하고 정착시켜 스크럼 방식을 통해 얻고자 하는 효과를 얻고있는 회사는 극히 드물다는 것이었습니다.

이 글은 제가 앞서 체감하기 시작한 문제를 해결하기 위해 스크럼(Scrum)을 이론적으로 공부하고 실제 적용해 보면서 배운 점들을 정리하는 동시에 팀에게 스크럼의 목적과 효과, 프로세스를 가이드하기 위해 쓰는 글입니다.

📌 스크럼을 풀어서 설명하면 '팀을 중심으로 문제에 대한 해결 방법을 고객 가치 관점의 솔루션으로 만들어내는 프로세스 프레임워크'라고 할 수 있습니다. 이 프로세스를 날씬하고 날렵한 사고와 이터레이션을 통한 지식 습득(린 씽킹), 이를 통한 반복적인 개선하는 방식(경험주의)으로 운영하면 이상적인 스크럼에 가깝지 않을까 생각합니다.

📌 저는 5명, 10명, 15명 규모의 스크럼 팀을 운영하면서 10명 내외의 크기가 스크럼의 이상적인 팀 크기라고 확신하게 되었습니다. 10명의 크기일 때, 상대적으로 소통이 원활하여 의사결정이 민첩하면서 규모가 있는 가치의 증가분도 만들어 낼 수 있었기 때문입니다.

📌 스크럼 프로세스
1️⃣ 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2️⃣ 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분 Increment of value 으로 만들어 낸다. (*증가분은 스크럼팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미)
3️⃣ 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4️⃣ 반복한다.

본 글의 링크는 아래 첨부합니다.