Mar
13

Lean: it’s all about respect for people

A great post over on Evolving Excellence: It’s all about respect for people.

Lean without respect for people is LAME (Lean As Mistakenly Executed), a surefire way to fail. You can eliminate waste all you want, but without respect it isn’t worth anything. I’ve seen some “Lean” initiatives without this respect for customers, employees or partners. They were all abandoned quickly. This lean lame stuff doesn’t work!

In the story, the departments are asked to find ways to reduce accidents, not to reduce costs. Reducing insurance costs isn’t a very exciting goal. Reducing accidents, making life safer for your coworkers, is a worthwhile goal.

What are the goals of your project? Are they worthwhile? Are they exciting? If not, why are you pursuing those goals?

Are you Lean or Lame?

Respect. Another way to know you’re really lean/agile.

Jan
04

Toyota Talent

Toyota Talent

Developing your people the Toyota Way

Yup, another book about the Toyota Way. Gotta feed that habit!

One of the “Toyota Way” principles is to Develop Exceptional People. Well, doesn’t every company do that? Not in my experience. Many are caught in the “No time” vicious cycle. People are firefighting, so they have no time for (effective) training. Because of that, any training they get is ineffective. So their work is ineffective. They have to fight fires. And so on…

There must be a better way. Jeffrey Liker and David Meier delve deeper into the development of exceptional people principle.

Origins

Many of the training methods Toyota uses today are based on “Training Withing Industry” (TWI), a program started up in the USA during World War II. To keep wartime production running with all young men off to war, the USA needed to train a lot of people very well in a very short time. The program was focused on “immediately increasing production for defense, then for war“, but “The training we give the worker to do a good job… can be more than an expedient means of getting the job done. It can be suitable to the individual and in line with native talent and aspiration. Then it becomes education because the worker placed in the line of work he desires, and trained in accordance with his talent and aspirations, is a growing individual…” [preface to the Training Within Industry Report 1940-1945]

After the war, the need wasn’t so pressing any more, so the program was abandoned. TWI was exported to Japan during the post-war reconstruction. So how does Toyota apply TWI?

1. Prepare the organization

You start by defining the organizational needs and objectives. Ask around in your company “Why do we train people? Why do we want to develop the talents of our people?” Make sure that you get measurable objectives: reduce incidents, increase throughput, increase quality… Go to the source (Genchi Genbutsu) to assess the real needs.

Determine how many trainers you need and how the the trainers map to the organizational structure. The book recommends one qualified trainer per 10 employees. In the Toyota Way, these are “workplace trainers”, people who do the work, but are also trained as trainer. Each leader is first and foremost a trainer. Being an effective trainer is not easy. The book contains a list of talents to recruit, select and train trainers.

Training is planned as a long-term commitment. there is an organizational development plan and each employee has a personal development plan. Of course, the status of the training is always visible in a “multifunction worker training table”: a sheet where the team members and their skills are listed. This allows us to see at a glance that the team has a good balance of skills and that each skill is mastered by multiple workers.

2. Identify critical knowledge

First, analyze the work from a high level. One analysis technique looks at task variety (is the content of the work always changing?) vs task analyzability (can the job be broken down into simple steps?). This results in 4 categories of work: Routine, Technician, Craft and Nonroutine. Most jobs contain a mixture of the four. Training techniques are adapted to each type of work. For example: Routine job training is heavily based on standard work and training the job steps until they become “motor memory” and the worker can concentrate on problem recognition, response and solving. Craft job training is based on generic procedures, fundamental skills and guidelines.

For each job, the detailed skills requirements are determined. The skills are broken down into simple tasks. This is heavily dependent on the presence of “Standardized Work” procedures. Standardized work and Job Instruction are two lean practices that reinforce each other. The tasks are analyzed in detail; the critical points and their reasons are highlighted. The job breakdown is documented in training sheets.

3. Transfer knowledge

All the material has been prepared. The trainer now prepares for the instruction itself. One of the main points of the book is preparation, preparation, preparation!

At the start of the training session, the student is prepared: the student is made at ease, the goal of the session is explained. The teacher verifies the current knowledge of the student and gets the student interested in the job.

At first, the teacher presents the operation: major steps are explained, key points are emphasized. The teacher performs the job a second time, now explaining the reasons for the key points. After the demonstrations, the student performs the job. The trainer observes and gives instant feedback. When the student gets proficient at the job, they have to explain the major steps, then the key points, then the reasons, while they’re performing the tasks. Another key point is repetition, repetition, repetition.

The teacher assesses whether the student can 1. perform the job in the standard way and 2. understands why the job is performed this way. When the teacher thinks the student is able, the student performs the real job, at first under supervision.

4. Verify learning and ensure success

