분명 익숙한 용어인데, 이렇게 어려운 개념일 줄은..
오늘은 저희 팀에 스프린트를 도입하기 위해 고군분투했었던 사례를 소개드려요.
스프린트 도입을 앞두고 있거나, 의지는 있지만 아직 스프린트를 도입하지 않은 분들에게 도움이 되었으면 좋겠네요
➡️ 입사 후, 프로덕트 개선 작업에 착수했지만, 기존 레거시의 복잡도로 인해 사이드이펙트가 잦아 작업 착수가 어려움
➡️ 당시 진행했던 의도나 목적을 추측할 수 있는 히스토리가 없어서 현재 화면을 기준으로 “당시에 퇴사자가 왜 이렇게 화면을 그렸는지 예측해야 하는 문제 존재
사실 저는 회사 경험이 없다 보니, 이런 문제의식을 몇 달 동안 느끼고는 있었지만, 구체적으로 어떻게 해결할 수 있을지 감이 잘 오지 않았는데요,
다행히 최근에 팀에 합류하신 프론트 개발자분과 이런 고충에 대해 얘기하면서 스프린트를 도입해 보자고 먼저 의견을 주셨고, 일하는 방식이 중요하다는 점에 크게 공감해서 적극적으로 도입하게 되었습니다.
먼저 킥오프를 통해 현재 일하는 방식의 문제점과 그 문제로 파생되는 다른 문제들에 대해 공유했고, 다른 팀원분들과 의견을 나누는 시간을 가졌어요.
다행인지 불행인지 다들 공감하고 있던 문제였고, PM님도 포용적인 스탠스 셔서 도입 이후의 가치에 대해 모두가 공감할 수 있었어요.
다만, 기존 방식보다 추가적인 리소스가 든다는 점이 가장 큰 문제였어요. 구조적인 이유 때문에 평상시에도 PM님이 프로덕트에 집중할 절대적인 시간이 부족한데,
스프린트 플래닝에 추가적인 리소스를 할당하는 것은 사실상 불가능에 가까웠기 때문이에요.
유저스토리 기반으로 큰 줄기를 전달해 주시면 메이커들이 알아서 피쳐를 개발하는 기존 방식에 비해, 스프린트를 이터레이션 돌리기 위해선, 훨씬 더 짧은 기간 동안 더욱 자세히 요구사항이 기획되어야 해요.
또한, 스프린트에 대한 병목도 고려해야 하는 점도 문제였어요.
일반적인 스프린트는 이런 방식으로 애자일을 전제로 진행되고 있죠.
여기서 스프린트 1 종료 후, 스프린트 2 개발을 착수하기까지의 과정이 스프린트에서 가장 큰 병목으로 작용하기 때문에
앞단의 기획자와 디자이너는 스프린트 1이 종료되기 전까지 스프린트 2에 대한 플래닝을 준비해야 해요.
저희 팀 입장에선, 리소스가 부족해서 워터풀방식으로도 진행이 까다로웠는데, 현재 리소스로 과연 다음 스프린트에 대한 플래닝까지 챙길 수 있을지가 가장 큰 걱정이었습니다.
스프린트 플래닝에 대한 팔로업은 제가 자원했는데, 아래의 가설을 생각하고 지속성을 확보할 가능성이 있다고 판단했기 때문이에요.
(물론 개인적으로 PM을 지향하고 있기 때문에, 오히려 좋은 기회라고 생각한 부분도 있었습니다)
➡️ 가설: 플래닝에 필요한 PRD나 문서를 템플릿화 시켜서 하나의 프로세스 시스템으로 만든다면, PM님이 훨씬 적은 시간으로도 유효한 플래닝을 할 수 있을 것이다.
아무튼 스프린트 템플릿에 대한 컨셉은 단순합니다. 학교나 공공기관 같은 저희 도메인 특성상 메인피쳐나 메이저 업데이트가 잦지 않기 때문에,
general한 PRD 형식으로 대부분의 케이스에 대한 커버리지를 일정 수준 이상 높일 수 있을 것이라는 가정하에 1-2일이면 문서를 작성할 수 있을 것이라고 생각했습니다.
이 템플릿화 역시 스프린트 도입을 주도해 주신 프론트 개발자분이 적극적으로 노력해 주신 덕분에 현재는 어느 정도 형식이 구체화된 상태입니다.
여기서 스프린트 도입의 결과와 효용성을 자신 있게 말씀드리고 싶었지만, 사실 아직 스프린트의 효용을 판단할 만큼 이터레이션을 돌리지 못했어요. 정말 최근에 도입을 했거든요..
스프린트는 제품 개발 관점에서 분명 효율적인 방법이지만, 스프린트를 도입한다는 사실에 의의를 두지 않도록 경계할 필요는 있을 것 같아요.
도입을 고려하고 계시다면 정말 우리 팀의 협업방식과 제품의 개발 주기가 스프린트 방식에 fit 한 지 고민해 보시기를 바랄게요!
많은 스타트업이 그렇듯, 단 하나의 제품 스프린트에만 집중할 수 있는 환경이 많지 않다 보니 스프린트를 도입하고 일은 많아졌지만, 제품 개발 속도가 유의미하게 변하지 않을 수 있기 때문이에요.
이걸 어떻게 아냐고요? 자세한 결과와 회고는 다음 글로 찾아오겠습니다