스프린트가 잘 안되는 이유 (1)

지난 포스팅에서 애자일 / 스크럼 / 스프린트에 대한 이야기를 해보았는데요. 사실 실제로 해보면 잘 되는 느낌보다는 잘 안되는 느낌이 훨씬 더 강합니다. 음... 잘 안되는 이유는 너무 많지만 오늘은 그 중에서 추정에 대한 이야기를 해보려고 합니다.

 

스프린트를 회고하다 보면

 

- 최초 추정이 잘 안되어서 실제로 업무를 끝내는데 시간이 오래 걸렸다. - 그래서 끝내기로 했던 작업을 많이 못 끝냈다. - 그래서 야근을 했다. - 하지만 결국 못 끝냈다.

 

등등의 내용을 많이 듣게 되는데요.

지금 남기는 글이 정답은 아니지만 왜 이러한 결과가 나왔는지 생각해보면 (이건 개인적인 생각과 의견입니다.) 최초에 추정이 제대로 안되었기 때문인 것 같아요. 그러면 최초에 추정을 제대로 하려면 어떻게 해야 할까요?

일단 추정을 하기 위한 노력이 필요합니다. 근데 이 과정에서부터 동의가 안 될 수 있습니다. 왜냐면 많은 분들이 이렇게 생각하거든요.

 

<스프린트 추정 실패 알고리즘>

1. 어차피 지금 추정해도 하다 보면 안 맞는다. 2. 그래서 추정을 대충하게 됩니다. 3. 대충 추정하면 당연히 스프린트 회고에서 추정한 내용이 안 맞는다로 연결되고요. 4. 그러면 다시 대충 추정하게 됩니다. 5. 1번 ~ 4번을 반복하면 스프린트 방법론에 대해서 신뢰하지 않게 되고요. 6. 그러면 스프린트는 우리팀하고 안 맞는 것 같아. 7. 그냥 예전에 하던대로 하자.

 

(그래서 만약에 지금 스크럼팀이 이러한 상황에 놓여 있다면 사실 스크럼이라는 방법론 말고 칸반이라는 방법론을 도입하는 것도 좋은 방법입니다. 왜냐하면 스크럼이 항상 정답은 아니고 팀마다 프로덕트마다 적합한 방법은 다양할 수 있습니다. 그러므로 방법에 얽매이기 보다는 문제를 해결하는 좋은 방법을 선택하는 방향으로 진행하면 좋을 것 같습니다.)

 

저 역시 이러한 과정을 겪어 보았고요. 주변에서 이러한 팀을 많이 보았습니다.

 

그래서 스프린트를 실행하려면 이 방법론에 대한 신뢰가 있어야 합니다. 만약에 “일단 해보자” <= 이러한 마음이 없으면 잘 안될 가능성이 훨씬 더 높습니다. 왜냐면 잘 되는데까지는 시간이 엄청 많이 걸리거든요...

 

 

자 그러면 이제 “일단 해보자”까지 팀의 마음이 모아졌다고 생각하고요. 그런데 그래도 잘 안됩니다. 저 같은 경우에 그래도 잘 안되는 경우는 2가지입니다.

 

1. 해당 스토리/태스크를 하려면 무엇을 해야하는지 모르는 경우 2. 나의 업무 속도를 모르는 경우

그럼 어떻게 해야 추정을 잘 할 수 있을까요?

 

---

 

1. 해당 스토리/태스크를 하려면 무엇을 해야하는지 모르는 경우

 

예를 들어 이러한 스토리가 있다고 생각해보겠습니다.

=> “운영자”는 “데이터”를 “다운로드” 받을 수 있다.

 

스토리를 조금 더 구체적으로 쓸 수도 있습니다.

=> "운영자”는 (“다운로드 버튼을 클릭”하여) “조회목록의 데이터”를 “다운로드” 받을 수 있다.

 

그런데 스토리를 조금 더 자세하게 쓰면 구체적으로 해야 할 것이 정해질 수가 있습니다. 그리고 이 스토리 하나만으로는 추정이 진짜 어렵습니다. 그래서 스토리를 소개해야 하는데요. 이때 프로토타입과 기획서가 필요합니다. 프로토타입은 최종 산출물을 상상하는데 도움이 되고요. 기획서는 최종 산출물에 다가가기 위해서 필요한 정보를 확인하는데 도움이 됩니다.

 

