스탠드업 미팅: 15분이 아깝지 않게 진행하는 법

아홉 명이 한 통화에 들어와 있습니다. 네 번째 사람이 "어제는 그제 말씀드린 걸 대체로 이어서 했습니다"라고 말하고, 화면 어딘가에서 카메라 하나가 꺼집니다. 지금은 9:47입니다. 이 회의는 9:30에 시작했습니다.

스탠드업 미팅은 15분을 쓰고 그날의 계획을 내놓아야 합니다. 그런데 실제로는 25분을 쓰고, 통화에서 가장 직급이 높은 사람에게 올리는 상태 보고를 내놓는 경우가 아주 많습니다. 이름만 남고 실체는 다른 회의가 된 겁니다.

해법은 규율이 아닙니다. 그 회의가 무엇을 묻느냐가 해법입니다. 그리고 대부분의 팀은 이 포맷을 만든 사람들이 몇 년 전에 이미 권장을 그만둔 세 가지 질문을 여전히 묻고 있습니다.

스탠드업 미팅이란 정확히 무엇인가

스탠드업 미팅은 하나의 목표를 공유하는 팀이 매일 하는 짧은 싱크입니다. 모두가 같은 작업을 보고, 무엇이 막혔는지 말하고, 그날의 계획을 조정합니다. 진척 보고가 아니고, 의사결정을 내리는 자리도 아닙니다. 다만 결정이 필요하다는 사실을 발견하는 자리인 경우는 많습니다.

이 관행에는 부모가 둘 있습니다. Ken Schwaber와 Jeff Sutherland는 1995년 OOPSLA 콘퍼런스에서 Scrum을 처음 함께 발표했고, 이 프레임워크에는 매일 열리는 이벤트가 들어 있습니다. "scrum"이라는 단어 자체는 다케우치 히로타카와 노나카 이쿠지로가 1986년 하버드 비즈니스 리뷰에 쓴 글에서 왔고, 팀이 함께 공을 밀고 나가는 럭비의 이미지를 빌려온 것입니다. 매일 하는 스탠드업은 1990년대 말 익스트림 프로그래밍의 실천 목록에도 등장합니다. 오늘날 대부분의 사람은 두 이름을 같은 것을 가리키는 데 씁니다.

서서 하는 것은 원칙이 아니라 요령이었습니다. 선 채로 하는 회의는 불편해지고, 그 불편함이 길이에 상한을 씌웁니다. 스크럼 가이드의 어떤 버전도 이를 요구한 적이 없으며, 이를 고집하면 편하게 서 있기 어려운 사람을 배제하게 됩니다.

경계를 하나 그어 둡니다. 이것은 팀의 매일 싱크입니다. 관리자가 팀과 우선순위를 하나씩 훑는 정기 회의가 아닙니다. 그것은 다른 종류의 동물이고 효과적인 팀 회의를 운영하는 법에서 다뤘습니다. 그리고 회사 전체가 모이는 올핸즈 미팅은 더더욱 아닙니다. 스탠드업의 내용이 둘 중 하나로 이사하기 시작했다면, 상류 어딘가가 고장 난 것입니다.

지금의 스크럼 가이드가 말하는 것, 그리고 말하기를 그만둔 것

대부분의 팀은 자기들이 생각하는 내용을 더 이상 담고 있지 않은 문서에서 나온 포맷을 돌리고 있습니다.

현행 버전인 2020년 스크럼 가이드는 데일리 스크럼을 "스크럼 팀 개발자들을 위한 15분짜리 이벤트"로 설명하고, 스프린트 기간 중 매 근무일 같은 시간, 같은 장소에서 연다고 말합니다. 목적은 스프린트 목표를 향한 진척을 점검하고 스프린트 백로그를 조정하는 것입니다. 프로덕트 오너와 스크럼 마스터는 자신이 그 백로그의 항목을 직접 작업하고 있을 때만 참여합니다.

그리고 거의 아무도 읽지 않은 문장이 이어집니다. 회의가 스프린트 목표를 향한 진척에 집중하고 다음 근무일에 실행 가능한 계획을 만들어 내기만 한다면, 개발자들은 원하는 구조와 기법을 무엇이든 고를 수 있습니다.

