2주 스프린트라는 굴레

(2주 스프린트라는 굴레에 갇혀 발버둥 치는 IT업계의 모든 동지들을 생각하며….. 💪)

스크럼 개발 프로세스에서 반복되는 짧은 개발 주기마다 지속적인 품질과 생산성을 유지하기 위해서는 모든 프로세스 단계가 그에 맞게 최적화되어 있어야 합니다.

정말 군더더기 없이 잘 준비된 아이템을 한 치의 오차와 지연 없이 거뜬하게 해낼 때야 다다를 수 있는 경지가 2주 스프린트가 아닌가 생각합니다.

때문에 많은 IT 조직이 맹목적으로 2주를 겨냥하지만, 기대만큼의 결과를 보지 못하고 업무 피로도만 쌓여가는 경우가 많습니다.

그런데, 정작 스크럼 가이드에서는 스프린트 기간이 꼭 2주여야 한다고 언급하진 않습니다. 대신, 스프린트 주기가 짧을수록 다음과 같은 이점이 있다고 얘기합니다.

• 데모를 더 자주 실시하여 솔루션이 실제 요구 사항에 부합하는지 확인할 수 있는 기회를 더 많이 가질 수 있다.
• 더 자주 회고하여 애자일 프로세스를 실험하고 개선할 수 있는 더 많은 학습 기회를 얻을 수 있다.
• 프러덕 목표 대비 진척을 점검하고 지표를 통해서 추세를 더 빨리 확인하고 시정 조치를 취할 수 있다.
• 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다.

이상적으론 맞는 말이지만, 실무를 보다 보면 마냥 짧은 스프린트 기간은 다음과 같은 문제를 초래하는 경우가 많습니다.

• 시간에 대한 압박이 너무 강해진다.
• 스프린트가 잦아질수록 스프린트의 이벤트(스프린트 플래닝, 회고, 데모)들을 위한 비용(시간)이 증가한다.
• 이벤트가 빈번하다고 느껴지면 식상해지고 결국 이벤트들이 갖는 의미가 퇴색될 수 있다. (학습 기회 X)
• 일부분만으로는 의미 있는 지표를 관찰하기 힘든 경우가 많다.
• 미완료 작업, 기술의 부채, 품질의 부채가 발생할 가능성이 높아지고, 결국 이에 대한 비용이 전가된다.
• 재작업의 가능성도 커진다.

결국, 조직 전체가 하나의 일률적인 스프린트 기간을 따르기보다는, 자기조직화 된 팀이 팀의 정황을 고려해서 가장 적합한 기간을 선택할 수 있어야 합니다. 더욱이 스크럼 방식을 이제 막 도입한 팀이라면 스프린트 기간을 조금은 여유 있게 가져가시고, 체력을 키우면서 조금씩 기간을 줄여가는 과정이 필요합니다.

스프린트 개선점은 Lean 개발 방법론의 ‘7가지 낭비’를 통해 점검해 볼 수 있습니다.

• Work in progress 미완성 작업 (완료 기준을 만족하지 않은 스토리) 배포되지 않은 코드
• Over engineering 특정 결과를 달성하기 위해 필요한 것보다 더 많은 작업을 수행하는 것 고객이 필요로 하지 않는 기능을 추가하는 행동
• Hand-offs 업무 이관, 정보의 전달 전달 과정에서 누락 발생
• Task switching 작업수행 중 다른 작업으로 전환할 경우 집중력 분산 및 시간 소모
• Delays 작업의 지연, 대기 시간
• Relearning 한동안 살피지 않았던 시스템의 일부분에 대한 재학습 Task swtching, hand-off, 요구사항의 변경 시에도 발생
• Defects/Rework 결함은 서비스의 가치를 떨어뜨리는 요소 결함을 수정, 확인, 배포하는 추가 작업 시간 필요 재작업(rework)는 요구사항의 변경 시에도 발생

우리 팀의 개발 스프린트 동안 위와 같은 낭비 요소들이 얼마나 발생하는지 점검해 보고 이를 줄여감으로써 스프린트의 효율성을 높이고, 팀에 맞는 속도를 찾아갈 수 있을 것입니다.