성장을 위해, (조금은 아픈) 소통의 도구 : 회고, Retrospect

회고, Retrospect : 내일 또 아프지 않도록 쪼금 아픈 소통

 

팀은 다양한 사람들이 모여서 함께 일하는 공간입니다. 팀원들 간에는 어러 가지 업무 수행 능력에 있어 다양함이 존재하기 나름입니다. 그러다 보니 실수도 발생하기도 하고, 요청한 업무가 엉뚱하게 처리될 때도 있고, 일을 서로 미루기도 하고... 다양하게 불편한 상황들이 끊임없이 발생하게 됩니다.

 

그런데, 이 상황을 어떻게들 대응하세요?

1) 그냥 둔다... 좋은 게 좋은 거지... 휴우...

2) 내가 손해보는 건 참을 수 없다. 대놓고 똑바로 하라고 말한다.

 

1번만 계속하면... 만만한 동료가 되고... 2번만 계속하면 재수 없는 동료가 됩니다. 둘 다 별로이네요.

 

이럴 때 리더가 챙겨주면 좋은 것이 바로 회고(Retrospect) 입니다. 회고는 대놓고 불편한 이야기를 할 수 있는 자리인데요. 진행하는 방식에 대해서 몇 가지 그라운드 룰만 잘 정해주면 서로의 감정을 상하지 않고도 현재 보다 더 나은 미래에 대한 이야기를 나눌 수 있게 됩니다.

 

사실은 놀랍게도~ 우리는 수평적인 토의를 어렸을 때 부터 많이 배우고 경험해 왔어요. 한참 안 써먹어서 까먹었을 뿐이에요. 초등학교 때 학급 회의하면서 지난주에 있었던 문제점, 건의사항 토의... 이런 회의 다들 해보시지 않았나요? 회장이라는 친구가 앞에서 사회 보면서 토론하는 회의요. (회의 특성상 선생님은 웬만하면 개입하지 않죠) 회장도 뭐... 완장이라 볼 수 있겠지만, 초등학교 기억을 되살려 보면 그냥 친구잖아요. 같은 친구들에서 서로 잘한 것과 잘못한 것을 이야기하면서 우리 다음번에는 이런 부분은 고쳐보자, (오글거리지만) '더 좋은 학교를 만들어보자' 뭐 이런 말 많이 했잖아요. 기억해보세요. 아마도 이 회의는 우리 인생에서 가장 안전한 회의였을 수 있습니다. 

 

사람들이 회사에서 입을 닫는 이유는 몇가지가 있는 거 같았어요. 

- 내가 무슨 이야기를 해도 이 회사는, 또는 저 임원은 도통 듣지를 않아

- 내가 제안하는 거는 맨날 옛날에 다 해봤데... 

- 이 사람들은 왜 이렇게 공격적이야? 무슨 말을 못 해...

 

그럼 안전하다는 것이 무슨 의미일까요? 

- 내가 무슨 말을 해도 이 사람들은 나의 이야기를 끝까지 들어줄 것이다.

- 내가 제안하는 아이디어에 대해서 객관적으로 검토해 줄 것이다. 

- 혹시라도 부정적인 피드백을 할 때도 품격 있는 말로 논리적으로 설명해 줄 것이다.

 

그래서, 우리 알스퀘어에서는 회고를 다시 도입하는 과정에 있어 몇 가지 그라운드 룰을 세팅하는 것에 많은 노력을 기울였습니다. 뭐 내용은 사실 별거 없죠...

- 진심으로 우리를 생각하는 마음가짐으로,

- 명확하게 오해 없는 표현들을 사용해서,

- 최대한 정중하게 이야기 하자는 것이었습니다.

아내와 부자 되는 방법을 이야기 나눌 때처럼, 아이와 수학 성적을 올리는 방법을 이야기 나눌 때 처럼, 사랑과 배려로 대화 나누어 달라는 부탁이었어요.  

 

그 내용을 잠시 공유합니다.

---

회고는 왜 해야 하나요?

이번에는 힘들었지만 다음에는 조금 더 쉽게 일을 하기 위해서