Students transition gradually from training to being self-reliant. The teacher monitors regularly. As workplace leaders are often also the teachers, they can offer on the job mentoring. The following tips help the student become self-reliant:

  • The trainer is always responsible for the capability of the student. “If the student hasn’t learned, the teacher hasn’t taught“.
  • Always support the student
  • Explain who to call for help. Asking for help a basic skill that anyone should master.
  • Check progress frequently
  • Encourage questions
  • Gradually reduce coaching and follow-up. Don’t throw the student in at the deep end, to swim or sink.
  • Use the cascade audit method to ensure success of the process. Do you achieve the goals (and sub-goals) you set? If not, adjust the training. This closes the positive feedback loop of learning.

It’s not easy

All of this takes sustained effort. Each leader must see it as their first responsibility to develop their people. The whole process must be ingrained in the company. Really developing people takes time; it takes years before new engineers are really up to speed and can take responsibility for important subsystems. It’s easy to undo all this hard work if your employees leave or if they get moved willy-nilly to unrelated teams (as happens in strictly project-based organisations).

The book contains many examples and tools. Most of the examples are from manufacturing, but there are also plenty of examples from engineering and nursing.

There are many useful techniques that I use when creating training or conference sessions. These are essential skills for any leader. How do I know if I lead well? When the product gets better AND the team gets better.

Dec
10

Mind reading for beginners

Planning the next release

A while ago I was responsible for the implementation of the “B” system. The current release was coming to an end. The Customer (in the XP sense) and I had collected a set of stories for the next release. Every two weeks, we had a meeting with user representatives to discuss the current and future system. We would discuss the plan for the upcoming release at the next meeting.

Shortly before, I had followed a tutorial by Suzanne Robertson on applying creative techniques to requirements discovery. Whenever I learn something new, I try to apply it with my guinea pigs customers. So, before presenting the release plan, I tried to get some more “creative” requirements from the users.

Make a wish

I asked the users to “make a wish” about the system. It could be anything, it could be crazy, it could be impossible to implement, it could be very costly. I didn’t care. I wanted them to tell me what they really wanted.

I was met with puzzled stares.

Finally, one woman spoke up.

I wish…

Well, I wish the behaviour of <this bit of the software> was not so annoying! I do this the whole day, when customers call. I want all the information available immediately, I don’t want to click through!“, she said.

That doesn’t count as a wish, because we’ve already corrected this in the current release. Make another wish.“, we replied.

Thanks. Well… then I wish the system would <do this> for me.“, she added.

That doesn’t count either, this story is already in the plan for the next release. You still have a wish left.

Okay… then… I wish… the system would <solve this> for me“, she exclaimed.

She thought we wouldn’t have thought of this. She was wrong. That story was also in the next release.

She thought a bit more and looked at us with a slightly worried look: “Have you been reading my mind, or what?

Mindreading 101

If you have a good Customer or Product Owner, the users feel as if the development team can read their mind. It’s like magic. Like most magic, there is a trick.

How did we know she was annoyed with that functionality? Simple: she had told us at the previous meeting. We had a look at how this functionality slowed her down and saw that we could improve her efficiency very easily. So, we decided to add this change to the current release. We had some time left, because we were going a bit faster than planned.

How did we know the users needed those other functionalities? Simple: we regularly went to the “Gemba“, to see how users performed their work, to talk to them, to really listen, to really understand, to really help. Genchi Genbutsu.

If you know of any out-of-work mind readers, contact me. I know several teams that are looking for a good Customer or Product Owner.

Meanwhile, they can already start to really look, really listen, really understand.

And I need to get better at stimulating users’ creativity. This was a really crap effort: we didn’t learn anything new. That’s the subject of a future entry.

Dec
06

David Anderson @ xp.be on December 10th

Agile ManagementDavid Anderson will talk about “Building a high trust culture in your software engineering organisation” on December 10th in Antwerpen, Belgium.

The Javapolis conference has provided the xp.be group with a BOF room.

Register to attend this presentation.

I’m looking forward to hear from and talk to David. I’m very interested in the application of the Theory of Constraints in agile software. Now, David is exploring a more Lean , Kanban based approach.

If you’re really ‘extreme’ you have to question everything, for example the value of a (large) backlog. According to lean principles, this is work in progress, inventory, waste. What David explains comes closer to a flow-based system. More about this at David’s Javapolis session.

But that’s NOT the topic of this talk. The topic is:

“If the essence of agile development is rooted in high levels of trust, how do you set about creating a high trust culture? When so much of what you and your team may have experienced in their career is based in an assumption of low levels of trust – contract negotiation, audit, finger pointing and blame, how do you set about reversing that and building a high trust culture?

What is trust? How do you build trust between individuals and is it possible to build trust between teams and across organizations? What are the benefits of high levels of trust? And why it is essential if your agile and Lean organization is to be “built to last”?”

Does your team or organisation have enough trust? If not, come to the session. I’ll post a summary after the session.

See you there.

Nov
24

Toyota and the power of people

Kevin Meyer has an excellent blog entry “Toyota and the Power of People” over on Evolving Excellence.

If the Toyota Way has a bottleneck, it must be the time it takes to teach people to live the “Toyota Way”. If you grow quickly (and lose some of your top people), you will be constrained by the number of people you can bring up to the level that real lean requires.

Some more about the way Toyota trains people in future blog entries.