Get certified - Transform your world of work today

Close

Using a Kaizen Board to Boost Your Retrospectives

A kaizen board is a simple yet powerful visual tool to add to your Agile tool kit

26 August 2015

Damián Buonamico
Kleer SRL


kaizen-board-600.jpg

A kaizen board is a simple yet powerful visual tool to add to your Agile tool kit. Based on Agile principles, the tool facilitates effective Agile retrospectives and prevents some of the more common sprint retrospective pathologies.

The retrospective is a critical moment for any Agile team. During the retrospective, the team assesses the current situation and its performance. The assessment is used to change what is not working by adapting the team dynamic to keep the team productive.
 

Retrospective pathologies

Some pathologies or incorrect ways of practicing Agile principles may have an impact on the effectiveness of the retrospective.

Moaning and groaning

In this case, the retrospective is focused on complaints and nagging. Team members assume the role of the victim. The retrospective evolves into a cathartic session or group therapy. There are no concrete actions to solve problems. In some instances, too much time is dedicated to gathering problems, and there is not enough time for discussing actual changes.

Lack of commitment

The retrospective finishes with clear actions. All actions seem promising, but then nothing happens during the next sprint. The team members spend little to zero time on the committed tasks. Sometimes tasks are forgotten after the weekend, or the pressure to focus on the product backlog leaves no priority for other things. In the next retrospective, the same problems are likely to appear. This can frustrate the team and might jeopardize their willingness to keep the retrospective as part of their Agile best practices.


Preventing or fixing the pathologies

Problems exposed during the retrospective can have several root causes. To mitigate the pathologies, follow these simple steps:
  1. Create a template (as illustrated in the figure). Use standard-size paper. For more durability, use hard cardboard instead.
  2. Bring the board to your retrospective and explain the goal of finishing the session with one, two, or three (maximum) well-defined actions to solve or to reduce the detected problems.
  3. Use your preferred method to conduct the retrospective. Team members write the committed actions on index cards, using one card per action or problem. The description should include who, when, and what. If it's not clear, ask how you will know when the committed task is considered complete.
  4. Prioritize the problems and solutions (with the most important first). If you have many, pick the three most important to refine the team's focus.
  5. Paste the index card to the board according to the level of priority.
  6. Use color-coded Post-its to describe the status of each task. You can define the default status as "Not started."
  7. After the retrospective, make sure the kaizen board is visible to the team and is alongside the task board or where the team holds the Daily Scrum.
  8. During the Daily Scrum, the team checks the kaizen board to discuss and update progress, if there are user stories on the task board. Following is a suggested color-coding scheme:
    • Light blue: Not started
    • Yellow: In progress
    • Green: Completed
    • Red: Blocked/Impediment
  9. Bring the kaizen board to the next retrospective. Reserve time to check the final status of each task, and assess how the problem was mitigated or resolved.
  10. Put a system of metrics at the bottom of the kaizen board. For each completed action with a positive result, add a green mark in the Success area. Otherwise, add a red mark in the Fail area. If you're unsure about how to mark the completed action, remember that what matters is the team's perception of the outcome.
  11. On a small Post-it, update the "effective rate" as the amount of accepted features divided by the amount of total actions.
  12. Save this board for future reference. It's a good practice to look back at the progress made over time and appraise how the retrospective contributed to resolving those problems.
  13. Celebrate when you reach a good number of successful actions.


Kaizen board principles

For continuous improvement in quality, apply the following kaizen board principles:
  • Follow the Plan-Do-Check-Act (PDCA) cycle: Identify the problem and root causes, plan and execute one or more actions, and check the current situation.
  • Be action oriented: As an exit criteria for the meeting, require that explicit actions are recorded on the board so that they're completed before the next retrospective.
  • Drive commitment: When team members write actions by hand, it creates a sense of commitment to the project.
  • Apply prioritization and focus: Limiting the number of actions to three allows the team to focus on what is important, while prioritizing makes the teams identify what is most important to complete first.
  • Create visibility: The team problems and committed tasks are exposed to everyone in the team area. Color coding facilitates easy visualization.
  • Follow up: By following the prescribed process, the retrospective closes the feedback loop. The Daily Scrum forces the team to follow up on the status of committed actions.
  • Low-tech, easy to make, use, and adapt for the team: Make use of the Graphic Facilitation technique.
  • Use gamification and metrics: With this technique, we use a metric to determine how are we doing, which helps with motivating the team.
  • Use the power of the Post-its: Marking a task as completed with a Post-it creates an instant feeling of accomplishment.
The kaizen board is just a tool. It does not solve problems by itself; however, it facilitates solving retrospective pathologies when used correctly. It helps to embrace the principles and overcome the retrospectives pathologies.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.7 (3 ratings)

Comments

Robert Day, CSM, 8/26/2015 4:15:51 AM
Interesting post, Damian. I have a colleague who will appreciate "the power of Post-its"! But I wouldn't underestimate the value of catharsis. If there have been a lot of impediments during a Sprint, the team will need the opportunity to let off steam about them in a formal setting.

The art of the Scrum Master is in not letting the gripe session get out of hand, but instead embracing it and harnessing that energy into productive channels:

How can we get around those problems?
Is there anything I can do, as Scrum Master, to address those issues with the business/ (i.e. everyone else outside the team)
What learning issues can we identify from these?

I would suggest that accepting that there will be times when there are issues that result in gripes, learning from them and accommodating or addressing them is a part of the flexibility and adaptiveness that Scrum is all about. And addressing issues will give positive feedback to the team that they are being listened to and their concerns are being addressed. Just ignoring issues with the aim of maximising positivity might not make them go away and then the team will suffer.
Damián Buonamico, CSD,CSM,CSPO,REP, 8/26/2015 9:11:20 AM
Thank You Robert ! In my opinion Catharsis it's ok only when happens once in a while. The problem with Catharsis is that leaves the team in a position of victim, where it's easy to complain but hard to take ownership on the situation and fix the problems, because the problem seems to be outside the scope of the team. From the role of protagonist there is always something that can be done to fight the problems.

As a Scrum Master, also take care of not putting on yourself all the problems the team had and complain about. Is the team who should take action, so they can learn the process of fixing the problems and improving by themselves. A scrum master fixing all the problems for the team will be always a bottleneck, create dependency on the Scrum Master and prevent learning in the team.
Robert Day, CSM, 8/27/2015 8:28:02 AM
Yes, Damian, the Scrum Master can't fix all the team's problems; but the ones they should address are those from outside the team - pressures from the business, conflicting messages coming in and so on. The Scrum Guide (http://www.scrumalliance.org/why-scrum/scrum-guide#sthash.FlTTSnZN.dpuf) puts it rather more diplomatically:

"The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t."

I suppose in my experience, impediments from outside the team are the things that have caused the most issues with projects I've worked on!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe