Agile 프로젝트 퀵가이드(13) : Execution & Control편-스크럼회고

스프린트 회고란?

회고란(Retrospective)란 사전적 의미로 뒤를 돌아보다, 지나간 일을 돌이켜 생각해본다는 뜻을 갖고 있습니다.

스크럼 프레임워크에서는 회고를 통해 스크럼 팀이 자신을 스스로 되돌아보고 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 기회를 갖게 됩니다. 여기서 개선할 대상은 제품에 대한 것이 아니라, 일하는 방식에 대한 것을 말합니다.

즉, 스프린트 회고는

• 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토하고
• 잘된 것들, 그리고 개선의 여지가 있는 주요 항목들을 알아내고 순위화하여
• 스크럼팀이 작업을 수행하는 방법에 대해 필요한 개선을 실천할 수 있도록 계획을 수립 하는 활동입니다.
  여기서 도출된 개선 계획은 Action Item으로 관리하여 다음 스프린트 회고 미팅에서 해당사항이 잘 이행되었는지 확인할 수 있어야 합니다.
  
  

참고로, 스크럼 가이드북에서는 다음과 같이 회고 활동을 정의하고 있습니다.

스크럼 마스터는 스크럼 팀이 스크럼 프로세스 프레임워크 안에서 그 개발 프로세스와 실천 방안이 다음 스프린트에 좀 더 효과적이고 즐겁게 수행할 수 있도록 개선하는 것을 장려한다. 각 스크럼 회고 미팅에서, 스크럼 팀은 제품 또한 조직 내 표준에 어긋나지 않는 한도에서 필요에 따라 작업 과정들을 개선하거나 “완료”의 정의를 조정함으로써 제품 품질을 높일 방법들을 계획한다.

회고 방법

회고 활동을 위하여 다양한 기법이 존재하는데, 많이 쓰이는 회고 방법으로는 Good & Bad Things, PMI (Plus/Minus/Interesting), KPT(Keep/Problem/Try), 3L(Liked/Learned/Lacked), 워드 클라우드(Word Cloud) 등이 있습니다.
회고 활동에 앞서 스크럼 마스터가 팀 성격에 맞는 회고 기법을 미리 찾아보고, 적용한다면 보다 원활한 소통과 나은 결과를 얻는 데 도움이 될 것입니다.
Good & Bad Things

PMI(Plus/Minus/Interesting)

KPT(Keep/Problen/Try)

Word Cloud

다음 사이트에 다양한 케이스에 대한 여러가지 회고 방법들이 잘 설명되어 있어 참고하면 도움이 될 것입니다. http://www.funretrospectives.com/category/retrospective/

회고 절차

여기서는 KPT 기법을 사용하여 회고 절차를 설명하겠습니다. KPT 기법은 다음의 항목들에 대해 의견을 적음으로 단순히 좋은 것과 나쁜 것이 아닌, 조금 더 깊이있게 스스로를 돌아보게 합니다.

• K(Keep) : 금번 스프린트에서 좋았거나 유지하고 싶은 점
• P(Problem) : 금번 스프린트에서 제거하고 싶은 문제점
• T(Try) : 다음 스프린트에서 시도하고 싶은 것

P와 T에서 비슷한 의견이 나올 수도 있는데, P는 프로젝트에 부정적인 영향을 미치는 문제로 제거에 포커스를 둔 반면에 T는 좋은 것은 더 강화하고 나쁜 것은 다른 방식으로 바꾸는 데에 초점을 맞춥니다.

KPT 방법을 사용할 경우 스크럼 마스터는 다음과 같이 절차를 준비하여, 스크럼 팀과 함께 회고 미팅을 수행합니다.

1) 준비 및 회고 작성

체크인 및 준비

• 먼저 팀원 한 명씩 번갈아 가며, 이번 이터레이션에서 느꼈던 것을 짧게 이야기한다.
• 내용은 자유롭게 말할 수 있도록 하되, 시간은 개인별로 1분 30초 이내로 제한한다.
  ※ 내용 자체가 너무 부정적으로 흐르지 않도록 하고, 팀 내 인원에 대한 불만을 이야기 하지 않도록 한다.

Keep / Problem / Try할 것에 대해 각각 포스트잇 작성

• 참여 인원은 3 가지 색깔의 포스트잇을 선택하여 KPT각각에 대하여 3 장씩 작성한다.
• 작성 내용은 다른 사람도 이해할 수 있도록 공용의 언어로 작성한다.
• 작성이 완료된 사람의 포스트잇부터, 보드 또는 벽에 KPT 칸을 나누어 붙이도록 한다.
  ※ 인원이 많을 경우(10 명 이상) 시간을 단축시키기 위해, 포스트잇을 3 장 대신 2 장 만 사용한다.
  

