회고를 왜 하시나요?

여러분은 회고를 하고 계신가요?

며칠 전에 회고를 돕기 위한 서비스를 제작하는 팀을 만났습니다. 이 팀은 KTPA 라는 유명한 회고 양식을 토대로 많은 사람들이 회고를 하기를 바랬습니다.

하지만 정작 왜 회고를 해야 되는 지에는 대답을 잘 못하더군요. 회고는 일기가 아닙니다. 단순히 하루에 무엇을 했는지에 대해 쓰는 게 아니라는 말입니다.

회고를 하는 목적은 Future Action 을 도출해내기 위해서 입니다. Future Action 은 다음엔 어떤 시도를 해볼까? 입니다. 그래서 KTPA 는 Future Action 을 쉽게 도출하기 위해서 존재하는 도구라고 볼 수 있습니다.

그러니 회고를 통해 Future Action 을 도출하세요.

• 내가 다음 주에 어떤 걸 실천하면 어떤 문제를 해결할 수 있을까?
• 이거 해보면 좋겠다?
• 당장 다음 주에 시도해볼 수 있는 게 있을까?

단, 지킬 수 없는 Action 은 도출하지 마세요!

Action 에 대한 FeedBack 까지 받아야 회고를 하는 의미가 있습니다. FeedBack 으로 어떤 문제가 어떻게 얼만큼 개선되었는지 확인하세요.

짧은 단위로, 예를 들면 일주일 단위로 Action 의 유효성에 대해 FeedBack 을 하세요.

1. Action 도출하기
2. Action 을 실천하고 유효성에 대해 FeeBack 하기

이 두 개가 전부이고 이게 에자일입니다.

마무리하겠습니다.

회고의 양식은 중요하지 않습니다. 기록하는 방법도 중요하지 않습니다. 하지만 Action 도출과 Action 의 실행이 어떤 효과가 있었는 지에 대한 FeedBack 은 반드시 있어야 합니다.

애자일 조직이 되고 싶나요?

에자일 조직이라고 말하면서 회고하는 방법에 집착하지 마세요.

진정한 애자일 조직은 다음과 같습니다.

• 피드백이 되고 있는 조직이다.
• 되도록 자주 더 많이 빠르게 피드백을 하려고 한다.
• 피드백을 통해 더 자주 많이 빠르게 학습하려 한다.
• 피드백을 위해 어떤 시스템이 있고 어떤 노력을 하고 있다.

피드백은 결국 학습입니다. 빨리 개발하는 조직이 애자일 조직이 아닙니다.
빨리 더 많이 학습하는 조직이 애자일 조직입니다. 후자는 고객한테 더 빨리 더 많은 가치를 줄 수 있습니다. 더 빨리 더 자주 우리 조직이 학습한 만큼 고객에게 줄 수 있는 가치가 늘어납니다.

TDD 가 왜 애자일 Practice 일까요?

TDD 가 왜 애자일 Practice 일까요? 피드백을 엄청 빨리 자주 하기 때문입니다. TDD는 코드를 치는 단계에서 피드백을 엄청 빨리 자주합니다. 이게 TDD의 목적이기 때문입니다.

그래서 TDD 가 단순히 테스트를 먼저 작성하는 것이라고 오해하시면 안됩니다. 테스트를 먼저 작성하는 게 에자일의 목적이 아니기 때문입니다. 우리는 테스트 코드 없이도 TDD 를 할 수 있습니다. 계속 짧은 주기로 동작하는지 확인하면 됩니다. 하지만 이게 귀찮으니 테스트 코드를 가지고 자동으로 확인하는 것입니다. 그래서 테스트 코드는 부산물일 뿐입니다.

마지막으로

여러분 에자일 책을 많이 읽는다고 에자일이 되지 않습니다. 자연스럽게 피드백을 많이 하려고 하세요. 그게 에자일입니다.

그리고 에자일은 혼자보다 함께하세요. 구성원의 합의하에 진행되는 에자일은 더 어렵지만 더 많은 것을 도출합니다.