즉, 그 유명한 세 가지 질문은 사라졌습니다. 이전 판은 그것을 규정했지만, 2020년 개정판은 다른 지시적 표현 상당수와 함께 그 규정을 걷어냈습니다. 현행 Scrum에는 어제 무엇을 했는지 말하라고 요구하는 대목이 하나도 없습니다. 가이드는 또한 지나가듯, 팀이 다시 계획을 세울 수 있는 시점이 이때뿐인 것은 아니라고 적어 두었습니다.

세 가지 질문이 형편없이 낡은 이유

어제 무엇을 했는가. 오늘 무엇을 할 것인가. 무엇이 나를 막고 있는가. 이런 걸 한 번도 해본 적 없는 팀의 보조 바퀴로는 나쁘지 않습니다. 하지만 영구적인 구조로 삼으면 예측 가능한 네 가지 방식으로 실패합니다.

이 질문들은 일이 아니라 사람을 향합니다. 아홉 명 곱하기 세 개의 답이면 스물일곱 개의 작은 독백이 되고, 그중 한 사람의 청자에게 실제로 필요한 것은 네 개쯤입니다. 목표는 한 번도 등장하지 않습니다. 어떤 질문도 목표를 묻지 않기 때문입니다.

"어제"는 감사(監査)의 질문입니다. 동료들 앞에서 전날을 해명하라고 하면 돌아오는 것은 변론이고, 알찬 하루처럼 들리도록 부풀려집니다. 그 질문이 초대하는 것이 바로 그것입니다.

보고의 방향이 표류합니다. 시선은 그 자리에서 가장 직급이 높은 사람에게로 향하고, 3주면 동료 간 싱크가 아니라 그 사람을 위한 브리핑이 됩니다.

스프린트의 상태를 가립니다. 모두가 바쁘고, 아무도 막혀 있지 않은데, 목표는 그대로 밀립니다. 이 포맷에는 그것을 보여줄 방법이 없습니다.

딱 한 번만 해보세요: 어제 무엇을 했는지 아무도 말할 수 없는 스탠드업을 진행해 보십시오. 그래도 제 역할을 한다면, 그리고 대개는 하는데, 그 질문은 애초에 가치를 나르고 있지 않았던 겁니다.

더 나은 스탠드업 미팅 질문

대부분의 스탠드업을 고치는 전환은 방을 도는 대신 일을 도는 것입니다. 보드를 열고 항목 하나씩, 오른쪽에서 왼쪽으로 갑니다. 완료에 가장 가까운 것부터 시작하십시오. 시작하는 것보다 끝내는 것이 낫기 때문입니다. 자기 항목이 나올 때 말하게 되고, 아무도 일일 보고를 연기하지 않습니다.

자기 자리를 스스로 벌어들이는 질문은 이렇습니다.

• 이 항목이 움직이려면 오늘 무엇이 일어나야 하는가? 사람이 아니라 항목에게 묻고, 그것을 쥐고 있는 사람이 답합니다.
• 무엇이 위험하고, 언제 알게 되는가? 정직하게 답할 수 있도록 다시 쓴 블로커 질문입니다. "위험하다"고 인정하는 데는 비용이 들지 않습니다. "막혔다"는 자백처럼 들립니다.
• 어제 이후 바뀐 것 중 다른 사람이 알아야 할 것은 무엇인가? 세 사람만 들은 옆길 결정을 잡아냅니다.
• 이 회의가 끝나고 누가 누구의 10분을 필요로 하는가? 회의에서 수익률이 가장 높은 질문이자, 나머지 14분을 깨끗하게 지켜 주는 질문입니다.
• 우리는 여전히 목표에 도달하는가? 일주일에 두세 번, 소리 내어. 답하지 못하는 팀에는 공유된 목표가 없습니다. 스탠드업 옷을 입은 계획 문제입니다.

15분은 어디로 가는가

타임박스는 인원 수에 따라 늘어나지 않습니다. 네 명이든 열 명이든 15분은 15분입니다. 열 명짜리 팀으로 계산해 보면 한 사람당 90초가 나오는데, 이는 돌아가며 말하기가 잘못된 형태라는 가장 분명한 신호입니다.

스탠드업은 세 가지 방식으로 부풉니다. 누군가 그 자리에서 문제를 풀기 시작합니다. 누군가 자리에 없는 이해관계자에게 브리핑을 합니다. 그리고 사람들은 노력을 증명하려고 서술합니다. 이것은 게으름이 아니라 그 회의가 지금까지 어떻게 쓰였는지를 보여주는 증상입니다.

