Kaizen: With Marginal Gains to Long-Term Improvements
How a team of engineers embraced continuous improvement.
I think there will always be challenges in software development. Challenges that affect collaboration, the quality of the software, the enjoyment people get from working on the software, and more. Challenges that are so important that the people facing them want solutions.
They want to improve.
In this article, I will show you how one engineering team embraced the desire to improve by making it a well-functioning gear in their process machine.
About Kaizen and Marginal Gains
The word ‘Kaizen’ is Japanese and can be translated as ‘improvement’ or ‘change for better’. The concept refers to a continuous improvement approach.1
Another concept that fits well with Kaizen is Marginal Gains2. The idea of making many small, low-effort improvements that add up to big improvements over time.
Our Interpretation
We interpreted these two concepts this way:
Anyone can make suggestions at any time, describing the problem and how to solve it.
The proposed changes should be easy to implement and have a little impact on the way we currently work.
We prefer experimentation with these suggestions rather than to long discussions of what-if scenarios and analysis. Experience beats theory.
Proposals are discussed in a Kaizen meeting once per sprint.
The Kaizen meeting is where we discuss proposals that the majority of the team feel are important to discuss.
We agree to experiment with a change if the majority of the team is in favour.
By following these guidelines, we have seen the following benefits:
We focus on real problems experienced by real people in our team that are holding us back.
Proposals can be discussed and further refined before the actual Kaizen meeting.
Other team members can make additional proposals for solving a problem.
A better understanding of what other roles in our team are struggling with, how they work and sharing of knowledge.
Changes can be seen as experiments and easily reversed if they fail to prove their worth.
Changes have little impact on our daily work. We can maintain our productivity as we adapt to these changes.
Let's take a look at what this looks like in practice.
One Gain by Example: Automated Test Setups
Preparation
Several times a day I would download the latest build of our product and manually install it before I started testing. A process that was boring, error-prone and for some setups time-consuming. So, I wanted to change this and came up with the following proposal.
Problem Statement
Our product is highly complex and highly configurable.
Our developers make several new builds every day, and we test several features on those builds every day.
Setting up our product manually several times a day is boring and, for some features, error-prone and time-consuming.
Proposal
In two days, I built a tool that automates the setup for several different use cases, including complex ones.
It saves 5 to 15 minutes per setup, depending on the use case.
The tool works out of the box.
The tool provides a starting point that can be used to further refine the setup.
Do we want to use, own and maintain this tool?
Discussions
After I have created the proposal in our task management software, everyone in the team receives an email. This gives everyone the opportunity to read the proposal before the actual meeting, and to provide input and ask me questions about it.
Some people asked me about the tech stack behind the tool. Others wanted to better understand how I, as a tester, set up my test environment compared to them, as developers.
These discussions helped me to understand what information I should include in my presentation at the Kaizen meeting.
The Kaizen Meeting
On a Tuesday afternoon, we gathered in the attic of our office building and began our one-hour Kaizen meeting. Everyone had previously voted on the proposals they felt were most important at the time.
We usually go through the unfinished proposals from the previous meeting. We then go through the open proposals in the order in which they were voted on.
During the meeting we came to my proposal.
Presentation and Discussion
I presented my problem statement, my proposed solution to improve the situation and demonstrated the tool that I had built.
After the presentation, the team had the opportunity to ask questions and share their thoughts on the proposal. We realised that this tool would not only help testers, but also developers and product owners. We also decided that if this proposal was accepted, we would need a proper documentation on how to use it.
The presentation and the discussion are time-boxed. If a discussion takes longer than ten minutes, we would do two things:
Vote on whether the proposal is worth continuing to work on.
Define a group of people to discuss and refine the proposal for the next Kaizen meeting.
Getting the whole team together for an hour was expensive. It was important for us to have decided on actual improvements in the kaizen meetings, rather than just talking about them. We wanted to make the most of that time.
My proposed change was ready to be voted on.
Vote and Actions
We then took a vote. The majority of those who voted agreed with the change. The proposal was accepted.
Everyone was free not to vote.
We then wrote down the actions needed to implement the change. One of these was the missing documentation for the tool.
Context
Every team and organisation is different. This approach may or may not work for you. So here is more context:
The team consisted of about 15 people.
The people in the team had a sense of ownership and responsibility for the product they were building.
The team was self-organised.
These people were passionate about their work.
Decisions were mostly made based on the basis of arguments and data. Not on role, experience or hierarchy.
There was a high level of transparency in the team.
The people were open to change and learning.
Using this approach, the team implemented hundreds of improvements over several years. Improvements that addressed problems in all areas of the development process: Coding, testing, quality, documentation, knowledge management, self-organisation, collaboration and more. Improvements that did not slow them down or require (big) reorganisation.
It was a real continuous improvement process that actually worked and made a big difference. Wonderful.
Happy improving,
Florian
James Clear, “This Coach Improved Every Tiny Thing by 1 Percent and Here’s What Happened“, James Clear