[2023-12] 스크럼 가이드 리뷰

안녕하세요. 오늘은 스크럼 가이드를 여러 번 읽어보면서 이해했던 내용들을 남겨보려고 합니다.

같은 제품개발실 PM님 덕분에 스크럼 가이드의 한국어 버전이 있다는 것을 알게 되었고,
한번 읽어봐야지 했던 게 시작이었습니다.

한번 읽어보니깐 이해 안 되는 부분이 많아서 여러 번 읽어보니 스크럼 가이드의 의도가 조오오오금 보이더라고요.

스크럼 가이드에서 이해되지 않았던 부분들을 어떻게 이해하게 되었는지 중점적으로 기록해 보겠습니다.

---

Q. 스크럼 가이드에서 이해되지 않는 부분들

Q1.  스크럼 가이드가 왜 이렇게 딱딱해?

스크럼 가이드를 보면 개요 부분부터 스크럼 가이드를 무조건 준수하라는 글을 볼 수 있습니다.

스크럼 가이드는 스크럼의 정의를 담고 있다. 스크럼 프레임워크의 각 요소는 특정한 목적을 이루기 위해 설계된 것이고, 스크럼으로 실현하려는 전체적인 가치와 결과에 필수적이다. 스크럼의 핵심 설계와 발상을 변경하는 경우, 특정 요소를 배제하는 경우 또는 스크럼 규칙을 따르지 않는 경우에는 어떤 문제가 있는지 알 수가 없고 스크럼의 이점을 충분히 살릴 수도 없다. 심지어 스크럼을 쓸모없는 것으로 만들 수도 있다

저는 이 부분부터 굉장히 어색하다고 느꼈습니다.

스크럼과 같은 애자일한 개발 방법론들은 프로젝트의 불확실성을 염두하고 만들어졌습니다.

'애초에 불확실성을 염두하고 만들어진 프레임워크라면 사용자가 적절히 변경하는 것이 당연한 것 아닌가?'

그런데 무조건 따르라고만 하니 이상한 것이었죠.
 

Q2. 스프린트 계획은 얼마나 정확해야 하고, 얼마나 시간을 투자해야 하나? 

한 때, 매 스프린트마다 긴 시간을(2시간 이상) 투자해서 스프린트 계획을 한 적이 있습니다.
 
작업들의 크기를 추정하기 위해서 티셔츠 사이즈 혹은 스토리 포인트를 사용하고, 실현 가능한 계획을 위해 모두 함께 플래닝 포커를 했습니다.
 
하지만 스프린트 계획은 계속해서 부정확했으며, 긴 시간을 투자하는 것도 모두에게 피로감을 주었습니다.
 
그때 당시의 저희들은 스프린트 계획에 긴 시간을 투자하지 않기로 결정했고, 백로그에 있는 작업들 중에서 우선순위가 높은 순으로 업무를 진행했습니다.
 
과연 어떻게 하는 게 좋은 선택이었을까요?
 

Q3. 데일리 스크럼 어떤 효과가 있는 건가?

혹시 데일리 스크럼을 진행하면서 어떤 효과를 누리셨나요?
 
저 같은 경우는 팀에서 데일리 스크럼을 진행하다가 큰 효과를 체감하지 못해서 이를 그만뒀습니다.
 
1) 다른 제품을 만들고 있는 구성원분들과는 이해하기 어려운 이야기를 하고,
2) "어제 한 일"과 오늘의 Todo 리스트를 한 일을 읽는 것이 전부였습니다.
 
이렇게 진행되다 보니 팀원분들도 '데일리 스크럼 빈도를 줄이자', '효과를 모르겠다' 같은 의견을 많이 주셨고,
 
저희들은 데일리 스크럼을 진행하지 않기로 결정했습니다.
 

A. 스크럼의 목적은 자율관리조직을 만드는 것!

위 질문들의 답을 찾기 위해 스크럼 가이드를 여러 번 읽었습니다.

• 지금 생각하면 스크럼 가이드를 여러 번 읽을 것이 아니라 온라인, 오프라인에서 다른 분들의 의견을 물어보는 게 훨씬 좋은 방법이었던 것 같습니다!

여러 번 읽고 집중하게 된 키워드는 "자율관리조직"이었습니다.
 
스크럼은 자율관리조직으로 거듭나기 위한 프레임워크인데 이를 의도하지 않고 단순히 따르기만 하면 되는 것이라고 생각한 것이 패인이었습니다.
 
자율관리조직이라는 키워드를 가지고, Q3, Q2, Q1을 다시 살펴보겠습니다.
 

A3. 명확한 스프린트 목표가 있어야 의미 있는 데일리 스크럼이 진행된다.

데일리 스크럼은 누군가에게 일일 보고하는 시간이 아닙니다.
스크럼 팀의 개발자들간의 소통을 향상시키고, 스프린트 목표를 이루는데 방해되는 장애물을 식별하는 시간입니다.
 