- 여러 번 동일한 상황이 반복되는데 왜 나는 똑같이 힘들까? 아마도 그 이유는 쉽게 하는 방법을 고민해 본 적이 없기 때문일 것입니다.

 

Lesson learnt을 최대화하기 위해서

- 힘들게 수행한 모든 활동(task, bug fixing, project...) 에서 '배울 수 있었던 것(possibly learned from)'들을 진지하게 확인함으로써 진짜 배우고 내 것(100% mine)으로 하기 위해서입니다.

서로 행복하게 일하기 위해서

- 두 번 같은 실수는 서로를 힘들게 합니다. 잠깐 아프더라도 잘못을 알려주고, 다음에 그 실수가 일어나지 않으면 그다음부터는 아프지 않아요. 한 번만 아프면 돼요.
- 아플까 봐... 그냥 넘어가면, 계속 아픈 거예요.

회고는 어떻게 하나요?

모든 것에 앞서 회고는 올바른 마음가짐이 젤 중요합니다.

• 사랑 : Blame이 아니라 Grow together 하는 자리입니다. 친구, 조카, 연인과 대화한다고 생각하세요.
• 다양함 : 본인의 생각은 항상 부족합니다. 나의 생각과 너의 생각이 모인 우리의 생각이 항상 훌륭합니다. 나는 맞고, 너는 틀리다는 생각은 집에 두고 오세요.
• 구체적임 : 모두가 이해할 수 있는 표현을 써주세요. 어렵게 설명하거나, 둥글둥글 설명하는 건 시간낭비예요.
• 이런 마음가짐으로 긍정적인 사건과, 부정적인 사건을 이야기 나누어 보세요.

개인 스스로의 회고는 각자의 방식으로 해보세요. 그건 not my business

회고 방식 중 하나로 3Fs + 2Fs라는 방식이 있어요. 스프린트 종료 시마다 해보면 좋은 방식이에요.

• 업무 방식부터 변경되어야 자연스럽습니다. waterfall에서 agile로 변화가 필요해요.
• Agile practice은 '주기적인 product 개발 문화'를 대표하는 개발 방식입니다. 이건 별도로 이야기가 필요해요.
• 3Fs : Fact, Feeling, Finding, 2Fs : Future, Feedback, 예를 들어 볼까요?
  • Fact : 이번 스프린트에서는 모든 프로세스대로 릴리즈를 잘 진행했는데, 특정 휴대폰에서만 정상적으로 화면이 보이지 않는 상황이 발생했었죠. 근데 하필이면 김문규 님의 것이었네요.
  • Feeling : 아.. 식겁했죠. 안그래도 깐깐한 양반인데... 망했구나 싶었어요. 지난번에도 상무님이 같은 문제를 지적했던 적이 있거든요. 정식 릴리즈 점검 단계에 넣어야겠어요.
  • Finding : 이전에는 뭐가 문제였어요? 그분이 Brave라는 특이한 브라우저를 사용하거든요. 첨에는 듣보잡이라서 그냥 다른 브라우저 쓰세요.. 라고 말했는데.. 이런.. 1억 다운로드 브라우저더라고요.. 헐.. 그래서 보니까 그 브라우저가 ad blocker로 유명한 브라우저인데... 이런이런 사유로 우리 사이트 기능 일부가 블록 되더라고요. 그래서, 좀 보니까.. 그게 이런저런 이유로 광고로 검출되고 있어서 요렇게 조치했죠. 아무래도 다음에는 상위 top 5 브라우저를 대상으로 테스트를 하고서 릴리즈를 해야 할 것 같아요.
  • Future : 그럼 우리 릴리즈 전 통합 테스트에 검수 조건을 하나 더 추가하도록 할게요. 릴리즈 담당자분들께서는 이점을 다음 릴리즈 시에 꼭 챙겨 주세요.
  • Feedback : (2주 후 다음 스프린트에서) 이번 릴리즈에서는 상무님 폰에서도 아무 문제없었어요. 지난번 회고에서 정했던 점검 대상 브라우저를 확대했던 것이 큰 도움이 되었던 것 같아요. 짝짝짝!

