Kaizen

Only after American carmakers had exhausted every other explanation for Toyota's success - an undervalued yen, a docile workforce, Japanese culture, superior automation - were they finally able to admit that Toyota's real advantage was its ability to harness the intellect of 'ordinary' employees.", "Management Innovation" by Gary Hamel, Harvard Business Review, February, 2006

Taiichi Ohno (February 29, 1912 - May 28, 1990) is considered to be the father of the Toyota Production System, also known as Lean Manufacturing.

When I attended Mary Poppendieck's presentation on The Role of Leadership in Software Development at Agile 2007 she talked a lot about Ohno and had a marvelous quote from his book Workplace Management.

There is something called standard work, but standards should be changed constantly. If you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen [change for the better]. Standards are set arbitrarily by humans, so how can they not change? You should not create these away from the job. See what is happening on the gemba [workplace] and write it down.

When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve 'the best way.' This is a big mistake. Document exactly what you are doing now. If you make it better than it is now, it is kaizen. If not, and you establish the best possible way, the motivation for kaizen will be gone.

One way of motivating people to do kaizen is to create a poor standard. But don't make it too bad. Without some standard, you can't say 'We made it better' because there is nothing to compare it to, so you must create a standard for comparison.

We need to use the words 'you made' as in 'follow the decisions you made.' When we say 'they were made' people feel like it was forced upon them. When a decision is made, we need to ask who made the decision. Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

But in the beginning, you must perform the Standard Work, and as you do, you should find things you don't like, and you will think of one kaizen idea after another. Then you should implement these ideas right away, and make this the new standard.

Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, 'The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.' I said 'What do you come to work to do each day? If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.'

At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying 'Have you been goofing off all month?' If it takes one or two months to create these documents, this is nonsense.

I found this very profound. I saw ghosts of many failed and failing projects pass before my very eyes. First with Rational and then Number Six I've been lucky enough to work with some great people with a passion for change. They find it hard when customers do not embrace improvement so readily. I don't think they set expectations that cannot be met but, they are perhaps naive to assume they will be met immediately.

Maybe it's time to consign to the scrap heap that silly phrase "set the bar high". After all, a high jumper may have lofty ambitions but, they do not set the bar high, a high jumper sets the bar low and then gradually increases the height as they become more comfortable.

Maybe we can draw some inspiration from Taiichi Ohno:

• Set realistic goals for improvement, goals that can be achieved in the short term
• Continuously challenge and improve processes
• Define processes at the workplace not in the laboratory
• Remember that people are much more likely to follow through on a commitment they made than one that was forced upon them

A Process Definition Is Not a Process

It hit the desk with a thud. "What's that?" "Oh, that's the Risk Management Plan." "Great, let's see the Risk List?" "Oh, we didn't bring that, it's on Tony's laptop somewhere."

This was a real conversation. We were meeting with some of the staff in the PMO and they had brought their Risk Management Plan for review. It was an impressive document with 65 pages of everything you ever needed to know about risk management. This was the culmination of weeks and weeks of effort and many meetings. The sad thing is that in the time they had spent documenting the process they could have collected, analyzed and responded to all the program's risks and been in a much better position to ensure program success.

You don't need to spend weeks and weeks defining a risk management process, it has already been documented to the finest level of detail and there's not a lot of options to ponder. Likewise, you don't need to spend hundreds of thousands of dollars to be told that you need a change control board (sadly another true story).

As real process engineers will tell you, a process definition is not a process. Instead of spending months and months documenting processes it is far more effective to reference existing documentation. Keep the process simple and transparent so that it can be easily implemented and iterate often in the early stages to right size the process to fit the team. Remember a process definition is not read but referenced, so make sure it is small, online and referenceable.

Drivers Never Get Car Sick

I recall one day sitting in a meeting when our project's sponsor, very proud that our team had just delivered a release on-time and under budget gave a very passionate speech to our team about how proud she was to have worked alongside us and how we had triumphed over adversity. It was very touching and heartfelt but she lost my vote when she stated that process cannot be allowed to stand in the way of innovation.

I agree in spirit but why is process perceived as counter productive and stifling. The main benefits of process are not control but rather ensuring best practices are repeated and people understand the direction the project is going to take.

Did you ever notice how drivers never get car sick? The reason is of course that they know where the car is going. On this particular project we had a lot of very sick passengers. As a driver of a car you can take some steps to avoid your passengers getting sick:

1. make sure they know where the car is going
2. keep them talking and involved with others
3. make sure they keep focused on the road ahead
4. keep them involved in tactical decisions such as speed and direction.

Applying that analogy to our project drivers can keep their team productive, engaged and healthy by following a few simple steps:

1. create a simple roadmap to ensure everyone knows the direction and there are no unexpected changes in direction
2. continuously talk to the team and communicate progress
3. make sure the team does not lose sight of the end goal
4. ensure that the team has visibility and input into project direction.
   

Lastly, don't let stubborn pride get in the way, if you're lost, stop and ask for directions.