To improve slightly every day. Wouldn’t that be great? At Easy LMS, we are all followers of the Kaizen method. This Japanese productivity method helps us tackle time wastage, to make work nicer and lighter. Its key aspect is continuous improvement.
Major improvement processes. We have tried, believe me, but never with the desired effect. They came to a halt, as we could not choose from all the possible improvements, and we lost ourselves in the daily issues. There was always a client question that came up in between, that was more urgent than setting up an entire process.
Since we really like to improve, we have gone for the Kaizen method. After reading the book Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother, we were convinced of its effectiveness. After all, Kaizen does not focus on the fact that everything should be perfect all at once, but on taking small steps every day. The small steps are indeed very small steps. In total, these steps will take you far. Ultimately, you also run a marathon step-by-step.
The literal translation of Kaizen is "change for the better".
Overview of the Kaizen methods at Easy LMS
Kaizen has a wide range of methods and processes, both large and small, to realize improvements. Kaizen at Easy LMS is based on the following parts:
- Determine direction by using target conditions.
- Small continuous improvements.
- Root cause analysis: asking why five times.
- Knowledge is power.
- Kaizen is everyone’s responsibility.
Let’s focus on parts two to five, illustrated with an example of how we execute Kaizen. Part one needs a whole article to explain 😊.
Part 2: Small continuous improvements
Some improvements seem to be too small and precisely then it is important to make them.
How small is small? In our case, very small. Learning shortcuts, or even moving a printer to a more convenient location, is an improvement. Making small improvements is therefore perhaps the most difficult step. Some improvements seem to be too futile, too small, or to have too little impact. Therefore you often don’t make them, and precisely then it is important to make them. The other danger is that the longer you wait, the bigger the problem becomes, which means you have to put it in the planning, with all the associated dangers. You can start immediately with making small improvements. Even without approval from management. Each step forward generates profit.
We realized that when we took a closer look at our release cycle. In the past, we created new functionality or solved bugs online ("releasing") once every few weeks. Now we do this at least twice a week, and very soon it'll be every time we have completed something.
The path to this consists of dozens of small (mini) steps. We’d like to highlight four:
- We first test everything before it goes live. To test a release, developers initially had to make this available in our test environment. Developers would sometimes forget this, or were sick. After all, we are only human 😉. This gave us plenty of reason to ensure that our tester, Caroline, can put the release in the test environment herself.
- Automatic generation of a release takes 45 minutes, which is a rather long time to wait. Because this takes so long, we now do this at set times: Monday and Thursday morning at 6:00 am. When Caroline arrives, she can start immediately. But first, of course, a cup of coffee 😉.
- Initially a developer was also required to put a release live in the live environment. That is no longer the case. Caroline now does this herself. Putting it live is only possible if everything has been approved.
- We always conduct acceptance tests and that takes a lot of time. Especially if there are 25, as is the case with us. Therefore, we started to automate these tests one-by-one. The first test saved us a bit of time. They are now all automated and this saves us 12 hours a week.
Part 3: Root cause analysis, asking why five times
When you use Kaizen, you don’t just patch things up.
When you use Kaizen, you don’t just patch things up. You tackle the root cause of a problem, so you only have to solve it once. Ever so efficient. You can find the root cause of the problem by asking "why" five times.
Each time we don’t meet a certain target, we perform a root cause analysis. This gives us a limit of three user stories that may be under development. We have determined this together. This forces us to complete stories in order of priority. If someone picks up a fourth story, we stop the work and we start to analyze.
Recently, we had to put something live while three stories were already being developed. Putting something live, means story number four. We came to the following analysis:
- Why have we opened a new story?
We must do a release and the release requires a story that states what must be done.
- Why do we need this story?
We will put several new, requested functionalities live.
- Why will we put several functionalities live?
We never put just one functionality live.
- Why don’t we do this?
Creating a release takes too much time. The costs outweigh the benefits.
- Why does it take so much time?
Testing is the bottleneck.
- Why is testing the bottleneck?
The automated tests are not reliable enough, so there is a lot of manual testing.
- Why are the automated tests unreliable?
Because we use an older framework in which we run tests.
There are multiple solutions at various levels to solve this problem. Together we decide what the best solution is for the moment. The solution for this root cause is to update the framework for running the tests.
Part 4: Knowledge is power
How will you know if a change has been successful? Knowledge is power. Create a baseline, and then measure it again after the adjustment. We try to make as many things measurable as possible, but sometimes it is also a gut feeling that something can be done faster or better. Again, we are only human.
A process that we have made fully measurable is that of a user story. Before a story can go live, it goes through a whole series of steps. How long did these steps take? We had no idea until we started to measure the time. Then it was immediately clear where the bottleneck was: it took too long before Caroline could test. We conducted a root cause analysis and immediately implemented an improvement based on this. Another improvement that emerged: the process for managing the translations. But that is something for another article.
Part 5: Kaizen is everyone’s responsibility
Kaizen only works if everyone in the company contributes to it by taking responsibility and giving time and attention to it. At Easy LMS, everyone is given the space to come up with improvements and the time to spend on them. Because we know we will benefit in the long term.
Now that you have read this article, would you like to take a step on the road to Kaizen?