[SCRUM] Interrupt handling while we do sprint : Sprint 진행 중 나오는 interrupt 처리하기

스크럼에서는 planning할 때 붙인 백로그 이외에는 처리하지 않도록 가이드 하고 있다.
하지만 내가 지금 일하고 있는 환경은 제조업으로, 우리의 최종 제품은 하드웨어이다. 즉, SW가 나왔다 해도 그것을 하드웨어에 올리고 제대로 동작하는지를 확인하는 과정이 아직 남아있다. 또, 이미 출시한 제품의 수가 꽤 많으며, 그것에서 나오는 필드 이슈의 우선순위가 가장 높게 들어온다. 때문에 2주동안 처리를 안하고 계획했던 일들만 하고있을 수 없는 환경이다.

이런 환경에서 보통 내가 가이드하는 방법은 Scrum과 Kanban을 섞어서 쓰는 것이다.
새로운 기능/제품을 개발하는 일은 스크럼으로, 이미 출시한 제품에서 나온 이슈들은 Kanban으로 관리한다. 커다란 오프라인 보드를 하나 만들어서 두 부분으로 나누어서 쓰면 보기에도 편리하고, 할 일을 붙이고 옮기기도 매우 쉽다.

그래서 난 오프라인 스크럼 보드를 선호하며, jira를 쓰는 팀에 들어가도 오프라인 보드를 하나 더 만들어서 데일리 미팅은 오프라인 보드로 진행한다. jira의 획일적인 프로세스는 팀 별로 커스터마이징하기 번거로울 뿐더러 채워야 할 칸도 많기 때문에 오히려 업무를 방해하기도 한다.
그저 벽에 폼 보드 하나를 붙이고, To do, Doing, Done 세 칸으로 나누어 라인테잎으로 선을 그으면 우리의 스크럼 보드 완성이다.
포스트잇은 planned는 노랑색, 이외에는 모두 빨간색으로 붙인다.
빨간색의 의미는 미처 계획하지 못한 일임과 동시에 인터럽트 업무이다. 때문에 sprint가 돌면서 점점 줄어든다.
빨간색이 많이 붙을수록 그것들을 빨리 줄이고 싶어할 것이다. 특히 조직 책임자가 말이다.

입터럽트성 업무 관리하기
Sprint 진행 중에 빨간 포스트잇이 많이 붙는다는건, 치고 들어오는 일이 많다는건데 이걸 관리하기 위한 한가지 방법으로 다음 Sprint 진행할 때는 Planned용 포스트잇에 interrupt 업무 시간을 추정해서 빈 포스트잇을 붙여놓는 방법을 사용할 수 있음.
대신 이 방법을 쓰려면 이전 Sprint 중에 진행된 빨간 포스트잇들을 구분해서 정말정말로 예측할 수 없었으나 우선순위가 높았던 인터럽트성 업무를 구분해내야 함.
따라서 스크럼 미팅에 언급되지 않은채로 시작됐다가 끝나버린 일들에 대한 추정도 필요하다. (이것들만 모아서 분석해보기)
사람들은 인터럽트성 업무가 발생하면, 이전에 계획된 업무의 우선순위가 더 높아도 빨리 처리할 수 있는 일을 먼저 처리하려는 습성(?)이 있기 때문에 빨간 포스트잇의 업무가 발생하면 개발자 스스로 우선순위 관리를 할 수 있도록 해야 한다.
빨간 포스트잇에 적히는 업무들은 Burndown chart에 따로 표해서 우리팀에 얼마만큼의 시간이 빨간 포스트잇에 소요되고 있는지를 가시화 (즉, 꺾은 선이 두개가 되는 것)

시간 추정하기
Planning poker 사용하여 시간 추정하기

타부서와 연관되어 holding 되는 이슈 관리 (1)
Doing에 이미 옮겼는데 유관부서와 얽혀있어서 done으로 갈 수 없을 때. 시간을 줄이기도 뭣하고 그렇다고 Done으로 보내버리기도 찝찝할 때.
Doing에 따로 칸을 하나 만들고, backlog를 그쪽으로 이동. 시작하는 날짜 써놓고 Done으로 가기 전까지 매일 아침 스크럼미팅할 때마다 동그라미 스티커 하나씩 붙이기.
스티커가 늘어날 수록 개발자는 조급해져서 빨리 끝내야겠다는 생각에 유관부서와의 긴밀한 커뮤니케이션이 일어날 수 있음.

타부서와 연관되어 holding 되는 이슈 관리 (2)
다음 sprint 시작을 위해 planning을 할 때 전개된 backlog를 다른 팀에 공유한다.
그리고 sprint가 진행되는 2주 동안엔 계획한 것 이외에는 진행하지 않을 것이니 혹시 우리가 계획한 것 외에 다음 sprint에서 꼭 진행해야하는 것들은 미리 알려달라고 말한다. 알려주지 않은 것에 대해서는 진행하지 않을 것이라는 말도 덧붙인다.
2013년도에 적용해보니 실제 효과가 있었다.
처음 시작할 땐 sprint planning에서 계획한 backlog를 50% 정도는 인터럽트 처리하느라 완료하지 못했지만, 6개월 후에는 계획한 backlog를 100% 완료할 수 있었다.

(tip) 프로젝트가 끝나는 시점에서의 Agile
Agile이라는건 일을 할 때 좀 더 효율적으로 낭비되는 것 없이 프로젝트를 진행하자는 취지인데, 프로젝트가 마무리지어질 때 쯤엔 Agile로 뭔가를 개선하는 일을 하기보단 정형화된 프로세스에 따라서 마무리하는게 더 효율적으로 보일 수 있다. 이런걸 Agility가 떨어졌다고 표현하는데, 만약 지금의 프로젝트 팀이 이후 프로젝트도 계속 한다면 개선할 사항을 반영할 수 있겠지만, 일반적으로는 TF처럼 한 프로젝트가 끝나고나면 흩어지기 때문에 프로젝트 막바지에 Agility가 떨어지는 상황에서 어떻게 해야할지에 대해 생각해보기.