PM으로서 처음 겪은 애자일 스프린트 회고

입사 후 처음으로 2주 단위 스프린트를 온전히 리드해봤습니다.

이론으로 배운 애자일과 실제로 돌려본 애자일은 꽤 달랐어요.
책에서는 "팀이 자율적으로 계획하고, 매일 짧게 싱크하고, 2주마다 회고한다"고 깔끔하게 정리되어 있었는데, 현실은 훨씬 지저분했습니다.

첫 스프린트 계획 회의 때부터 삐걱거렸어요.
개발팀 리드가 "이건 스프린트 안에 못 끝낸다"고 하면, 저는 일정표에 이미 그 기능을 넣어둔 상태였습니다.
지금 생각하면 당연한 건데, 그때는 제가 뭘 잘못했는지도 몰랐어요.
문제는 제가 "기능 단위"로 일정을 짰고, 개발팀은 "작업 단위"로 공수를 산정한다는 거였습니다.
같은 기능이라도 API 설계, 프론트 구현, 테스트가 각각 며칠씩 걸리는데, 저는 그걸 뭉뚱그려서 "이 기능은 3일"이라고 적어놨던 거죠.

 

가장 크게 느낀 차이는 "완료"의 기준이었습니다.
개발팀은 코드가 머지되면 완료라고 생각했고, 저는 QA와 실사용자 확인까지 끝나야 완료라고 생각했습니다.
스프린트 첫 주는 이 기준을 맞추는 데만 절반을 썼던 것 같아요.
DoD(Definition of Done)라는 개념을 그제서야 팀 위키에 정리해서 붙여놨습니다.
"코드 머지 + 유닛 테스트 통과 + QA 체크리스트 통과 + 스테이징 배포 확인"까지가 완료라고요.
이렇게 문서로 박아두니까 그 다음부터는 "이거 완료된 거 맞아요?"라는 질문 자체가 줄었습니다.

 

두 번째로 배운 건 백로그 정리의 중요성입니다.
스프린트 계획 회의 직전에 백로그를 정리하면 이미 늦습니다.
회의 시작하고 나서야 "어, 이 티켓 설명이 부족하네요"라는 말이 나오면, 그 자리에서 30분이 그냥 날아갑니다.
저는 이후로 매주 금요일 오후를 "다음 스프린트 백로그 다듬는 시간"으로 따로 빼두기 시작했고, 이게 정착되면서 회의 시간이 절반으로 줄었어요.
백로그 정리라는 게 별게 아니라, 티켓마다 "왜 하는지", "어떻게 확인할지", "예외 상황은 뭔지"를 미리 적어두는 것뿐이었는데도 효과가 컸습니다.

우선순위를 정하는 것도 생각보다 감정적인 작업이라는 걸 알게 됐어요.
누구는 이 기능이 제일 급하다고 하고, 누구는 저 버그부터 고쳐야 한다고 하고, 저는 로드맵에 있는 다른 걸 밀어야 한다고 생각하고.
결국 데이터 없이 목소리 큰 사람 의견대로 흘러가는 경우가 많았습니다.
그래서 우선순위 논쟁이 생기면 "이걸 안 하면 어떤 지표가 나빠지는가"를 먼저 물어보는 습관을 들이기 시작했어요.
답이 안 나오면 그 안건은 일단 다음으로 미뤘습니다.

 

마지막으로, 회고(Retrospective)를 형식적으로 하지 않는 게 생각보다 어렵다는 걸 알게 되었어요.
"Keep / Problem / Try"를 적긴 하지만, Try로 적은 항목이 다음 스프린트에 실제로 반영되지 않으면 회고 자체가 의미가 없었어요.
몇 번은 저도 그냥 형식적으로 스티커 메모 붙이고 끝낸 적이 있었는데, 그럴 때마다 다음 회고에서도 똑같은 문제가 또 나왔습니다.
그래서 Try 항목은 반드시 다음 스프린트 백로그에 티켓으로 등록하는 걸 규칙으로 만들어 진행했어요.
"다음에 잘 해보자"는 말이 아니라, 실제로 칸반보드에 티켓 하나로 남기니까 책임 소재도 명확해지고 실행률도 확실히 올라갔습니다.

 

돌아보면 첫 스프린트는 실패에 가까웠던 것 같습니다.
계획했던 것의 절반도 못 끝냈고, 팀원들 사이에 자잘한 오해도 많았어요.
그런데도 이 과정을 거치면서, 완벽한 애자일 팀을 만드는 게 목표가 아니라 우리 팀에 맞는 리듬을 찾는 과정이라는 걸 이 첫 스프린트에서 배우게 되었습니다.

지금도 스프린트를 새로 시작하는 팀을 보면, 첫 두세 번은 삐걱거리는 게 당연하다고 말해주고 싶어요.

중요한 건 그 삐걱거림에서 뭘 고칠지를 팀이 같이 찾아내는 거니까요.