세 가지 모두에 대한 해법은 같습니다. 이름을 붙이고, 주인을 정하고, 시간을 박아 넣는 것. "그건 설계 문제네요. Rosa와 Tunde, 이거 끝나고 바로, 15분." 약속이 된 것은 제대로 된 작업의 형태로 회의를 떠나야 하고, 그 문장을 쓰는 방법은 실제로 완료되는 액션 아이템 쓰는 법에 정리해 두었습니다.

시간 초과가 거의 매일 일어난다면, 그것을 규율 실패라고 부르는 것을 그만두십시오. 초과된 그 부분이 바로 당신의 팀에 필요한 회의입니다. 그리고 제대로 된 회의 안건 템플릿을 뒤에 둔 주간 워킹 세션이, 매일 아침 10분씩 덧붙이는 것보다 그 일을 훨씬 잘합니다.

그대로 복사해 쓰는 일일 스탠드업 템플릿

보드 하나, 타이머 하나, 여섯 단계. 이 포맷은 의도적으로 항목이 먼저입니다. 누군가 다른 사람에게 무언가를 필요로 할 때만 이름이 등장합니다.

템플릿 — 15분 일일 스탠드업

[팀] 스탠드업 — [날짜] · 15분 · 타이머: [누구]

우리가 향하는 목표: [한 줄 — 바뀌었을 때만 소리 내어 읽기]

보드를 오른쪽에서 왼쪽으로 훑기

[항목] — [상태] — [움직이려면 오늘 무엇이 일어나야 하는지] — [쥐고 있는 사람]

착지하지 못할 위험

[항목] — [이유] — [언제 알게 되는지]

어제 이후 바뀐 것

[다른 사람이 알아야 할 것 — 결정, 장애, 새 정보]

오늘 누군가가 필요한 것

[이름]이(가) [이름]에게서 [무엇]이 필요함 — [언제 만나는지]

보류

[주제] → [주인] → [언제 진행하는지]

작성 예시 — 15분 스탠드업

PAYMENTS 스쿼드 스탠드업 — 9월 1일(화) · 15분 · 타이머: Meg

목표: 12일 전까지 환불이 새 원장을 통과하게 한다.

보드를 오른쪽에서 왼쪽으로 훑기

환불 취소 — 리뷰 중 — 점심 전까지 Nils가 봐야 함 — Rosa

정산 작업 — 진행 중 — 오늘 9월 데이터로 실행 중 — Tunde

부분 환불 — 미착수 — 취소 건이 나갈 때까지 아무도 잡지 않음

착지하지 못할 위험

정산 작업 — 9월 익스포트에 이틀치 데이터가 빠져 있음 — Tunde가 14:00까지 확인

어제 이후 바뀐 것

재무가 마감을 10일로 앞당겼습니다. 보드에 적힌 날짜보다 이틀 빠릅니다.

오늘 누군가가 필요한 것

Rosa는 Nils의 리뷰가 필요 — 점심 전 · Tunde는 데이터 엔지니어링에서 빠진 익스포트가 필요 — Meg가 10:00에 재촉

보류

부분 환불을 이번 배치에 넣을지 말지 → Meg → 이 회의 끝나고 20분, Tunde와 함께

잘 굴러가면 여기까지 대략 7분입니다. 나머지 8분은 대화가 필요했던 항목을 아무도 서둘러 넘기지 않게 해주는 여유분입니다.

비동기 스탠드업, 그리고 그것이 그냥 상태 연극일 때

비동기 스탠드업은 마감 시각까지 채널에 올리는 글로 회의를 대체합니다. 제대로 하면 많은 팀에게 실시간 버전보다 낫습니다. 엉성하게 하면 아무도 읽지 않는 의식이 되고, 대체한 회의보다 더 나쁩니다. 적어도 회의에서는 사람들이 듣기 때문입니다.

비동기가 이기는 경우는 이렇습니다. 팀이 몇 시간을 넘는 시간대에 걸쳐 있어 어떤 실시간 시간대를 잡아도 누군가는 손해를 볼 때, 작업이 느슨하게 결합되어 있을 때, 그리고 팀의 가치가 끊기지 않는 긴 시간에서 나와 고정된 9:30이 협업으로 위장한 방해일 때입니다.

실시간을 유지해야 하는 경우는 이렇습니다. 사람들이 같은 파일을 만지고 있어 충돌 한 번에 반나절이 날아갈 때, 팀이 새로 만들어졌을 때, 또는 올라온 글이 조용히 읽히지 않게 되었을 때. 마지막 경우는 누가 답글을 달기는 하는지 확인하면 1분 만에 알 수 있습니다.

