그동안의 경험과 고민을 통해 나름의 스크럼 스프린트 기반의 팀 활동 프레임워크를 만들어보았다.

현재 소규모로 실행해보고 있고, 팀원들의 만족도도 좋은 편이다.

요약

  • 회의
    • 회의를 시작할 때 목표를 정한다. 목표를 달성하면 회의를 끝낸다.
    • 약간 조급한 듯하게 진행하며, 1분이라도 빨리 끝내도록 한다.
    • 정보전달성 회의라면 회의를 잡지 말고 이메일이나 문서로 공유한다.
  • 스프린트
    • 스프린트 종료 회의
      • 스프린트 기간 동안 한 일들을 다 마쳤는지 확인한다.
      • 스프린트 기간 동안 한 일들에 대해 라이브 데모를 포함해 모두 공유한다.
    • 다음 스프린트 계획 회의
      • 다음 스프린트에서 할 일들을 결정해, 칸반보드의 Sprint TODO로 올려둔다.
      • 다음 스프린트의 기간을 결정한다.
      • 이전 스프린트에서 얻은 경험이 다음 스프린트로 이어지게 한다.
        • 경험상 비효율적인 것들은 없애고, 효율적인 것들은 다음으로 계속 유지한다.
  • 칸반 보드
    • Backlog, Sprint TODO, WIP, Done. 이렇게 4개 컬럼을 둔다.
    • WIP 컬럼에는 limit 값을 지정해둔다.
      • 매 스프린트마다 얻은 경험을 통해, 스프린트 계획 회의에서 limit값을 결정하도록 한다.
      • limit을 약간 작게 잡고, 팀원들이 서로 돕는 것을 장려하도록 한다. (페어 프로그래밍 등)
      • limit 때문에 Sprint TODO에 있는 티켓을 WIP로 옮기지 못한다면?
        • WIP에 있는 일을 하고 있는 동료를 도와줘서 빨리 끝내도록 한다.
          • 도움을 주기 어렵다면? 커피라도 사다 주도록 한다. 그 일이 끝나도록 뭐라도 해야 한다.
          • 영 도와줄 방법이 없다면 임시 긴급 스크럼을 열고 WIP limit을 늘릴지, 특정 업무를 더 잘게 쪼갤지 등의 대책을 세워야 한다.
    • Jira 티켓 하나가 3~4시간 만에 해결할 수 있는 사이즈가 되도록 업무를 잘게 자른다.
  • 데일리 스크럼
    • 자기 일을 방해하는 blocker만 빠르게 이야기하고 빠르게 끝낸다.
    • 누군가 blocker를 이야기한다면, 팀원들이 도와주도록 한다.
      • 그런가보다 하고 넘기지 말고 그날 안에 다른 사람들이 도와줘서 해결하는 것이 이상적이다.

회의

회의록을 작성한다

회의 진행 과정에서 약식으로 회의록을 기록하도록 한다.

  • Slack의 스레드, Confluence Wiki, Notion 문서 정도가 적절하다.
    • 리스트 형태로 각 내용을 요약해 작성하며 진행할 것.

회의 목표를 정하고 시작한다

모든 회의는 시작할 때 회의 목표를 적어놓는다.

  • 회의 진행자(나)는 회의가 시작되면 다음과 같이 말한다.
    • "우리 회의 목표부터 적어놓죠."
    • "우리 회의 목표부터 정합시다."
  • 회의 목표는 1가지만 있어도 되고, 2~3가지여도 된다.
  • 다같이 보고 있는 Slack 스레드나 회의록 제일 윗줄에 적는다.

목표를 달성하면 회의를 빨리 끝낸다

회의는 최대한 목표 달성을 향해 진행하도록 한다.

  • 1번 목표를 달성하면 다음과 같이 한다.
    • 크게 말한다: "1번 목표인 XXX 를 달성한 것 같습니다. 더 이야기할 게 있을까요?"
    • 회의록 상단에 있는 1번 목표에 체크 표시를 한다.
    • 크게 말한다: "1번 목표가 달성됐으니 이제 2번 목표를 위해 이야기합시다."
  • 모든 목표를 달성하면 회의를 끝낸다.
    • "오늘 모든 목표를 달성한 것 같습니다. 더 이야기할 게 있는 분이 없으면 회의 끝내죠."

