This is the third and final article in a series of three about how we practised with lean principles. We established in our first article that we needed to find a form or shape in which we became able to address tensions that concern a chain of roles and circles.

Introducing Kaizen as a process model

While Bouke shared his observations, we also started conversations throughout the organization to increase awareness about potential for improvement. Colleagues were often unaware that they could contribute to solutions for tensions other roles were struggling with to resolve.

To streamline the process Bouke introduced the Kaizen circle (DMAIC). The Kaizen circle is a process model from Lean that entails an emphasis on problem analysis. It has many resemblances with other process models such as:

• Double Diamond Framework
• Design Thinking Circle
• Human centered design process (HCD)
• The Lean Startup Model (BML)
• Agile lifecycle
• Plan, do, check, act (PDCA)

Make the process work for you

I personally feel the double diamond framework (Nessler 2018) is the most detailed to go by, although one should keep in mind to keep it simple. After all, these processes are merely there to give structure and keep everyone on the same page. You don’t want to exhaust colleagues with intricate complexities. Plan, do, check, act is the most simple representation. 

Having a process and understanding it, is important for teams. We have learned that it is better to apply the process and let the team gain experience than to give lengthy explanations about these models. We are a quirky organization that likes to adjust processes to our needs as we see fit anyway. I believe that is a healthy attitude towards any process, framework or method. It can be challenging, but anything can be tailor made to make it work for your organization as long as you approach it with a flexible mindset.

It is important to make small improvements until it is good (enough). Often when processes do not immediately work the way you’d like them to, people tend to just stop the process altogether. It is better to make an improvement effort, reap the benefits of what is already there, and address the specific downsides of something that doesn’t work for you (yet).

Every now and then I had this murmuring feeling of being slightly annoyed with Lean. I sometimes feel the Lean community utilizes obscure and unique vocabulary while common language is available. That vocabulary is making it sound more complex and interesting then needed. Don’t let that put you off, the bottom line is that Lean teaches methods that get you to continuously improve. And getting 1% better each day is something that we care about.

Learn fast and adjust quickly

The Kaizen process model has five stages to go through (Define, Measure, Analyze, Improve, Control). Although there are no rules set in stone, running through the process is supposed to go in a quick repetitive rhythm. The kaizen circle builds on the same paradigma’s as for example the “Build, Measure, Learn” cycle. It encourages people to learn fast and adjust quickly. Quick and small iterations enable fast learnings. It takes time and practise to get into that rhythm. It is relatively easy to increase the size and complexity of a problem. It’s much harder to narrow it down in smaller chunks. 

I refer to a short video (90 sec) to explain the five stages of Kaizen. 

Improving quality assurance

At one point we had three simultaneous Kaizens running. The enthusiasm of the Webapp team was rubbing off and more teams wanted to get involved. One of the topics that sparked interest within the Webapp team was the amount of issues deployed to our production environment. Everytime an issue is deployed to production our customers could potentially experience issues with our services. In the first half year of 2020 a total of 88 hotfixes had to be made by the Webapp team. That means there is a problem to be resolved every two days, requiring additional deployments and testing.

Initially the overall belief was that the blackbox tester should become more proficient in preventing these issues. Blackbox testing is the last process step before deploying the software to production. At the time the blackbox tester was quite stretched for capacity and felt frustrated with the lack of support. It appeared that colleagues were unaware of the actual activities performed by the blackbox tester. Neither were they conscious of the impact that their own processes had on the effectiveness of the blackbox tester. 

After applying a more holistic approach, many conversations, and going through a root cause analysis, colleagues realized that they had a part in bringing about improvement. It became clear that the initial expectations for the blackbox tester were unrealistic and better collaboration and improvement was needed.

Considerable thought was given to which roles are involved in the quality assurance process, and who should participate in an attempt at improvement. There are a few principles (do’s and don’ts) to follow when starting an improvement initiative like this.

Kaizen principles

Do’s

• Do not worry about being perfect – even if you get halfway – start now
• Get rid of old assumptions and knee-jerking reactions
• Look for wisdom from the team rather than one individual
• Include all the colleagues that are involved in the process
• Make sure the team understands the problem and is committed to resolve it
• Continue to ask questions till root causes of problems are established

• Be open minded to all ideas, solutions, brainwaves and approaches
• Immerse yourself in the actual situation and observe for good understanding.
• Limit the scope and set achievable goals
• Find ways to make it happen, don’t stop half-way

Don’ts

• Ignore the do’s

A closer look at your processes

During the “measure the facts” stage the team decided to take a closer look at the overall process that was followed. Bouke introduced the SIPOC diagram to the team as a way to answer important questions such as: 

• What are the essential steps within the process?
• What are the main inputs and outputs?
• Who are the key customers (internal and external)?
• Who are the key suppliers (internal and external)?
• What are the customer demands?

Asking these questions and answering them encouraged team members to cooperate and communicate. This drastically improved understanding of expectations and goals; what is the internal customer expecting and what does the supplier handover? Instead of trying to improve an individual circle, the team started to improve an overarching process involving a chain of circles and roles.

The quality assurance process was radically revised with the creation of a new circle, the capacity for testing was increased, the team started to measure the facts, tracked the amount of hotfixes, measured the severity of each hotfix, and analysed the root cause. 

Often this led to the conclusions; “Missed during development” or “Missed during QA (staging)”. In the latter case the team also started to ask: Could the blackbox tester have picked this up or not. This led to the conclusion; we (webapp devs) need to test more and better ourselves!

A huge success

As a result of the improvements and the increased awareness we have seen a significant decrease in hotfixes. In the second half of 2020 the webapp team had to do 26 hotfixes. An improvement of 70% compared to the first half of 2020. The result:

• Happier colleagues
• Less time lost on additional deployments, tests, and fixes
• And a more reliable experience for customers

Waste walks

One of the tools in the Lean toolbox is the waste walk. The methodology describes 8 categories of waste. These categories are helpful to give direction into where one would typically find waste. 

Every marriage has its struggles

In our first article we use the metaphor of a happy marriage between holacracy and Lean. One must admit that even in the best marriages struggles occur. A continuous effort to make it work is required. Success never presents itself in a linear motion.