그래서 PM(PO)은 스토리를 잘 소개해야 합니다. 예를 들어 “운영자”는 (“다운로드 버튼을 클릭”하여) “조회목록의 데이터”를 “다운로드” 받을 수 있다. 라는 스토리를 진행하기 위해서는

1. 프론트 작업 - 다운로드 버튼 생성 (위치, 색상 다 맞춰야겠죠.) 2. 프론트 작업 - 다운로드 로딩 중 화면 표시 (더블 클릭 방지, 다운로드 완료까지 다른 작업을 못하도록 로딩 화면 표시) 3. 다운로드 형식 결정 - Excel로 받을 건지, CSV로 받을 건지 결정 4. 제약사항 확인 - 최대 다운로드 row는 몇 개까지인지

 

최소한 이 정도 스토리 소개(프로토타입과 기획서)가 있어야 이 스토리/태스크를 끝내려면 무엇을 해야하는지 파악할 수 있고 이 때 스크럼팀(개발, PM 모두) 내에서도 어떤 작업이 필요한 파악할 수 있습니다. 그리고 스토리 소개 후에 플래닝 포커를 진행하게 되고요. 포인트 부여하고 포커의 숫자를 서로 맞춰보는데요. 이 때 나누는 대화가 굉장히 중요하다고 생각합니다. 누군가는 2점, 누군가는 5점, 누군가는 20점이라고 생각하는지 이야기하면서 해당 스토리/태스크에 대한 서로의 개발 방향(해결 방향)을 이야기 하다 보면 팀 정보가 동기화되고 결국 가장 좋은 방향을 선택하게 되기 때문입니다.

 

---

 

2. 나(팀)의 업무 속도를 모르는 경우

 

이 경우는 스스로 업무를 하면서 나의 업무 시간을 돌이켜 볼 필요가 있습니다. 사실 이 경우는 어떤 포지션의 역할을 수행하는 사람이든지 필요한 역량이라고 생각합니다. 경력있는 PM, 개발자, 디자이너 등등 어떤 포지션이든 “OO업무”를 수행할 때, “(자신이 업무를 수행했을 때) OO 정도 걸리겠다”를 예측할 수 없다는 것은 경력보다 경험이 없다는 것을 의미일 수도 있고요. 혹은 경험을 쌓을 때 생각보다 무관심했었을 수도 있고요.

 

그러면 경험도 충분히 있고 유사한 경험에 대한 감도 있다고 해서 추정이 잘 될 수 있을까요? 사실 그럼에도 불구하고 팀의 속도를 추정하는 것은 여전히 어렵습니다. 그 이유는 아직 안해봤기 때문이죠. 그래서 처음에는 추정과 실제 사이에 차이가 발생하는 것이 당연합니다. 하지만 처음에는 알 수 없지만 두 번째 이후부터는 조금씩 되어간다는 느낌을 갖는 것이 중요합니다.

 

그러다 보면 점점  팀의 추정이 실제와 어느 정도 일치하게 되고 이러면 예측가능성을 확보하게 되는 것이죠. 사실 추정한다는 것은 정말 어려운 일입니다. 하지만 그렇다고 해서 이 추정 작업을 포기하면 스프린트가 잘 될 가능성이 매우 어렵습니다. 스프린트가 성공했을 때 추정이 잘 안 된 경우는 없기 때문이죠. 즉, 추정 작업의 성공이 스프린트 성공을 보장하진 않지만 성공한 스프린트는 항상 성공적인 추정 과정이 있었다는 점입니다. (추정 과정의 성공이 추정과 실제가 항상 일치하는 것을 의미하는 것은 아니고요.)

 

스프린트가 잘 안 되는 이유(1)로 추정 작업의 실패를 한 번 소개해 보았습니다. 혹시 더 좋은 스프린트 운영 경험담에 대해서 알고 계시면 언제든지 공유해주세요. 소통은 항상 열려 있습니다. ^^

 

이상 끝.