회의는 가능한 한 1분이라도 빨리 끝내도록 한다.

  • 회의 시간이 1시간으로 캘린더에 잡혀있었다면, 1시간 다 채워서 회의하는 일이 가능한 한 없도록 노력한다.
    • 59분만에 끝낸 회의가 1시간짜리 회의보다 더 낫다.
    • 20분만에 모든 회의목표 달성에 성공했다면 21~23분만에 끝내는 것이 베스트.
    • 이것이 반복되면 회의 참석자들의 회의 만족도가 꽤 높아진다.
    • 잘 못하겠다면 약간 조급한 듯하게 회의를 진행해보는 것도 새로운 경험이 될 수 있다.
  • 회의를 빨리 끝내야겠다는 생각을 하지 않으면, 회의를 미리 끝낼 수 있다는 생각을 잘 안 하게 된다.
    • 1시간짜리 회의가 실제로는 40분만에 끝났는데도, 캘린더 일정상 나머지 20분간 다른 주제를 논의하다 일어나는 경우도 많다.

회의 팁

  • 만약 정보전달성 회의라면 가급적 회의를 하지 말고 이메일이나 문서로 공유한다.
    • 문서를 작성하는 사람 한 명만 시간을 쓰면 된다.
    • (읽는 건 각자 덜 바쁜 시간에 할 거라는 믿음)
  • 정말 사소한 사안인데 논의가 길어진다면 다음과 같이 말한다.
    • "이건 1분 안에 결정합시다." (Time Timer 시계를 1분으로 맞춘다.)

스프린트

  • 이 활동의 기반은 경험주의이다.
    • 경험은 바로 직전의 스프린트에서 얻는다.
    • 스프린트 종료 회의는 철저하게 바로 다음의 스프린트를 더 잘 하기 위해 하는 회의이다.

스프린트 종료/다음 스프린트 계획 회의

스프린트가 끝나는 날에 스프린트 종료 회의를 한다.

  • 스프린트 종료 회의는 할 일들과 목표가 뚜렷한 회의다.
  • 회의록을 만들어서 각 아이템을 하나씩 체크하고 내용을 채워가며 빠르게 진행하도록 한다.

스프린트 종료 회의의 아이템은 다음과 같다.

  1. 스프린트 동안 팀이 한 일들을 5~9줄1로 구체적으로 요약한다.
    • 누구 한 사람이 미리 적어오지 않도록 한다. 모두 모인 자리에서 이야기하며 적어내려간다.
    • 모두 정리했다면 다같이 라이브 데모를 돌려본다.
      • 라이브 데모 할 것이 없다면?
        • 스프린트 동안 작성한 테스트 코드 목록이라도 다같이 돌려보도록 한다.
  2. 스프린트 동안의 바람직한 일들과, 비효율적인 일들에 대해 이야기한다.
    • 바람직한 것은 바로 다음의 스프린트에서도 이어지게 한다.
      • 부정적인 것들이 다음 스프린트에서 발생하지 않도록 대책을 세운다.
    • 감정에 대한 회고도 좋음. 그러나 감정 이야기만 하면 곤란하다.
      • 어떻게 해야 다음 스프린트가 '더' 잘 진행되고 '덜' 불안할지를 고민한다.
  3. 다음 스프린트 계획을 세운다.
    • 스프린트 종료 회의의 최중요 목표는 다음 스프린트가 잘 굴러가게 하는 것이다.
    • 다음 스프린트에서 할 일들을 계획한다.
    • 이번 스프린트에서 마치지 못한 일이 있다면?
      • 다음 스프린트에서 계속 이어서 할 지, 아니면 백로그로 돌려놓을 지 결정한다.
    • 할 일들을 모두 계획했다면 대화하며 Jira 티켓을 만든다.
      • 한 명이 미리 만들어오지 않도록 한다.
      • 회의가 끝난 후에 혼자서 왕창 만들지 않도록 한다.
      • 모두 모인 자리에서 이야기하며 하나씩 만들어내려간다.
    • 만든 티켓은 모두 Kanban 보드의 'Sprint TO DO' 컬럼에 올려둔다.
      • 다음 스프린트에서는 'Sprint TO DO'의 일만 한다.
    • 다음 스프린트의 종료 일시를 정해, 캘린더에 스프린트 종료 시간과 회의실도 잡아두도록 한다.