KPT라는 방식도 있어요. 스프린트 종료 시보다는 업무 방식의 문제점이라던지... 조직 구성의 문제라던지... task가 아닌 다른 차원의 문제 상황의 해결을 위한 회고인 경우에는 더 잘 어울려요. 

• 논의하려는 문제 상황 : 구독 기능을 추가하는 과정에서 잦은 기획 변경이 발생하여서 개발 일정을 맞추기 어려웠던 문제에 대한 해결안 논의
• Keep : 유지해도 좋을 것
  • 개발 일정을 맞추기 위해 기획안이 잘못되었음에도... 이를 계속 추진하는 것은 더 큰 문제. 잘못이 확인되는 즉시 공유하고 변경하는 것은 필요함
  • 덜 완성된 기획안임에도 불구하고 너무 빨리 개발에 전달한 것이 문제일 수도 있지만,  빠르게 개발과 기획이 사전 조율이 가능하다는 관점에서는 긍정적이고 유지 필요
• Problem : 해결해야 하는, 없애야 하는  문제점
  • 변하지 않을 것 같은 요구사항과 변할 수도 있는 요구사항을 구분해서 알 수 없기 때문에 개발에서 사전에 대응 준비가 여의치 않음
  • 상무님이 중간에 요구사항을 변경하는 바람에 기획에서 변화를 예측하기가 쉽지 않음
• Try : 문제를 해결하기 위해서 해볼 수 있는 것들
  • 상무님하고 터놓고 이야기를 한번 해보자 (담당: OOO 팀장)
  • 기획팀에서 여러 가지 상황을 고려해서 요구사항이 변할 가능성을 수치화해보자. 개발팀은 가능성이 높거나 높아지고 있는 요구사항은 좀 더 유연한 대응을 준비해보자 (담당: OOO PM)

시작하기 전에 마지막으로 유의할 사항

• 주간 회의랑 회고(retrospect)는 분리합니다. 회고는 정기적으로 애자일 스프린트 종료 시 또는 비정기적으로 문제 상황이 인지되었을 때 별도로 진행해야 해요.
• 각자는 팀의 일원입니다. 누군가의 문제는 존재하지 않아요. 팀과 우리의 문제라고 생각해야 해요.
• 말투는 품격 있고 배려있게, 내용은 객관적으로! 그냥 둥글게 둥글게 하는 회고는 명확한 해결책이 제시되지 않을 것이기 때문에 오히려 기분만 상하게 될 거예요.

회고 관련해서 참고할 자료가 있을까요?

• 회고 없는 성장은 없다 : https://brunch.co.kr/@hsjcompany/10
• 프로덕트 매니저의 애자일 회고 방법론 - KPT 실전편 : https://www.designsori.com/zero/1157702
• 회고 (Retrospective)에 대한 정리 및 설계 #8 : https://github.com/JaeYeopHan/tip-archive/issues/8
• 회고에 대한 고찰 - KPT 진행의 노하우에 대하여 : https://www.moreagile.net/2016/04/kpt.html
• KPT 회고란 무엇인가? : https://brunch.co.kr/@jinha0802/35

Are you ready to retrospect?

---

첫 회고 회의를 시작하면서 제가 위 내용을 하나씩 차례로 설명한 후, 약 3시간에 걸쳐서 대망의 첫 회고를 진행했습니다. 저는 최대한(?) 개입을 자제했고요. 때때로 위태로운 순간도 있었지만, 적절하게 컨트롤하면서 무사히 마칠 수 있었습니다. 팀과 첫 회고에 대한 느낌을 1:1로 이야기를 나누어 보아야겠지만, 나름 소기의 성과를 달성한 시간이 아니었나 싶습니다. 누구도 크게 불쾌하지 않았다고 생각하고, 논의는 자연스럽게 몇 가지 문제점으로 집중이 되었고, 그 문제점을 개선하기 위한 대안 제시와 합의까지 무사히 잘 이루어졌으니까요. 긴 회의록이 있지만 이건 공유드리기 어렵네요. :) 궁금하시면 입사 지원부터... 쿨럭

 

저도 진심으로 다음번 회고가 궁금합니다. Future가 조금이라도 바뀌었길 간절히 기대해 봅니다.