실시간이면서 분산 상태를 유지하면 시간 잡기가 보기보다 훨씬 어렵습니다. 매일 하는 회의는 월간 회의처럼 돌려 가며 시간을 바꿀 수 없기 때문입니다. 불친절한 시간대는 같은 사람에게 1년 내내 매일 불친절합니다. 본사 아침이 시작되는 시각이 아니라 진짜로 겹치는 시간대 안에 넣으십시오. 겹치는 시간이 대략 세 시간 아래로 내려가면, 비동기는 게으른 답이 아니라 정직한 답입니다.

비동기를 작동하게 만드는 규칙: 다른 사람의 이름을 언급한 글은 상태 한 줄이 아니라 요청이며, 요청은 같은 근무일 안에 답을 받습니다. 이것이 없으면 손에 남는 것은 업데이트의 벽뿐이고 협업은 없습니다.

템플릿 — 비동기 스탠드업 글

#[팀]-standup — [날짜] · [시각, 당신의 현지 시간]까지 게시

네 줄. 자세한 내용은 스레드로.

진행 중

[오늘 끝낼 단 하나. 목록이 아님.]

위험

[착지하지 못할 수도 있는 것, 그리고 언제 알게 되는지]

요청

[@이름 — 무엇이 언제까지 필요한지 — 없으면 "없음"]

공지

[듣지 못하면 팀이 짜증날 한 가지]

작성 예시 — 비동기 글

#payments-standup — 9월 1일(화) · Tunde, 09:10 WAT

진행 중

정산 작업을 9월 데이터로 돌리는 중 — 퇴근 전까지 결과를 내는 게 목표입니다.

위험

익스포트에 이틀치가 빠져 있습니다. 14:00 UTC까지 고쳐지지 않으면 목요일로 밀립니다.

요청

@meg — 데이터 엔지니어링에 3일과 4일치를 재촉해 주실 수 있나요? 14:00 UTC까지 필요합니다.

공지

재무가 마감을 10일로 앞당겼습니다. 보드에는 아직 12일로 적혀 있습니다.

도구 이야기를 솔직하게 하자면, 15분짜리 스탠드업에 전사본은 필요 없고, 그걸 파는 사람은 당신에게 없는 문제를 풀고 있는 겁니다. 예외는 좁습니다. "스탠드업"이 사실상 녹화 영상이고 절반은 나중에 보는 분산 팀, 그리고 아무도 기록하지 않은 채 매번 의사결정 회의로 변해 버리는 스탠드업입니다. 그 두 경우라면 통화를 녹음하고 요약하는 AI 미팅 어시스턴트가 값을 합니다. Laxis는 Zoom, Google Meet, Teams를 지원하고, 액션 아이템과 담당자를 뽑아내며, 100개 이상의 언어를 처리합니다. 평범한 7분짜리 싱크라면 보드와 타이머가 어떤 소프트웨어보다 낫습니다.

스탠드업이 죽는 네 가지 방식

아무도 가치를 못 느끼는 스탠드업을 없애거나 고치는 법

스탠드업 자리에서 투표에 부치지 마십시오. 한 사람씩 따로 물어보십시오. 여럿이 모인 자리에서는 그 회의를 잡은 사람 앞에서 시간 낭비라고 말하고 싶은 사람이 없기 때문입니다.

그다음에 실험을 하십시오. 2주 동안 취소하고 아무것도 대체하지 마십시오. 다른 회의가 아니라, 정말 아무것도 없이. 그리고 무엇이 깨질 것으로 예상하는지를 먼저 적어 두십시오. 대부분의 팀은 두 사람이 같은 작업에서 충돌하거나 같은 결정이 두 번 내려지기까지 나흘 정도 버팁니다. 그 충돌이 바로 그 회의가 제공하고 있던 가치이고, 이제 그 크기를 알게 된 겁니다.

아무것도 깨지지 않는다면, 그 팀은 애초에 일을 공유하고 있지 않았던 것입니다. 스탠드업은 매일의 조율이 필요 없는 평행 트랙을 보상하고 있었던 것이고, 정직한 해법은 의식을 계속 살려 두는 것이 아니라 일을 나누는 방식을 바꾸는 것입니다.