만약 데일리 스크럼 시간이 불필요하다고 여겨진다면,
스프린트 목표가 명확한지, 그리고 스크럼 팀원 모두가 스프린트 목표를 동일하게 이해했는지 검토해야 합니다.

이를 확인하는 가장 간단한 방법으로 스프린트 목표와  스프린트 목표를 이루기 위해 무슨 업무를 진행하고 있는지 물어보는 것이 있습니다.

• "스프린트 목표보다 주어진 업무만 완료시키면 된다" 라고 생각하면 데일리 스크럼과 같은 소통 시간을 불필요하게 여길 수 있습니다.
• 하지만 스프린트 목표를 달성하는 것이 가장 중요하다고 얼라인 되었다면 데일리 스크럼 시간이 절대 불필요하다고 여기지 않을 것입니다.

 
이 외에도 개발자들이 장애물을 잘 식별하고 있는지를 고려할 수 있습니다.

• 많은 개발자들이 자신의 작업이 장애물에 막혀 있는지 식별하는데 어려움을 겪습니다. 실제로 이를 식별할 명확한 방법이 없기도 하고요;;
• 이를 해소하는 방법으로 팀 차원에서 4시간 이상 진척이 없으면 문제가 있다고 판단한다. 등의 규칙을 정하는 것이 있습니다.

 

A2. 스프린트 계획은 프로덕트 목표를 달성하는데 도움이 되는 실현 가능한 스프린트 목표를 잡는 것

A3.에서 말씀드렸던 "스프린트 목표를 달성하는 것이 가장 중요하다고 얼라인"이 이뤄지기 위해서는
팀원 모두가 필요하고, 이번 스프린트에 실행되어야 한다고 공감할 수 있는 목표를 세워야 합니다.
 
그 기준이 바로 1) 프로덕트 목표를 달성하는데 얼마나, 어떻게 도움이 되는지, 2) 실현 가능한지 입니다.
 
저 같은 경우에는 1) 프로덕트 목표가 명확하지 않아서 어려움이 컸습니다.
 
관제 시스템을 어떻게 개선해 나가야 할지 방향을 잡지 못해서 명확한 스프린트 목표를 세우지 못했고,
이로 인해 팀이 스프린트 동안 어떤 업무들에 집중해야 하는지 알기 어려웠죠...
 
 
2) 실현 가능성도 중요합니다.
 
스프린트 목표를 너무 크게 잡고, 이를 억지로 달성하기 위해 팀원들의 야근이 종용된다면 사기와 소통 저하로 이뤄질 수 있습니다.
 
또한, 스프린트 목표를 너무 적게 잡아도 할 일이 없어서 사기 저하로 이뤄질 수 있습니다.
 
저는 스프린트 목표의 최소 75%는 기간 내에 확실히 완료될 수 있게끔 계획해야 한다고 생각합니다.

• 25%를 끝내지 못했더라도 우선 순위가 높지 않은 작업일 확률이 높아서 다음 스프린트에서 챙겨도 괜찮았습니다.
• 스프린트 기간 내에 빠르게 스프린트 목표를 달성하더라도 적당하게 정비 시간을 가질 수 있습니다.

 
마지막으로 이를 만족하는 스프린트 목표를 수립하기 위해서 시간을 얼마나 소요해야 할까요?
 
2주 스프린트는 스프린트 계획에 최대 4시간 이상을 소요하지 않는 것을 권장하더라고요.

• 일반적으로 스프린트 1주 당 스프린트 계획에 최대 2시간을 할당합니다.

 

A1. 설명하기 어려우니  가이드가 이렇게 딱딱한 것, 너도 일단 경험해 봐

위에 적은 A3, A2도 데이터나 이론에 기반한 것이 아닙니다.
 
지금까지의 제 경험과 자기관리조직이라는 키워드에 비춰서 더 좋은 방법을 도출한 것입니다.
 
누군가 특정 상황을 가정해서 저에게 질문한다면 저는 명확한 답변을 드리지 못할 것입니다.
 
하지만 그 상황이 실제로 온다면 직접 경험해보고 더 나은 방법을 찾을 수 있을 것입니다.
 
그래서 일단 경험해보는 것이 중요합니다.
 
P.S.
괜히 "포괄적인 문서보다는 작동하는 소프트웨어를"이라는 문구가 생각나네요.

---

애초에 스크럼이 경험주의적인 프레임워크이기도 하고,
직접 팀원들과 사용해 보면서 공부해야 할 부분들이 많기 때문에 저와 다르게 이해한 분들도 많을 것이라고 생각합니다.

하지만 좋은 제품을 만들자는 최종 목표는 동일하기 때문에 모두 통할 것이라고 믿어 의심치 않습니다 :)
 
피드백은 언제나 환영입니다!