애자일 팀의 회고(Retrospective) 잘 하는 법

 

회고를 몇 년째 진행하다 보면, 어느 순간 회고 자체가 형식이 되어버리는 시기가 옵니다.
저희 팀도 그랬어요.
매 스프린트 끝나면 회의실에 모여서 포스트잇에 Keep, Problem, Try를 적고, 다 같이 붙이고, 몇 개 투표하고 끝내는 패턴이 반복됐습니다.
그런데 어느 순간 팀원 한 명이 "우리 이거 3주 전에도 똑같이 얘기했던 것 같은데요"라고 말했고, 그 말에 다들 조용해졌던 기억이 있어요.

 

회고에서 나온 Problem이 다음 스프린트에 실제로 개선되지 않으면, 회고는 그냥 감정 배출구가 되어버립니다.
저희가 겪었던 문제는 Try 항목이 "노력하자", "신경 쓰자" 수준의 다짐으로 끝나는 경우가 많았다는 거였어요.
"코드 리뷰를 더 꼼꼼히 하자"는 Try는 누가 언제 무엇을 다르게 할지가 없으니, 다음 스프린트가 되면 흐지부지됩니다.
그래서 저희는 Try 항목을 적을 때 반드시 "이번 스프린트 안에 담당자와 완료 조건을 붙여서 티켓으로 만든다"는 규칙을 세웠어요.
"코드 리뷰를 더 꼼꼼히 하자" 대신 "PR에 테스트 코드 없으면 리뷰어가 반려한다, 이번 스프린트부터 적용, 담당: 개발 리드"처럼 구체적으로 바꾸는 식입니다.
이렇게 바꾸고 나서부터는 다음 회고에서 "이거 진짜 됐나요?"를 확인할 수 있는 항목이 됐고, 실행률이 눈에 띄게 올라갔습니다.

 

Keep / Problem / Try는 기본적으로 좋은 틀이지만, 계속 같은 형식만 쓰면 팀원들이 습관적으로 적게 돼요.
저희는 몇 번은 형식을 바꿔서 진행했습니다.
한 번은 "이번 스프린트에서 가장 스트레스를 받았던 순간"을 타임라인으로 그려보는 방식을 써봤는데, 이게 오히려 평소 회고에서 안 나오던 이야기를 끌어냈어요.
한 팀원이 "화요일 오후 배포 직전에 QA 담당자가 자리에 없어서 30분을 그냥 기다렸다"는 걸 타임라인에 적었는데, 이게 계기가 되어 배포 전 QA 담당자 배정을 미리 캘린더에 고정해두는 규칙이 생겼습니다.
포스트잇에 Problem이라고만 썼으면 아마 "커뮤니케이션 이슈"라는 뭉뚱그린 문장으로 끝났을 텐데, 타임라인으로 구체적인 순간을 짚으니 원인이 명확해졌어요.

 

회고를 몇 번 진행하면서 느낀 건, 퍼실리테이터가 누구냐에 따라 회고 품질이 크게 달라진다는 점이었습니다.
PM이 계속 퍼실리테이터를 맡으면, 은근히 팀원들이 PM의 눈치를 보면서 부드러운 이야기만 하게 되는 경향이 있었어요.
저희는 이후로 퍼실리테이터를 팀원들이 돌아가면서 맡는 방식으로 바꿨습니다.
처음엔 다들 어색해했는데, 몇 번 돌고 나니 오히려 각자 다른 관점에서 질문을 던지기 시작했어요.
QA 담당자가 퍼실리테이터를 맡았을 때는 "우리가 버그를 늦게 발견하는 패턴이 있는가"라는, 평소 PM인 제가 잘 안 던지던 질문이 나왔던 게 기억에 남습니다.

 

가장 어려웠던 부분은 사실 이거였어요.
팀원이 "이번 스프린트에 제가 일정을 잘못 잡아서 지연됐어요"라고 솔직하게 말할 수 있는 분위기가 없으면, 회고에서 나오는 이야기는 다 표면적인 것들뿐입니다.
저희 팀에서는 한 번 신입 개발자가 자기 실수를 회고에서 언급했다가, 다른 팀원이 "그건 애초에 일정 산정이 무리였다"고 오히려 감싸주는 순간이 있었어요.
그 이후로 팀 안에서 실수를 말하는 것에 대한 부담이 확실히 줄어드는 걸 느꼈습니다.
저는 이제 회고를 시작할 때 항상 "오늘은 누구를 탓하는 시간이 아니라 시스템을 고치는 시간"이라고 한 문장을 꼭 말하고 시작해요.
별거 아닌 것 같은데, 이 한 문장이 있고 없고의 분위기 차이가 꽤 큽니다.

 

Try 항목을 티켓으로 만드는 것 외에, 저희는 지난 5번의 회고에서 나온 Problem을 한 장의 표로 정리해서 팀 위키 맨 위에 붙여뒀습니다.
같은 Problem이 두 번 이상 나오면 표에 빨간색으로 표시하는 식이었는데, 이 표를 보고 나서야 "아, 우리가 배포 프로세스 얘기를 벌써 세 번째 하고 있구나"라는 걸 시각적으로 확인할 수 있었어요.
숫자와 색으로 반복을 눈에 보이게 만드니, 팀 스스로 "이번엔 진짜 끝내자"는 동기가 더 생기더라고요.

회고는 잘 하면 팀이 스스로 고쳐나가는 가장 강력한 도구가 되지만, 잘못하면 그냥 매번 같은 이야기를 반복하는 의례가 됩니다.

저희 팀도 아직 완벽하게 잘 하고 있다고는 말할 수 없지만, 적어도 Try를 티켓으로 만들고 반복되는 Problem을 눈에 보이게 만든 이후로는 회고 시간이 훨씬 밀도 있어졌다고 느껴요.

다음 목표는 회고에서 나온 데이터를 정량적으로도 좀 더 추적해보는 것입니다.