스크럼 스탠드업

agile scrum daily standup

개발팀에 애자일 스트럼을 도입한 지 수개월이 지났다. 중간에 거의 애자일 스크럼을 중단하게 되었던 적도 있었지만, 팀원들과 논의 후 다시 적극 도입해 보기로 했다. 중간중간 좋은 기억이 있었기 때문이다. 

이전엔 스프린트만 계획하고 지켜봤는데, 데일리 스탠드업을 도입해 보기로 했다. 동료 간 태스크가 팔로우업이 안 되는 이유에서였다. 이전 회사에서 경험한 바로는, 팀 안에서 개발 콘텍스트를 잃지 않는 목적에서 매우 좋았던 경험이 있다. 

출처: growing agile

우리는 점심 식사 전 20분, 중앙 로비에 서서 20분 간 스탠드업을 실시한다. 리모트 근무가 확대되면서, 리모트 근무 동료를 위해 최근엔 행아웃으로 바꾸고 있다. 스탠드업에서는 다음과 같은 이야기를 한다. 

1. 어제 한 일

2. 오늘 할 일

3. 개발 중 직면한 기술적 어려움

4. 어떤 지원이 필요한지

종종 기술적 이슈가 나오면 이야기가 길어질 때가 있지만, 서로가 의도적으로 이 부분은 따로 만나서 이야기하거나, 더 큰 사항이면 별도 미팅을 열어 이야기하자며 정리한다. 

아니, 정리를 해야만 한다. 왜냐하면 밥을 먹어야 하니깐. 그래서 오전 11:40분은 좋은 시간이다. 밥을 먹어야 한다. 만약 시간이 더 있으면 스탠드업임에도 불구하고 기술 디스커션이 끊이지 않을 것이다. 또한 우리는 유연 출근 제라 11시까지 오면 되기 때문에 11:40분은 여러모로 좋은 시간대인 듯하다. 

중요한 점은, 자칫 잘못하면 이런 매일의 공유가 매일의 '보고'로 이루어지며, 뭔가 진행이 되지 않는 동료에 대한 비난과 실망으로 이어질 수 있다는 점이다. 이에 따라 팀원과 리더는 이 스탠드업의 목적을 서로가 하는 업무를 파악하고, 같은 콘텍스트 안에 있게 하려 하는 목적을 분명히 알아야 한다.

또한 이재왕 님의 '애자일 & 스크럼 프로젝트 관리' 책에 의하면, 이 스탠드업 시간에 투두 리스트를 완료로 옮기는 작업을 하게 되면 팀원들이 성취감을 느낄 수 있다고 한다. 우리도 이건 적용 안 하고 있는데, 한 번 도입해 봐야겠다. 

심지어, 우리 팀의 비개발팀에서도 이런 스탠드업의 장점을 빌려해 보면 좋겠다는 이야기가 오가고 있어 흥미롭게 지켜보고 있다. 비개발팀에서도 혹시 스크럼을 적용할 수 있는지, 그런 사례가 있다면 읽거나 듣고 싶다.