회의 자체는 쉽습니다

#

구조는 민망할 만큼 단순합니다. 스프린트나 프로젝트 단계가 끝나면 팀이 모여 세 가지 질문에 답하는 게 전부입니다.

1. 무엇이 잘 되었는가?
2. 무엇이 잘 안 되었는가?
3. 무엇을 개선할 수 있는가?

이게 답니다. 핵심은 피드백 루프에 있습니다. 주기적으로 멈춰 서서 실제로 무슨 일이 있었는지 돌아보고, 일하는 방식에 반영하는 것. 멈추지 않는 팀은 같은 일을 반복할 뿐입니다.

쓸모 있는 회고와 푸념 대회의 차이

#

우선 솔직함입니다. 진짜 문제를 입 밖에 낼 수 있는 건 그게 나에게 불리하게 돌아오지 않는다는 확신이 있을 때뿐입니다. 그래서 자리의 안전함이 어떤 포맷을 골랐는지보다 중요합니다. 그리고 가장 날카로운 관찰은 대개 조용한 팀원에게서 나오죠. 리드만 말하는 회고는 절차만 늘어난 스테이터스 미팅입니다.

나머지 절반은 논의 이후에 벌어지는 일입니다. 고칠 가치가 있는 문제라면 담당자와 기한이 붙은 액션 아이템이 되어 회의실을 나가야 합니다. 그리고 — 대부분의 팀이 건너뛰는 부분인데 — 다음 회고는 지난번 액션 아이템 점검으로 시작하세요. 액션 아이템이 장식품이라는 걸 모두가 조용히 깨닫는 순간만큼 회고를 빨리 죽이는 건 없습니다.

가능하면 숫자도 가져오세요. “이번 스프린트는 느린 느낌이었다” 같은 감상은 겉돌기만 하지만, 차트 한 장이면 대개 결론이 납니다.

자주 보이는 실패 패턴

#

가까이서 본 것만 세 가지입니다. 비난전으로 흐르는 회고(고칠 건 시스템이지 사람이 아닙니다), 일 년 내내 똑같은 포맷을 쓰다가 전원이 자동 조종 모드가 되는 회고(형식에 변화를 주세요), 그리고 팔로업이 아예 없는 회고. 위에서 말했듯 마지막이 치명타입니다.

참고로 이건 소프트웨어에만 해당하는 이야기가 아닙니다. 마케팅 캠페인, 행사 운영, 연구 프로젝트, 제조업까지, 사이클이 반복되는 일이라면 어디든 같은 루프가 통합니다. 다만 어디서 하든 판정 기준은 같습니다. 다음 회고 전까지 실제로 뭔가 바뀌었는가? 안 바뀌었다면, 그냥 수다를 떤 겁니다.