2) 의견 공유 및 Voting

의견 공유

• 포스트잇 내용중 비슷한 것이 있으면 그룹핑한다.
• 진행자는 그룹핑된 내용을 간략하게 정리하여 전체 인원과 공유한다.

Voting

• Voting 스티커를 팀원들에게 나누어 준다.
• Try 할 부분 중 우선적으로 개선하고 싶은 항목을 마음 속에 생각하게 한다.
• Voting 스티커를 붙이고 득표수대로 우선순위를 정한다.
  

3) 개선 항목 도출

• 선택한 항목을 어떻게 발전시켜야 더 도움이 될 지, 방해가 된 내용은 어떻게 개선할 지에 토론하게 한다.
• 결론에 대해 이야기하고 Action-Item으로 정리한다.
  

회고 주의 사항

스크럼 마스터는 다음과 같은 회고가 되지 않도록, 팀원들을 독려해야 합니다.

불평이 가득한 회고

• 내용 자체가 너무 부정적으로 흐르거나, 팀 내 인원에 대한 불만으로 이어지지 않도록 해야 한다.
• 팀 내부에서 원인과 개선점을 찾기보다, 팀 외부의 조직이나 제품 책임자(혹은 PM)가 제대로 일을 하지 않기 때문이라는 불평이 쏟아져 나올 수 있다. 이런 경우 대개 초기에는 부정적인 한 두 명의 입에서 의견이 나오는 식으로 시작해서, 회고가 반복되면서 불만의 에너지는 팀 전체로 전염이 되고 결국, “그래.. 우리만 잘 하면 뭐해~” 라는 식의 무기력한 분위기가 팀 전반에 자리잡게 된다. 특히 팀의 자유로운 의견 개진을 위해 제품책임자(혹은 PM)를 회고 때 배제할 경우 이러한 분위기로 빠져들기 쉽다.

도출된 문제점이 해결되지 않고 방치되는 경우

• 회고는 나빴던 점을 이야기하고 끝나는 것이 아니라, 정말 개선되는 것을 팀원들이 체감할 수 있도록 보여주는 것이 중요하다.
• 스크럼 마스터는 회고가 끝난 이후, 회고에서 도출된 개선사항들이 지속적으로 F/up되고 개선될 수 있도록 관리하고, 이와 관련된 진행 내용과 결과에 대해서 팀원들에게 피드백을 제공해야 한다.
  
  

이처럼 스스로를 돌아보는 스크럼 회고 미팅이 끝나게 되면 스크럼 팀은 다음 스프린트에 실천할 개선 사항들을 얻게 되며, 이러한 개선 사항들을 다음 스프린트에서 실천함으로써 스크럼 팀 자체는 스스로를 검토하고 조정하여 지속적으로 개선/발전하는 결과를 얻을 수 있습니다.

눈에 보이는 큰 개선 효과가 아니더라도 팀웍과 사기 진작 면에서도 도움이 될 수 있습니다. 아주 간단한 예를 들자면, 첫번째 회고에서 프로젝트 팀을 위한 간식거리가 제공되면 좋겠다는 팀원의 의견이 있었습니다. 프로젝트 예산이 넉넉하지 않았기 때문에 관리자는 팀을 위한 간식을 구입하는 것에 관심을 두지 않았지만, 회고에서 나온 의견을 수용하여 간식을 제공함으로써 비교적 적은 비용으로 팀원 모두가 만족하며 팀 분위기도 상승되는 효과를 얻을 수 있었습니다.

또 어떤 팀의 경우에는 회고에서 나온 의견을 반영하여, 프로젝트의 개발 Tool을 바꾼 예도 있습니다. 처음 사용한 Tool은 프로젝트 주최측에서 선정한 Tool이었지만, 두번째 선택한 Tool은 개발팀 스스로 선택하였기에 새로운 Tool에 대한 학습에 스스로 몰두하며 Tool 사용시 문제가 발생하더라도 기존처럼 불평하기 보다는 해결에 보다 적극적인 노력을 들임으로써 이전보다 나은 결과를 얻을 수 있었습니다.

스프린트마다 회고를 통해 이러한 개선을 함으로써 팀이 스스로를 발전시키고 만족감과 향상된 결과를 얻을 수 있는 공식적 기회를 제공한다는 점에서 회고라는 방법은 스크럼 프레임워크의 가장 큰 매력 으로 꼽히기도 합니다.

< EOF >