스타트업 개발팀의 애자일 회고 방법론 KPT – 도입편
마케팅팀 멤버로부터 개발팀이 부럽다는 이야기를 듣다.
도쿄에서 앱에이프 서비스를 설명하는 외부 세미나가 있어서 세일즈팀, 개발팀, 마케팅팀 멤버들과 일정을 마치고 돌아오는 전철 안에서 마케팅팀 멤버가 개발팀은 어떻게 매일 아침에 하는 Stand-Up 미팅을 그렇게 짧은 시간에 잘 마무리하느냐는 질문을 받았다.
내가 현재 Product Manager로 소속되어 있는 개발팀은 총 7+1명으로 매일 아침 스탠드업 미팅을 통해서 현재의 진행 상황 공유 이와 관련해서 부족한 부분, 도움이 필요한 부분 등 프로젝트 일정 관리 및 각자의 업무를 체크하는 시간을 마련하고 있다. 해당 Stand-Up 미팅은 매일 아침 5 – 10분 정도로 이뤄지며 Asana(프로젝트 관리 툴)로 만든 데일리 리포트를 통해서 각자의 진척 상황을 빠르게 확인할 수 있다. (해당 부분은 추후 따로 글로서 작성하겠다)
위에 언급한 내용을 토대로 그렇게 시간들이지 않고 끝낼 수 있다고 말했는데, 오늘 오후에 팀 멤버들이 티타임을 가지던데 그것도 보기 좋다고 말하는 것이다. 그건 일전에 KPT를 통해서 팀 멤버가 제안한 업무 외적으로 팀 멤버들과 서로 이야기할 시간이 부족했다는 점을 보완하기 위해서 스케줄을 넣었던 거였다.
이때 마케팅팀과 개발팀 서로 크게 다를 게 없을 것 같았는데 불현듯 스쳐 지나간 부분이 KPT였다. 개발팀은 작년 중순부터 KPT를 통해서 팀 내 개선 사항 및 프로젝트의 회고를 진행하였고 상당 부분을 개선하며 꾸준히 진행해 왔는데 이 부분이 외부에서 개발팀을 보았을 때 무언가 바뀌어가고 잘 하고 있는 듯한 느낌을 받았을 수도 있겠구나 싶었다.
주니어 PM이 KPT와 만나게 되다.
작년 초 디자이너에서 프로덕트 매니저가 되면서 개발팀을 담당하였는데, 제품 개발 속도와 방향성도 중요하지만 개인적으로 반년 정도 지난 시점에서 제품을 만드는 팀의 단합력과 이해력 그리고 같은 목표를 향한 업무 수행력이 필요해지는 시점이라고 생각했다.
주변에 조언을 구하고 직접 팀 빌딩 관련해서 검색을 통해 KPT 애자일 회고 방법론을 알게 되었다. KPT는 회고를 통해서 일이나 프로젝트의 개선을 가속화 시키는 프레임워크이다. 업무 및 프로젝트의 회고를 Keep, Problem, Try로 정리하는 방법인데 상당히 심플하며 시각적으로도 알기 쉽고 멤버들도 어렵지 않게 시도할 수 있는 방법론이라고 생각했다. (실제로 도입 후 9개월간 10번의 KPT를 실시했을 정도로 꾸준한 개선과 효과를 보고 있다)
좀처럼 팀 내에서 서로의 생각을 공유하기 힘들거나, 리더와 멤버 간의 인식 차이가 있거나, 문제가 나타나도 솔루션으로 연결되지 않아 고민이라면 KPT로 해결할 수 있을 것으로 생각된다.
그래서 KPT는 무엇인가
팀 내 미국인 멤버(Project Manager)에게 KPT에 대해서 물어보니 잘 모른다고 하더라. 리서치를 해보니 KPT는 일본에서 유행하는 방법론이지만 초기 제안자는 Alistair Cockburn가 Reflection Workshop 내용 중에 The Keep / Try Reflection으로 언급하였다고 한다.
|
What we should keep. Where we are having ongoing problems. What we want to try in the next time period. – Alistair Cockburn |
해당 방법론이 일본 기업에서는 애자일 개발 방식의 회고 수법으로서 많은 분야에 도입하고 있다고 한다.
Keep : 좋았던 부분, 계속해서 유지되었으면 하는 부분
Problem : 잘되지 않았던 부분, 문제라고 생각하는 부분
Try : Problem을 해결할 수 있도록 실천해 보았으면 하는 부분
위 3개의 타입을 정해진 시간 순서대로 작성하고 공유하면서 서로의 의견을 나눔으로써 해결책을 찾을 수 있도록 유도하는 간단한 회고 방법론이다. (대략 50분 정도로 마무리 가능)
특히, Try가 상당히 중요한 포인트라고 생각하는데 예를 들면 `결과물에 실수가 많다`라는 Problem에 대해서 다음부터는 신경 써서 잘하자보다는 제출 전에 팀 멤버에게 리뷰 받는 구조 만들기를 통해서 해당 Problem에 대해서 다들 좋게 좋게 넘어가는 게 아니라 간단하더라도 확실히 해결할 수 있는 솔루션을 제안하여 팀 내에서 일어나고 있는 불편한 부분을 해소할 수 있는 게 가능하다.
여기서 중요한 것은 Problem를 방치, 방조하지 않고 가시화하여 팀 내에 공유하는 것이다. 팀에 공유가 되어 멤버들이 같은 문제를 인식하고 있다면 어떻게 해결할 것인지 같이 이야기하고 개선해나가는 것이다.
KPT를 팀 내에 도입한 효과에 대해서
개선이 필요하다고 생각했던 부분이 개선되기 시작했다.
KPT를 9개월 정도 진행하면서 가장 만족했던 부분은 작은 문제이지만 개선이 필요하다고 생각만 했던 것이 팀 내에 공유되고 다들 문제로 인식하고 개선으로 이어졌다는 부분이다. 모든 문제는 한 번에 개선할 수 없기 때문에 작은 해결책을 제안하고 실천하면서 또 이와 관련해서 다른 문제가 나타나면 다시 개선할 수 있는 솔루션을 제안하는 식으로 팀 멤버 간에 문제 인식에 대한 이해와 실천이 유대 관계로 단단해지면서 업무 효율성도 높아지는 게 실제로 느껴지기 시작했다.
팀 업무 및 프로젝트가 구조화되기 시작했다.
개발팀은 현재 노션을 도입(이것도 KPT로 제안되었던 부분)하여 업무를 통해서 배운 내용을 최대한 문서로 남기고 공유하면서 멤버들이 같이 성장할 수 있는 구조로 만들어져 있다. 이게 업무를 통한 문서화 뿐만 아니라 KPT에서 제안된 솔루션을 각 멤버가 생각하는 해결 방식으로 구조화하여 실천할 수 있도록 문서화하여 제안하는 부분이 상당히 매력적이었고 멤버들이 스스로 움직이고 노력을 기울이는 게 나 또한 많이 배우고 있다. 팀 내 업무 방식 등의 개선 및 구조화는 PM이 책임지고해야 한다는 인식을 깨뜨려주는 부분이어서 다양한 문제를 해결할 수 있는 범위가 넓어진 느낌이 든다.
매월 팀 멤버들과 KPT 하는 습관이 생겼다.
아무리 좋은 방법론도 결국에는 계속해서 스프린트 하지 않으면 안 된다. 한 번의 회고로 모든 문제를 해결할 수 없을 뿐만 아니라 문제는 언제 어느 상황에서도 또 나오기 마련이다. 매월 1-2번의 KPT를 통해서 문제를 인식하고 개선할 수 있는 실천 방안을 마련하고 공유하고 같이 성장해나가는 게 가시화되다 보니 KPT를 할 시점인데 안 하고 있으면 멤버들이 슬슬 KPT 할 때 아닌가 하고 먼저 이야기한다. PM이 제안하지 않아도 멤버들이 먼저 하고 싶어하고 이게 팀 내에서 습관처럼 진행되고 있다는 부분이 팀을 건강하게 만들 뿐만 아니라 업무 효율성을 늘려주고 있다고 생각한다.
회고의 습관화에서 일상화를 목표로
이번 글에서는 KPT에 대해서 대략적인 느낌만 적었기에 도대체 어떻게 하면 되는거야라는 분들도 있을 거라고 생각된다. KPT를 적용한 팀내 도입 사례는 다음 글에서 상세하게 공유 예정이다. 현재 개발팀에서 KPT를 습관화하는 것까지는 자리를 잡았지만, 이것을 각각의 업무, 프로젝트 등 팀 내에 소속되지 않는 상황에서도 KPT를 적용할 수 있도록 하는 것이 목표이다. 그리고 개발팀뿐만 아니라 마케팅 팀, 세일즈 팀 등에도 좋은 것은 알려주고 실천하여 건강한 팀을 넘어서 같이 성장하는 스타트업을 목표로 하고자 한다.
Jayden님과 모비인사이드의 파트너쉽으로 제공되는 기사입니다.
