지금까지 겪은 최악의 회고들은 모두 같은 모양이었습니다. 스프린트 골을 놓쳤고, 그래서 한 시간 내내 “왜 못 했나” 청문회가 열리는 식이죠. 반대로 가장 좋았던 회고에서는 골 얘기가 거의 나오지 않았습니다. 우리가 어떻게 일했는지, 뭐가 발목을 잡았는지, 다음엔 뭘 바꿔볼지를 이야기했습니다. 이 차이가 바로 “결과에 얽매이지 않는 마인드셋"이라는 것이고, 직접 스프린트를 꽤 돌려본 지금은 이게 스크럼 마스터에게 가장 중요한 태도라고 생각합니다.

분명히 해두자면, 결과는 당연히 중요합니다. 프로세스만 그럴듯하고 아무것도 출시 못 하는 팀에 월급을 주는 회사는 없죠. 다만 스프린트를 완수하는 건 팀의 일입니다. 스크럼 마스터의 일은 스프린트를 만들어내는 기계 자체를 개선하는 것이고요. 이 둘은 다른 일인데, 여기가 섞이는 순간부터 제가 본 스크럼의 부작용 대부분이 시작됐습니다.

스크럼 마스터 vs 프로젝트 매니저

#

두 역할은 자주 헷갈립니다. 한 사람에게 둘 다 맡기는 회사가 많은 것도 한몫하죠. 핵심 차이는 이렇습니다.

스크럼에는 애초에 프로젝트 매니저라는 역할이 없습니다. 프로젝트 매니저가 보통 하던 일의 상당 부분은, 무엇을 어떤 순서로 만들지 정하는 제품 책임자와 그걸 어떻게 만들지 계획하는 개발자들에게 나뉘어 있습니다.

결과에 대한 집착을 내려놓으면 달라지는 것들

#

우선 팀이 진짜로 주인의식을 가질 공간이 생깁니다. 스크럼은 자기조직화 팀이 전제인데, 결과 하나하나에 조바심 내는 스크럼 마스터는 어느새 의사결정에 손을 넣고 있습니다. 그러면 팀은 “결정은 우리 몫이 아니구나"를 금방 학습하죠. 프로세스에 무게를 두면 팀원들이 실험하고, 가끔 틀린 판단도 해보고, 거기서 배우게 둘 수 있습니다. 주인의식은 그렇게밖에 안 자랍니다.

회고도 솔직해집니다. 회의실의 질문이 “왜 숫자를 못 맞췄나"면 진짜 답은 숨어 버립니다. “뭐가 우릴 느리게 했고, 다음엔 뭘 시도할까"면 다들 입을 엽니다. 스프린트 중간에 터지는 장애물도 마찬가지입니다. 결과에 집착하는 스크럼 마스터는 마감 걱정에 허둥대지만, 프로세스에 집중하는 사람은 그냥 묵묵히 블로커를 치우러 갑니다. 아직 아무도 잘 모르는 게 걸림돌이라면 타임박스를 정한 스파이크를 제안하고요.

이해관계자와의 관계도 한결 차분해집니다. 들려줄 이야기가 번다운 차트뿐이면 작은 흔들림도 전부 실패처럼 보입니다. 팀이 뭘 배웠고 어떻게 적응해 왔는지도 이야기할 수 있으면 기대치가 훨씬 현실적으로 잡히고, 스프린트 중간에 팀한테 떨어질 압박도 상당 부분 밖에서 막아줄 수 있게 됩니다.

이미 어떤 결과에 집착하고 있다면

#

말이야 쉽죠. 특정 결과에 깊이 몰입해 있을 때 “프로세스에 집중하세요"라는 말은 액자 속 명언처럼 들립니다.

실제로 도움이 됐던 것 몇 가지만 적어 봅니다. 첫째, 결과를 신경 쓰는 자신을 탓하지 않기. 뭔가를 바라는 건 자연스러운 일이고, 아닌 척해봐야 오래 못 갑니다. 둘째, 결과 목표를 내가 통제할 수 있는 프로세스 목표로 번역하기. “대회에서 우승한다"가 아니라 “매일 30분 연습한다"로요. 릴리스가 잘 먹힐지는 통제할 수 없지만, 리뷰와 테스트를 거치고 일찍 데모했는지는 통제할 수 있습니다. 셋째, 집착에 연료를 대는 게 뭔지 알아차리기. 대시보드나 주가를 하루에 열 번씩 새로고침하고 있다면, 확인할 시간을 정해두고 그 외엔 안 보는 겁니다. 그리고 중간의 작은 성과도 꼭 챙겨서 축하하세요. 내버려 두면 저 멀리 있는 목표가 주의력을 전부 잡아먹습니다. 만약 집착 때문에 잠을 설치고 일상이 흔들릴 정도라면 전문가와 상담해 볼 가치가 있습니다. 전혀 부끄러운 일이 아닙니다.

결과는 여전히 중요합니다. 다만 결과를 꾸준히 내는 팀에는, “무엇을"만이 아니라 “어떻게"를 챙기는 사람이 반드시 있었습니다.

회의 자체는 쉽습니다

#

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

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

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

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

#

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

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

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

자주 보이는 실패 패턴

#

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

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