Retrospective method KPT

I will present you here a method i discovered in Japan and actually never seen elsewhere back in Europe. Fortunately I’ll remediate to that and give you a quick explanation about it !

The KPT method (Keep Problem Try) is a team retrospective formalization method. It can be used combined with any other agile methodology and is inspired by the Kaizen principle (continuous improvement) originally created by Toyota. The basic idea is pretty simple and like most of methods it relies on visual management.

The principle is simple, based a theme (usually the course of the last sprint of your release), we will divide our whiteboard in 3 major parts:

  • Keep: The good things that happened and that we want to keep as part of our process / culture.
  • Problem: The challenges we faced in the current sprint and the improvements we need to make.
  • Try: The correctives actions to get rid of the previous problems or the improvements in order to get a smoother course on the next sprint.

This whiteboard will be reused incrementally on each new iteration until there is nothing left to improve (Yeah this method allows you to dream too 😉 )

For each action written in the “Try” section, someone will be designed to be in charge and act upon this action (do research, create a issue, implement a new flow, write a library). It’s also this person who will present his solution / findings on the next session and together the group will decide if the solution provided is actually solving the pain or not. The strong point of this method is to propose a solution for each problem, and that each person can submit their own ideas in order to solve it. Anybody can decide to take the responsibility and give a try on his implementation of the solution. Later the group can review and validate this solution. What’s more the problems are usually a group problem and bringing solution helps the cohesion of the team since their member care about others problems and effectively think solution together. The problems depends on the theme you have chosen for the KPT sessions. There are no actual limits so the problems can cover wide range from technical issues(deploy script is too slow, validation problem) to organizational pain inside the team of in the workflow (too many bugs, bad code review).

In terms of timing, we’re talking short period. The longer I’ve experienced was one hour for an historic project we deploy rarely. Basic sessions should be done in 30 minutes and no more. If you need to keep in tracks you can record the time for each section but YOU MUST NOT SKIP a section!

If nobody finds a “Keep” for instance, you have a deeper problem ! You should spend 10 minutes on each section and never skip one ! Each section has a purpose, “Keep” helps you stay positive and not only see problems in your environments, “Problems” is your room for improvements, as a professional or as a team, and “Try” is your hope to overcome your problems and makes life better for everyone. These 3 steps MUST be gone through during the retrospective.

The goal is not to be exhaustive on the first pass since this method is iterative and incremental, a solution can fix several problems and there is another sprint to focus on the next challenge.

Now the practical part, you can handle the whole process with Post-its put on a whiteboard, or write by hand on the whiteboard. Ideally only one person writes on the board at a given time but this person can change at every session. At the end of the session I strongly recommend you to take a picture of the board and share it in your communication tool in order to keep tracks of evolution and also share with your possible remote colleagues.

And that’s it ! I hope you’ll try this in your team, and I’m waiting for your feedback on this ! I’d love to know your experience with this !

You may also like...

2 Responses

  1. 16/05/2021

    […] Keep/Problem/Try 보드 http://code-artisan.io/retrospective-method-kpt/ […]

  2. 17/08/2021

    […] KPT method (Keep Problem Try) – Historically speaking, this method was made by Toyota for continuous improvement. It’s still very useful and simple enough. It’s a good style for a new team who is new to doing retrospective. BUT as you continue with doing retrospective it can get a little monotonous, so it is good to combine this with Squad health check or any other style. […]