'스프린트 기간 선택'과 '스프린트 동안 할 일 선택'의 균형점 찾기

스프린트 종료 회의에서 다음 두 가지 중 하나를 선택해 균형점을 찾아야 한다.

  • 선택1. 다음 스프린트에서 할 일들을 정해놓고, 스프린트 기간을 결정한다.
    • 해당 업무들을 모두 합쳐 3일만에 끝낼 수 있을 것 같으면 스프린트 기간을 3일로 정하면 된다.
    • 중요하거나 병목이 되는 큰 일이 있을 때 이렇게 한다.
    • 이렇게 한다면 할 일이 예상보다 일찍 끝났을 경우 스프린트를 조기 종료하고 다음 스프린트를 시작할지, 다른 일을 할 지에 대해 Plan B를 세워둘 것.
  • 선택2. 스프린트 기간을 (보통 1주일) 정해놓고, 할 일들을 결정한다.
    • 스프린트 #1 부터 기간을 정해놓는 건 추천하지 않는다.
      • 스프린트 기간을 팀원들끼리 협상해 결정할 수 있다는 것을 실감하지 못하게 될 수 있다.
    • 스프린트를 여러번 돌리다 보면 이 방법으로 굳어져간다.
      • 팀이 5일간 할 수 있는 일에 대해 학습해가며 추정이 점점 쉬워지기 때문.

스프린트 진행

  • 스프린트 동안에는 스프린트 종료 회의에서 계획한 티켓들만 업무를 진행한다.
  • 스프린트 기간에 대해 유연하게 생각한다.
    • 월~금을 기본으로 생각하지 말고, 필요에 따라 이틀, 사흘을 잡을 수도 있다고 생각한다.
    • 필요하다면 하루짜리 스프린트도 가능하다.

스프린트 #1 의 경우(즉 프로젝트 초반인 경우), 일주일에 2회의 스프린트를 돌려보는 것도 괜찮았다.

  • 스프린트 #1
    • 월요일 점심식사 후 시작, 수요일 오후3시 종료.
    • 수요일 오후 3시에 스프린트 종료 회의 시작.
      • 스프린트 #1에서 한 일들 공유하고, 스프린트 #2 계획 세우기.
    • 팀원들이 스프린트를 맛보고 경험하기 위한 첫 스프린트.
    • 스프린트 종료 회의가 평범한 "한국식 주간업무보고"가 아니라는 것을 깨닫기 위한 것.
  • 스프린트 #2
    • 목요일 오전 10시 시작, 금요일 오후 3시 종료.
    • 이틀간 작업한 결과 공유하고, 스프린트 #3 계획 세우기.
  • 이후 상황에 따라 다음 스프린트를 진행하며 계획

데일리 스크럼

보통 데일리 스크럼은 "진행 중인 일", "할 일"을 동료들에게 보고하는데 이 프레임워크에서는 이 과정을 제외하였다.

데일리 스크럼은 다음 3가지 문제점을 동료들에게 공유하는 시간으로 한다.

  1. 내가 하고 있는 일을 방해하는 blocker.
  2. 불길한 예감.
  3. 내 시간을 빼앗는 비공식적 업무.

공유할 것이 없다면 아무것도 적지 않는 게 아니라, "없음"이라고 적는다.

매일 아침 Slack 스레드에 각자 자신의 문제점을 공유하는 방법도 괜찮다.

blocker를 처리하기

누군가 blocker를 작성했다면?

  • 팀원들이 그 문제를 해결하기 위해 도와주도록 한다.
    • 1명~2명 정도. 스스로 나서서 도와주겠다고 하는 것이 바람직하다.
    • 서로 blocker 해결을 도와주는 것에 팀이 익숙해지게 하는 것도 중요한 목표.
  • 중요한 사안이라면 모든 팀원이 그 사람의 blocker 해결에 집중해도 괜찮다.
    • 상황에 따라 시간 낭비가 아닐 수 있다. 팀워크가 향상된다.

하고 있는 일을 공유하지 않아도 괜찮은가?