없애는 데까지 가지 않겠다면 빈도를 절반으로 줄이십시오. Scrum 밖에서는 주 3회 아침이 충분히 정당합니다. Scrum 안에서는 프레임워크를 벗어났다는 뜻인데, 흘러 들어간 게 아니라 스스로 결정한 것이라면 그것도 괜찮습니다. 그리고 살아남은 것이 싱크가 아니라 의사결정 회의라면, 그에 맞게 대하십시오. 안건, 퍼실리테이터, 기록. 기억하는 일이야말로 스탠드업이 가장 못하는 일입니다.

정말로 기록이 필요한 회의라면

Laxis는 Zoom, Google Meet, Teams에서 중요한 통화에 참여해 요약을 쓰고, 모든 액션 아이템을 담당자와 함께 목록으로 정리합니다. 무료 플랜에는 매월 300분의 전사가 포함됩니다.

Laxis 무료로 사용해 보기

그래서 무엇을 하면 되는가

스탠드업은 가치를 검증하기 쉬운 몇 안 되는 회의인데도 거의 아무도 검증하지 않습니다. 취소하고 무엇이 무너지는지 보십시오. 질문 하나를 바꾸고 사람들의 말이 얼마나 달라지는지 들어 보십시오. 30분 뒤로 옮기고 그 아침이 지킬 만한 것이었는지 확인해 보십시오.

규칙을 쓴 사람들은 그 15분을 어떻게 쓰라고 알려 주는 일을 조용히 그만두었습니다. 그것은 실수가 아니라 초대입니다.

자주 묻는 질문

스탠드업 미팅이란 무엇인가요?

스탠드업 미팅은 보통 15분짜리의 짧은 매일 싱크로, 공유된 목표를 향해 일하는 팀이 함께 진척을 확인하고 그날의 계획을 조정하는 자리입니다. 무엇이 막혀 있고 누가 누구를 필요로 하는지를 드러내기 위해 존재하며, 위로 상태를 보고하기 위한 자리가 아닙니다. Scrum에서 이에 해당하는 이벤트의 이름은 데일리 스크럼입니다.

일일 스탠드업은 얼마나 길어야 하나요?

15분이고, 이 숫자는 인원 수에 따라 늘지 않습니다. 2020년 스크럼 가이드는 팀 규모와 무관하게 데일리 스크럼을 15분으로 못박고 있으며, 바로 그래서 한 사람씩 돌아가며 말하는 방식은 여섯이나 일곱 명을 넘기면 작동을 멈춥니다. 늘 30분이 필요하다면, 그것은 스탠드업 안에서 워킹 세션을 하고 있는 것입니다.

스탠드업 미팅의 세 가지 질문은 무엇인가요?

어제 무엇을 했는가, 오늘 무엇을 할 것인가, 무엇이 나를 막고 있는가입니다. 이전 판 스크럼 가이드는 이를 규정했지만, 2020년 개정판은 그 규정을 완전히 삭제했습니다. 팀이 계속 써도 되고, 새로 만들어진 많은 팀은 이를 유용한 보조 바퀴로 여기지만, 지금의 Scrum에는 이를 요구하는 대목이 없습니다.

스탠드업 미팅에서는 꼭 서 있어야 하나요?

아닙니다. 서 있는 것은 회의를 짧게 유지할 만큼 불편하게 만들려는 요령이었을 뿐이고, 스크럼 가이드는 한 번도 이를 요구한 적이 없습니다. 이를 고집하면 편하게 서 있기 어려운 사람을 배제하게 되고, 원격 팀에는 아무 효과도 없습니다. 대신 모두에게 보이는 타이머를 쓰십시오. 연출 없이 같은 일을 해냅니다.

관리자가 일일 스탠드업에 참석해야 하나요?

보드에 자기 작업이 있을 때만입니다. 스크럼 가이드는 데일리 스크럼을 개발자를 위한 이벤트로 규정하고 있고, 관리자가 관객으로 참석하는 순간 그 회의는 조용히 그 사람을 향한 상태 보고가 됩니다. 관리자로서 가시성이 필요하다면 보드를 읽거나 주간 요약을 요청하십시오.

비동기 스탠드업이 실시간보다 나은가요?

비동기 스탠드업은 팀이 몇 시간을 넘는 시간대에 걸쳐 있을 때, 작업이 느슨하게 결합되어 있을 때, 또는 즉시성보다 집중 시간을 지키는 것이 더 중요할 때 이깁니다. 실시간은 사람들이 같은 파일에서 일할 때, 팀이 새로 만들어졌을 때, 또는 글로 올린 업데이트를 아무도 읽지 않게 되었을 때 이깁니다.