Continuous Improvement Practices — Part #1 — Red Bin
At MeilleursAgents, continuous improvement is at the heart of our Product & Development culture. This article is the first part of a series around continuous improvement practices applied to software engineering.
A slice of theory
Software engineering teams are often familiar with a well known Lean practice: Kanban. It focuses on product development flow.
Yet, there are many other interesting but less known practices that software engineering teams can borrow from Lean Management.
The ‘Red Bin’ is one of them, used by manufacturing companies such as Toyota. ‘Red bins’ are red containers in front of every production line in which operators can put defective parts. On a regular basis, at a given hour, the team gathers around the ‘Red Bin’, analyze defects and suggest quality improvements.
Let’s see how we can implement this within a product development team.
How do we do it at MeilleursAgents?
We don’t actually have red containers around here. Because what we do is immaterial, we decided to stick post-it notes on a wall, with a short description of the problem to be further analyzed.
Every Tuesday, at 10am, the team gathers and analyzes problems one by one. This ritual is animated by someone from the team, Pierre B.
We’ve been experimenting with this for a few months now and learned several interesting things along the way. Below are the 7 most important ones we’d like to share.
#1: Everyone can report problems
The ‘Red Bin’ is definitely not a top down management tool. Everyone is encouraged to share whatever problem they face, could it be a process defect or more basic concerns. Here are a few real-life examples:
- Cowboy deployment without proper code review, leading to a few annoying bugs
- Wifi’s too slow
- Unclear user stories
- Desks too exposed to the sun, making it hard to work because of light reflecting on our laptop screens
#2: Name a ‘Red Bin’ owner
We all have a lot to do and even useful continuous improvement practices can be abandoned in a flash when the team is in a rush. To avoid this, we found that having someone responsible for the ritual animation is essential.
#3: Always reformulate
This one is true for every problem analysis methodology: don’t jump too quickly on a solution. Start off by asking to reformulate the problem and its consequences before suggesting improvements.
#4: Everyone can share solutions
In every group of individuals, some speak louder than others. The key to animating a ‘Red Bin’ ritual is to make sure that everyone can share the solution they have in mind.
#5: Given problem = given owner
For some problems, you will find a solution during the ritual. But, for most of them, you’ll have to run more in-depth analysis, gather data, make a prediction and test it. In these cases, a member of the team must take ownership for the problem resolution.
#6: Pace is key, never skip the ritual
This one is very linked to point #2. In a manufacturing production system, teams often gather to analyze defects several times a day at given times, every shift for example. We don’t feel we have to meet that often but it is mandatory to follow a given pace (once every week for us).
#7: Always improve
This is my favorite story about our ‘Red Bin’ experiment. A few weeks after we started, a team member shared his feedback about it:
It helps but we always talk about problems. What about sharing good things as well?
Well, based on this feedback, we created the counterpart of the ‘Red Bin’, our very own ‘Green Bin’ where everyone can share good things.
We hope this article will help you try Lean principles like the ‘Red Bin’ within your development team. So far, it has had very positive impacts for us: better communication, a deeper sense of ownership of our platform and processes and, of course, many defects durably solved!
Experimenting it is quite trivial since it is an easy to set up, non-time consuming ritual. A real great way to start fostering a continuous improvement culture in your team!