KPT로 지속적인 피드백하며 성장하기

회고 방법론에 대해 고민하게 된 계기

팀 프로젝트라는 건 쉽지 않은 일이라 생각한다. 많은 사람들이 모여서 같이 작업을 하는 만큼 어떤 일이 생길지 예상을 할 수 없다. 운이 좋게 잘하는 사람들만 만나서 편하게 갈 수도 있겠지만 그렇지 않은 경우가 더 많을 것이다. 마치 팀 프로젝트는 하나의 초기 스타트업과 같다고 생각이 든다. 아직 어떠한 것도 정립되어 있지 않아 모든 것이 백지상태. 좋게 말하면 어느 것을 자유롭게 적용하거나 시도해 볼 수 있지만, 반대로 말하면 수많은 선택지 속에 선택을 해야 되고 그것이 맞는지 틀린 지는 나 같은 주니어에겐 참 어려운 일이다..

어떤 프로젝트를 만드는 데 기술이 어려울 수도 있겠지만 그것보다 계속 이끌어가고 지속적으로 개선해나갈 수 있는 능력이나 커뮤니케이션 같은 *소프트 스킬들이 더 어려운 것 같다. 그래서 요즘 이에 대한 많은 고민을 하고 있다.. 현재 진행 중인 프로젝트에서 자주 스크럼을 하려고 하지만 이것만으로는 부족함을 많이 느꼈고 동료끼리 어떻게 체계적으로 피드백을 잘 주고받을지, 팀의 단합력, 이해력, 수행력 향상을 생각하던 차에 KPT 회고라는 걸 알게 되었다.

하드 스킬(Hard Skill): 프로그래밍 능력, 소프트웨어 디자인 및 설계 등 업무 수행에 직접적으로 필요한 능력

소프트 스킬(Soft Skill): 하드 스킬을 효율적으로 활용할 수 있게 도와주는 소통 능력, 실행력, 리더십 등 대인 관계와 관련된 정서적 능력

곧 있으면 우테코에서 많은 팀작업이나 페어 프로그래밍을 할 예정이므로 이번에 KPT 회고에 대해 알아보고 정리해 그때 적용해 보려고 한다. 조만간 페어 프로그래밍에 대해서도 찾아보고 정리할 계획이다.

다음 글에 대해 너무 공감이 가서 한번 읽어보면 좋겠다. 팀이 현재 아무런 잡음 없이 잘되고 있는 것처럼 보이는 것은 물론 잘되어가고 있는 경우도 있겠지만 사실 상처가 곪아가고 있는 중일 수도 있다.

• 조용하다고 당신의 조직이 건강한가
• 간단하게 요약해보자면
  • 조직이 사람들로 이뤄진 이상 크고 작은 실수가 생기지 않을 리 없다. 그러므로 실수와 문제가 없는 조직일수록 무언가 감추는 것이 많다고 생각해야 옳다.
  • 시끄러울 정도로 실수를 드러내고 지적하는 조직이 조용한 조직보다 성과가 높을뿐더러 높은 성과가 오래도록 유지된다.
  • 그렇기 때문에 조직의 건강성은 무결점의 ‘정적인 상태’가 아니라 문제를 끊임없이 제기하고 그것을 고쳐 나가려는 동적인 과정에서 찾아야 한다.

“지혜란 무엇을 아는지 그리고 무엇을 모르는지를 아는 것이다.” - 공자

KPT란?

KPT는 Keep, Problem, Try의 약자로 세 가지 관점으로 분류하여 회고를 진행하는 회고 방법으로 다음과 같이 3가지의 타입을 작성하고 공유하면서 서로가 의견을 주고받으며 해결책을 이끌어 낼 수 있는 회고 방법론이다.

• Keep: 잘하고 있는 부분, 계속해서 했으면 좋겠는 부분
• Problem: 문제가 있는 부분, 개선이 필요한 부분
• Try: 문제가 있는 부분을 개선할 수 있도록 우리가 시도해 볼 수 있는 부분

KPT 진행 과정

진행 순서

시간은 50분 정도로 진행하는데 여유시간 10분 정도를 추가적으로 잡아주자 (총 1시간).

1. KPT 사전 설명 - 5분
2. Keep, Problem 작성 - 5분
3. 서로 Keep, Problem 공유 - 10분
4. Try 작성 - 7분
5. 서로 Try 공유 - 8분
6. 앞으로 적용할 Try & Action 선정 - 15분

1. KPT 사전 설명

KPT를 팀에 적용하려고 하면 뭔지 모르는 팀원도 있을 수 있으므로 간단하게 설명을 하고 진행하는 게 좋다. 팀의 리더가 먼저 KPT에 대해 공부하고 공유할 자료를 만들어 설명해 주면 좋을 것 같다.

2. Keep, Problem 작성

두 가지의 다른 색깔(ex) Keep - 파랑, Problem - 빨강)의 포스트잇을 팀원에게 나눠준다. 그리고 팀원은 5분 동안 자신의 생각대로 Keep이나 Problem에 대해 작성한다. Keep에는 계속했으면 좋겠는 부분, Problem에는 개선이 필요한 부분을 작성할 수 있다. (여기서 타임 타이머는 언제든지 확인할 수 있게 모두가 잘 보이는 곳에 두도록 하자)

3. 서로 Keep, Problem 공유

각자 돌아가면서 자기가 작성한 Keep과 Problem을 읽고 진행자에게 넘겨주면 진행자는 포스트잇을 화이트보드의 Keep, Problem 영역에 붙인다. 각자 공유가 다 된 후에 이해가 안 되는 부분은 작성자에게 다시 물어볼 수 있다. 이때 작성자는 이해할 수 있도록 설명을 해줄 수 있는데 불필요한 논쟁과 토론이 되지 않도록 진행자가 잘 중재해 줘야 된다. 여기서 중요한 것은 현재 진행되는 프로젝트에서 좋았던 점(Keep), 불편한 점(Problem) 이 구성원들에게 잘 보이게 공유가 되는 것이 중요!

4. Try 작성

이제 Try를 작성하는데 아무거나 내는 것보다는 Problem의 해결책에 대해 작성하는 게 좋다. 여기서 Try를 작성할 때 주의할 점은 구체적이고 실천적이어야 한다. ~~를 잘해보자(ex) 공유를 잘하자~)라는 식의 Try 이면 지켜지기 어렵다. 해결할 수 있는 구체적인 솔루션을 제공해야 지켜질 수 있다.

예를 들어 공유가 잘 되고 있지 않다라는 Problem이 있으면 공유를 잘하자~라는 애매한 Try보다는 ~~을 하면 문서화해서 노션이나 구글 docs에 기록을 해서 공유하자라는 구체적인 솔루션을 제공해 줄 수 있다.

5. 서로 Try 공유

이번에도 돌아가면서 자기가 작성한 Try를 읽고 진행자에게 넘겨주면 진행자는 포스트잇을 화이트보드 Try 영역에 붙인다. 여기서도 또한, 이해가 안 되는 게 있으면 작성자에게 물어볼 수 있다.

6. 앞으로 적용할 Try & Action 선정

Try를 다 공유했다면 다음 KPT 전까지 Action을 취해서 개선할 수 있도록 Try를 선정해야 된다. 한 사람당 2 ~ 3개의 투표권을 가지고 각자 마음에 드는 Try에 투표를 진행한다. 그러면 가장 문제가 있는 Try가 상위권에 올라오게 된다. Try를 많이 뽑게 되면 오히려 집중력이 떨어지기 때문에 한 번의 KPT에서 Try는 2 ~ 3개가 적당하다. 그리고 각 Try마다 담당자를 선정해 적어두면 된다.

예를 들어, ~~을 하면 문서화해서 노션이나 구글 docs에 기록을 해서 공유하자가 Try로 선정되었다면 담당자가 이 Try에 대해 문서화할 양식 및 공유 방법(노션 or docs)에 대해 문서로 정리해 팀에 공유하면 된다. (추가적으로 다음 KPT까지 담당자가 Task를 완료할 수 있도록 팀 리더가 일정 기간이 지나면 진행 상황에 대해 체크할 필요가 있다.)

다음 글에 Action Item에 대해 상세한 예들이 있으니 참고해 보자!

• 팀 문화의 탄생

KPT 진행 팁 및 주의할 점

• 남 탓을 하지 말자
  • 남 탓만 해서는 변화가 있을 수 없다.
  • 내가 먼저 변화된 모습을 보여줘야 설득력 있음.
• 진척 회의와 회고를 분리하자
  • 회고는 어떻게 하면 효율적으로 일할 수 있는 것인가?라는 일의 진행 방식에 대해 논하는 것
  • 일의 진행 상황과 보고는 여기서 논하지 말고
  • 자신들의 업무 방식을 제3자 입장에서 객관적인 시선으로 봐보자
• 회고 기간
  • 회고는 1 주일 단위 정도에서 실시하면 좋다
  • 첫 회고 같은 경우 길어질 수 있지만, 1주일 단위가 정착하면 회고 자체를 짧은 시간에 할 수 있다.
  • 회고을 지속적으로 진행시켜 나가면 서서히 회고 방법 자체도 능숙해지게 된다.
  • 지난주보다 이번 주, 이번 주보다 다음 주에 점점 더 잘 하게 되는 것
• 회고의 ‘습관화’에서 ‘일상화’를 목표로
  • 회고을 계속 이어 가면, 팀은 스스로 현장을 개선해 나갈 것이다라는 의식이 싹트게 된다.
  • 1단계 목표는 정기적인 ‘회고’를 습관화하는 것
  • 다음 단계가 되면, 회고 자체가 당연하게 되어, 일상 업무 속에서 항시적으로 할 수 있게 된다.
  • 그렇게 ‘회고 ‘를 일상화 해 버리는 것이 두 번째 단계
• Keep이 나오지 않는다.
  • 자신의 프로젝트에 좋은 점은 하나도 없고, 문제투성이 혹은 이상이 너무 높거나
  • 원래 이전 회고에서 나온 Try가 전부 제대로 되지 않았다면 Try를 낸 방법 자체에 문제가 있는 것이므로 그것부터 개선 필요
• Problem이 고민 상담이 되는 경우
  • Problem을 낼 때 단순히 고민하고 있는 것을 말하는 것으로 Try가 도출되지는 않는다.
  • 실제로 일어난 불편한(안 좋은) 부분을 내자
• Try가 구체적이어야 한다.
  • Try를 생각할 때 “기분”을 반영시켜 버리는 것은 해서는 안 될 일이다.
  • 다음 KPT의 회고 때 무엇이 되어 있고 무엇이 안 되어 있는지 명확하게 판정할 수 없다.

참고:

• 소프트웨어 개발자가 ‘소프트 스킬’ 쌓는 방법
• KPT하는 스타트업은 성장한다
• 실수와 문제가 없는 스타트업은 없다
• 팀 문화의 탄생
• 회고에 대한 고찰 - KPT 진행의 노하우에 대하여

*틀린 부분이 있으면 언제든지 말씀해 주시면 공부해서 수정하겠습니다.