How do I introduce kaizen to IT?

Dear Gemba Coach,

Based on your experience, what is the best strategy to introduce kaizen as social, ongoing events without start and end dates in a service industry, specifically IT services?

Excellent question: once you’ve clicked to the fact that there is more to creating a kaizen culture than a blitz of rapid improvement events, what do you do? The answer lies in understanding the on-going and social nature of the activities you want to set up.

I was recently on the gemba of a fast growing IT start-up asking me how to move from “agile” practices, to lean thinking. This gave me pause, because agile understands very well both elements, the social and the on-going, and responds with smart get-together rituals on how to get things done together:

• Scoping the project
• Organizing the team
• Clarifying roles

The agile trick is to break down a project into chunk-able tasks, write them on post-its, place them on a board showing, essentially, pending, current, finished, and the backlog, and discusses daily how to move tasks along and remove blockages.

This is a radical departure from traditional project planning because it’s based on (1) an on-going re-prioritizing of what needs to be done to ship (as well as listening to customer responses) and (2) a daily social interaction of how to get things done.

Is this good? Yes, absolutely. Is this lean? Not quite.

Space to Think

Lean’s basic assumption is that people make products, not the process. Great products or services, we believe, are made by people who (1) know work standards inside out, (2) work well with each other according to a level load plan, and (3) think of ways to improve both what they do and how the team works together.

The foundation skill is problem solving, not as a way to get problems solved, but as a training technique to deepen people’s understanding of their own standards, and their colleagues’ problems in order to see how the technical process helps or hinders to deliver customer satisfaction – and profitability. In plain terms, we’re assuming people know what they do, but we look for the key misconceptions that generate unnecessary waste.

Rather than make “tasks” move forward, lean is more about creating space to think so that employees deepen their understanding of:

1. How do customers really use our service, and how do we help them make money (or get whatever they want to get done, done)?
2. How well do we understand our work standards? Why do we still have rework? What are we not getting?
3. How smartly do we work together to get things done and not get in each others’ way? Do we understand takt time? How can we improve our work methods?
4. More fundamentally, how does our technical process impact our service? Should we look at other technologies to do things better?

The latter point is core, core lean thinking. A recent excellent example of this can be found in Jim Morgan’s great post: https://www.lean.org/LeanPost/Posting.cfm?LeanPostId=541

If you look at his two cases, you’ll see how Toyota has radically rethought its technical processes in order to improve the quality, environmental impact or cost of its final product. This is the lean ambition: work from employees’ ideas to process rethink, to better services and products. To achieve this ambition, everyone in the line needs to understand exactly what we’re after – which is not simply get things done faster or more flexibly.

How can we get started with this?

First, establish a routine to look at customer complaints – say weekly. On a wall, start listing all customer feedback as:

1. What the customer is unhappy or unsure about – in their terms, and wonder why this affects them enough to try tell us about it?
2. How did we create this situation? Which part of our normal process (no blame, guys!) led to this?
3. What can we do to pacify the customer? How do we show them we hear and understand? How do we respond? How do we regain trust?
4. Did it work? Is the customer happy with our response? (Think of all the times, as a customer, when you complain, the company adds insult to injury in the way they try to make it up to you).

This exercise will bring the team together in listening harder to what the customer is actually sensitive to. They bothered to complain (as opposed to just move on), which means they’re motivated enough to try and educate you on what matters to them. The next step is to build a model of our understanding of value for the customer (say, a radar chart of what matters to them) and see if this complaint fits what we think we know about customers, or whether we need to think again. Deep stuff.

Rework Is Interesting

Second, we will have a daily routine to look at all rework. Rework is not bad per se, and it is sometimes necessary. No one finds it surprising that when writing a book, some rewrite is necessary to make the book better – still rewrites are rework. Rework simply means you didn’t get it right the first time, for whatever reason. It could be:

• A silly mistake with a large impact – okay, let’s not do this again.
• A misunderstanding of one part of the work – this needs looking into and clarifying the standards, or how standards apply in specific conditions.
• A deeper misconception about the purpose of the work itself – we’re just missing something big and must take a deep breath, stop and rethink.

In the book example, some rewriting is due to typos, some due to unclear language (we know what we mean to say, but don’t know how to say it clearly) and some is due to simply a bad concept, and needs a complete rewrite.

Rework is always interesting, and we’ll take a few minutes every day to discuss one rework that occurred in the previous period. We don’t look at all the instances, just one a day for up to 10 minutes, in order to get our minds around it. To do so we set up a whiteboard looking like this:

• Date: to check it’s done once a day.
• Problem: what process gap created what performance gap?
• Cause: which standard did we ignore? Didn’t apply? Was incorrect? Simply didn’t exit?
• Countermeasure: how do we intend to fix this?
• Check: has the fix worked? When do we check later if the fix holds?

This board is the focus of problem-based learning. By visualizing how we solve our own problems (the discussion must be held on a fully solved problem, all the way to check), we can challenge our experience and look more deeply in how well we understand our work as well as work with our upstream and downstream colleagues.

The board is not about solving problems – this every body does daily in the course of their work – but about a daily lesson about both (1) problem solving as a skill and (2) understanding work standards. This is where we go in-depth in the tasks and not keep them at post-it level.

6 Step Method

The third routine you want to get started is indeed, the kaizen event you mentioned. This is different again. Error correction, as done with the rework problem solving board is necessary but not enough to make great service, or indeed to motivate the team. We also want to encourage new ideas and initiatives. We want the team to look at its own work methods and, together, come up with new ideas and better ways of doing things. The best framework I’ve come across is Art Smalley and Isao Kato’s six step kaizen method:

1. Discover Improvement Potential
2. Analyze the Current Methods
3. Generate Original Ideas
4. Develop an Implementation Plan
5. Implement the Plan
6. Evaluate the New Method

You can do this as a kaizen event, by getting the team to work exclusively on one issue for a day or two, or as a “quality circle,” setting aside a couple of hours per week. The important thing is that, at any time, your team is working on one improvement at a time.

Finally, we’re all so busy with work that it’s hard to find time to continue to explore new technologies or alternatives to the way we work. This, ideally, should be part of every one’s job, but hard to fit in. The simplest way to do this in IT is to ask each developer to come up with their own self-development plan.

At team level, you then set up a “university”, say a monthly one-hour meeting in which members of the team present their findings (in A3 form to make it easier to share) – one per month. If the team has six members, they have six months to complete their self-development project and present to the rest of the team.

Such self-development projects are essential to keep the team open to what is going on outside and consider new technologies as well as work with the ones we know. Mostly this is also about building partnerships with the people who use or develop these new techs, to broaden the scope of our capabilities.

Clearly, I don’t believe there is any way to sum up lean thinking and practice in a few routines or techniques, but I feel confident that these four routines would get you started on the path of deeper thinking about what customers are looking for, how you work and how to engage people in having improvement ideas and initiatives. This is nothing more than the first step, but sometimes, the first step is all it takes to get started on the thousand-mile journey.