데일리 스크럼에서 각 팀원이 현재 하고 있는 일을 팀 모두에게 공유하지 않아도 괜찮은가?

  • 칸반보드와 협업(페어프로그래밍 포함), 빈번한 대화/식사 등을 활용한다.
  • 칸반보드에 모든 진행중인 일이 공유되도록 하고([[/better-work/2023/04-scrum-sprint#kanban-board]]{바로 아래의 칸반보드 섹션} 참고), 각 티켓을 반나절 해결 가능 단위로 쪼개두도록 한다. 그러면 이틀 이상 진행중인 일이 보인다.
    • [[/jargon/burndown-chart]]를 운영하고 있다면 변화를 파악하기가 좀 편하다.
  • 대화를 빈번하게 한다.
    • 10분짜리 대화라도 괜찮으니 2~3일마다 한다.
    • 어떤 어려움이 있는지, 서로 도와줄 수 있는지 물어본다.
  • 가능하다면 프로젝트 룸을 구해 함께 일하도록 한다.
    • 계속 같은 공간에서 일하며 잡담을 자주 나누면 자연스럽게 상황을 공유하게 된다.

칸반 보드

칸반 보드는 다음과 같이 구성한다.

Backlog Sprint #3 TODO WIP (limit 4) DONE
티켓 티켓 진행중 티켓 완료 티켓
티켓 티켓 진행중 티켓  
티켓 티켓 진행중 티켓  
티켓 티켓   취소 티켓
티켓 티켓    
티켓      
티켓      
  • Backlog: 프로젝트 전체에서 할 일들.
  • Sprint #N TODO: 현재 스프린트에서 처리할 티켓들.
    • 다음 스프린트를 계획하는 회의에서 Backlog에 있는 것들을 여기로 옮겨온다.
  • WIP: 현재 작업 진행중인 티켓들.
    • limit 4: WIP 티켓 수를 4로 제한한다는 의미.
      • 매우 중요한 개념.

업무 티켓 하나의 단위는 3~4시간 (반나절) 안에 처리할 수 있는 크기로 한다.

  • WIP의 모든 티켓이 다음날이 되었을 때 DONE으로 이동해 있는 것이 이상적이다.
  • 티켓 하나의 업무량이 예상한것보다 크다면 알아서 추가 티켓을 생성해 작업하도록 한다.

상황에 따라 [[/jargon/burndown-chart]]를 운영하는 방법도 고려할 수 있다.

WIP limit

[[/better-work/2023#wip-limit-conclusion]] 참고.

WIP limit 이 꽉 차서 Sprint TODO에 있는 티켓을 WIP로 옮기지 못하고 있다면?

  • WIP에 있는 일을 하고 있는 동료에게 다가가 도와주겠다고 한다.
    • 같이 협력해 해결해서 막힌 일을 DONE으로 빨리 옮기도록 한다.
    • 도움을 주기 어려운 일이라면?
      • 커피라도 사다준다. 자료를 찾아준다. 잘 아는 사람을 찾아본다.
      • 아무튼 그 일이 끝나도록 뭐라도 하도록 한다.
      • 영 도와줄 방법이 없다면 임시 긴급 스크럼(작전회의)을 열고, WIP limit을 +1 할지, 진행중인 문제의 작업 티켓을 더 잘게 쪼갤지 등의 대책을 세우도록 한다.

WIP limit의 수는 약간 작은 것이 적절하다. 이 문제는 멀티 스레드 프로그래밍과 비슷하다.

  • WIP limit이 너무 크면
    • (예: 팀원이 5명인데 WIP limit이 20 쯤 된다면)
    • 진행중이지만 며칠째 멈춰있는 일들이 많아진다.
  • WIP limit이 너무 작으면
    • (예: 팀원이 5명인데 WIP limit이 2 쯤 된다면)
    • 진행중인 일이 모두 협력했을 때 효율적인 일이면 괜찮은데, 그런 일이 아니라면 팀 업무 효율이 떨어지게 된다.
  • WIP limit이 적절하면
    • (예: 팀원이 5명인데 WIP limit이 7 쯤 된다면)
    • 각자 진행중인 일이 1가지씩 있고, 그 1가지가 좀 기다려야 하는 상황이 됐을 때 새로운 일을 시작하기보다는 동료의 일을 도와주러 가는 선택도 할 수 있게 된다.

주석

  1. 팀의 규모와 상황에 따라 달라질 수 있다. '5~9줄'과 같이 구체적으로 언급한 것은 너무 상세한 작성을 막기 위함이다. 너무 길어지면 '주간업무보고 회의'가 된다. ↩