Kaizen on team level

For several months I’ve been trying to convince management to introduce some innovations in order our product to be more stable, better performing and of higher quality. Among those ideas the two most important are already introduced and well functioning at several software companies of huge size. Namely, those are Kaizen and FedEx days (more on those a little bit later).

I don’t think I wasn’t persistent enough. I was trying on several levels. I went to innovation days, used idea boxes, had face to face conversations and so on. The result was always the same. The answer –in each and every case- was, “Wow, these are great ideas, we can really profit from these things. We’re definitely going to try these things out. Thanks for pointing it out”. Unfortunately, for some reasons the implementation of the ideas never took place. Too bad, there’s a lot of nice things about them.

Kaizen is a technique of continuous improvement. In its simplest form, it only needs a whiteboard, some kaizen cards with improvement ideas and some creativity from the team’s side. An idea can be process or technology related. The point in this way of collecting ideas is the infamous (mainly retrospective-related) phrase of “Gosh, I had a great idea, but I can’t recall it”. The idea behind kaizen is something like: any idea is worth discussing, none is worth forgetting. You get an idea, just write it down and put it on the board, so everyone can see it/think about it.

FedEx days are special working days, when no one is allowed to do their normal, every-day work. Instead, everyone is required to work on a kind of own project, with the only restriction that it has to make either the process or the product better. See how things connect? Those ideas collected on the Kaizen board can be developed/introduced during FedEx days. In order to get the best results, these occasions have to be organized regularly (bi-weekly or monthly).

My current team is a newly set-up one. Some people are having hard times understanding the basics of different agile methodologies. At the beginning there were no clear rules, we had a hectic whiteboard and several severe arguments. There was no way of introducing any improvement. The first thing was to do Kanban, with all its principles, practices, board-design stuff and so on. This took some time (and it still goes on. Some people just don’t want to get why Kanban rules are better than chaos. Even if they see data-based results. More on that in an upcoming post).

As Kanban was more or less in place and management was still ignoring the concept of kaizen, I decided to introduce it on team level. The idea was simple: I “designed” a kaizen note template, simple as hell: a table with two rows: idea and benefits:

One day I added a new Improvements section to the Kanban board and made the empty kaizen notes available. And guess what; it turns out that people actually HAVE improvement ideas. And they are keen to share them. This is how the board looked like before the first session of discussing the improvements:

Ideas are discussed; after reading the kaizen note’s text, the author is given the opportunity to clarify any unclear aspects about the idea. After a short debate where everyone can tell their thoughts, a simple majority voting is held. If an idea is passed, it becomes a new team principle. Rejected ideas become buried forever.


Ideas can be real simple and straightforward things. Things like “I think we should implement different classes of services. Benefits: better and faster work”. Improvements should not be thought of as world-saving things. Simple tiny steps can lead to better achievements.


A current state of the whiteboard:

As per now, I can say Kaizen works just fain on team level. Maybe as the project advances (as we’re working on a new,greenfieldproject) we can introduce FedEx days on team level as well. So we could tell managers “see, that’s why we should have it on organizational level”.