스크럼 오브 스크럼

팀이 셋을 넘어가면 각 팀은 제대로 도는데 팀 사이에서 막히는 상태가 생깁니다. 결제 팀이 인증 쪽 답을 2주 기다리고 있는데, 인증 팀의 목록에서 그 요청은 열두 번째에 놓여 있습니다. 양쪽 모두 자기 기준으로는 잘 일하고 있습니다.

기다린다는 말은 매일 나옵니다. 각 팀의 데일리 스크럼에서 그 말이 나오는데, 그 회의에는 인증 팀 사람이 없습니다. 팀 안에서 반복되는 말이 팀 밖으로 나가는 통로가 없어서, 2주 동안 같은 문장이 스무 번 발화되고도 상대 팀은 그 요청의 급함을 모릅니다.

관리자가 중간에서 전달하는 방식으로 메워 보기도 했습니다. 두 가지가 걸렸습니다. 전달하는 사람이 기술 맥락을 다 알 수 없어서 요청이 조금씩 달라지고, 그 사람이 휴가를 가면 통로가 닫힙니다.

그래서 팀 대표끼리 같은 자리에 앉게 만드는 회의 하나를 얹게 됐습니다. 새로 만드는 것이 회의 하나뿐이라 여러 팀을 다루는 체계 가운데 가장 가볍고, 팀이 서넛일 때 제일 먼저 시도합니다. 결제 팀 대표가 기다린다고 말할 때 인증 팀 대표가 그 자리에 앉아 있다는 것이 이 회의가 하는 일의 전부입니다.

15분을 지키는 것이 이 회의의 첫 규칙입니다. 순서는 여섯 단계입니다.

1. 주 2회에서 3회 엽니다. 매일 열면 팀 안의 회의를 한 번 더 하는 셈이 되고, 주 1회로 줄이면 기다림이 드러나는 데 최대 5일이 걸립니다.
2. 팀마다 한 명씩 앉습니다. 여섯 팀이면 여섯 명이고, 참관하러 온 사람은 말하지 않습니다.
3. 세 가지를 팀 단위로 답합니다. 지난 회의 이후 우리 팀이 끝낸 것, 다음 회의까지 할 것, 다른 팀 때문에 막힌 것입니다. 팀 안에서 개인이 답하던 세 가지를 팀 단위로 옮겨 놓은 모양입니다.
4. 세 번째 질문에 시간을 몰아 줍니다. 앞의 두 가지는 맥락을 맞추는 정도이고, 이 회의가 존재하는 이유는 세 번째 하나입니다. 진행하는 사람은 앞의 둘이 길어지면 끊습니다.
5. 막힌 항목마다 담당과 기한을 그 자리에서 붙입니다. 무엇이 왜 막혔는지를 여기서 논의하지 않고, 두 팀 대표가 회의 뒤에 따로 만나기로 정합니다. 15분이 유지되는지는 이 규칙에 달려 있습니다.
6. 다음 회의는 지난 목록을 확인하는 것으로 시작합니다. 이 단계가 없으면 같은 기다림이 매번 새로 보고되고, 그 상태가 몇 주 이어지면 참석자들이 말해도 안 된다고 배웁니다.

하지 않는 것도 정해 둡니다. 상태를 보고하는 자리가 아니고, 무엇을 먼저 할지 정하는 자리도 아닙니다. 우선순위는 각 팀의 프로덕트 오너가 정하고, 이 회의는 그 우선순위 때문에 누가 기다리게 됐는지를 드러내는 데까지만 합니다. 기술 설계를 논의하기 시작하면 15분은 지켜지지 않습니다.

누가 나오는지가 이 회의의 성패를 가릅니다. 규정상으로는 각 팀의 스크럼 마스터지만, 실제로 필요한 사람은 다른 팀에 무엇이 필요한지 아는 사람입니다. 그래서 개발자가 나오는 팀이 많습니다. 기술 맥락을 모르는 사람이 앉으면 막힌 항목이 그 자리에서 정리되지 않고 확인해 보겠다는 말로 끝납니다.

매번 다른 사람이 나오는 것도 문제입니다. 지난 목록의 맥락을 아는 사람이 없어지기 때문에, 팀마다 한 사람을 정해 두고 그 사람이 못 오는 날에만 대리가 갑니다.

팀 수는 셋에서 여덟 사이가 맞습니다. 아홉을 넘으면 한 사람이 30초씩 말해도 15분이 차고, 서로 관계없는 팀끼리 앉아 있는 시간이 길어집니다. 그때는 관련 있는 팀끼리 둘로 나누거나 더 무거운 체계로 넘어갑니다.

시작하는 시점은 팀이 셋이 되고 같은 기다림이 두 번 반복될 때입니다. 팀이 둘이면 이 회의가 필요 없습니다. 두 대표가 직접 말하면 되는 일에 회의를 만드는 셈입니다.

그만두는 시점도 정해 두는 편이 낫습니다. 3주 연속 막힌 항목이 없으면 주기를 주 1회로 줄이거나 없앱니다. 팀 사이 의존이 실제로 줄어든 결과일 수 있는데, 회의를 유지하면 그 성과가 보고할 것 없는 15분으로 남습니다.

다음 단계로 넘어갈 신호도 이 자리에서 나옵니다. 매주 같은 합치기 문제가 올라오면 통합을 관리하는 체계가 필요하고, 팀마다 출시일이 어긋나 서로를 기다리면 릴리스 트레인으로 날짜를 묶을 때입니다.

"그건 회의 끝나고 두 팀이 따로 보시죠. 목록에는 올려 두겠습니다."

15분을 지키면서 기다림은 기록하는 진행입니다.

"지난주에 올린 항목 세 개부터 확인하겠습니다."

목록 확인으로 시작하는 순서입니다.

"3주째 막힌 게 없습니다. 주 1회로 줄이죠."

회의를 줄이는 근거를 대는 말입니다.

페이지덱이 팀을 셋으로 나눈 뒤 이 회의를 시작했습니다. 문서 팀과 결제 팀과 인증 팀이 각자 2주 주기로 돌았는데, 첫 주기에 넘어간 작업의 절반이 다른 팀을 기다린 것이었습니다.

태오가 주 2회 15분으로 열고 막힌 항목만 목록에 적었습니다. 첫 회의에서 나온 항목이 일곱 개였고, 그 가운데 다섯 개는 상대 팀이 요청이 들어온 줄 몰랐던 것이었습니다. 두 주기 뒤에 팀을 기다려 넘어간 작업이 4분의 1로 줄었습니다.

상위 의사결정 회의로 읽는 경우가 가장 많습니다. 이름에 상위라는 뜻이 담겨 있고 대표들이 모이니 그렇게 보입니다. 하지만 이 자리에는 결정 권한이 없습니다. 각 팀의 우선순위를 바꾸지 못하고, 바꿔야 한다면 그 팀의 프로덕트 오너에게 가져가는 것이 순서입니다. 결정하는 자리로 취급하면 팀 안에서 하던 결정이 위로 올라가고, 그러면 각 팀은 자기 주기를 스스로 계획하지 못하게 됩니다.

팀이 많아지면 자동으로 필요해진다고 보는 것도 흔합니다. 팀 수가 늘면 조율이 필요하니 자연스러운 추측입니다. 하지만 이 회의가 값을 하는 것은 팀 사이에 서로 기다리는 지점이 실제로 있을 때입니다. 팀을 기능별로 잘 나눠 서로 기다릴 일이 적은 조직에서는 회의만 늘고 보고할 것이 없습니다. 먼저 할 일은 회의를 여는 것이 아니라 기다리는 지점 자체를 줄이는 쪽입니다.