|
|
I’ve finally got Jerry Weinberg‘s new book “Weinberg on Writing“.
It’s a thin book and it contains lots of examples and exercises. So far, I found it very easy to read, like all Jerry’s books (with the exception of “Introduction to General Systems Thinking“).
Jerry consistently uses the metaphor of building something out of “fieldstones”. Before you can build, you have to go out and find yourself some fieldstones. You must select the right stones and not be afraid to reject lots of stones.
Hopefully, I will learn to write a bit better. You be the judge…
Evolving Excellence by Bill Waddell and Kevin Meyer.
They write about Lean Manufacturing. The real stuff, making things people use.
 What I like most about the blog, is the passion with which they write. These guys believe in Lean, they live it everyday, they get it. A lot of people don’t get it. Bill and Kevin don’t hold back when they write about those who “talk the talk, but don’t walk the walk”.
Bill is the co-author of “Rebirth of the American Industry”. Sounds interesting, but can’t find it on the European Amazon site.
A few gems from the Toyota Way Fieldbook on organisational change:
“…we’re more likely to change what people think by changing what they do, rather than changing what people do by changing what they think.”
“Similarly, changing culture is not going to happen because of a classroom education process. We can teach people what is politically correct to say and sophisticated ways of saying it, but not affect deeply held values and assumptions. This is the unfortunate truth, though it might seem a lot easier to change culture en masse through an educational program than to have to remake the structure and processes of organizations in order to begin to change what people think. But Lean is not about doing what is easy. It is about doing what works. It is about confronting reality and having the confidence that we can shape the reality to achieve our goals.“
Some new books
I got some more books to fill up the left pane of the blog:
  “The New Solution Seling” is the follow-up to the “Solution Selling” book, a process and tools for effective sales.I’m no salesman, but the Solution Selling course I took a few years ago, was one of the most useful I ever took. I use the stuff I learned there almost every day. Much of it is about finding the real problems of the customer (the “pain”) and finding a good solution to the problem. It’s a whole process, from identifying (or surfacing) the customer’s pain to the implementation of the solution. Much of the process is what is also known as “consulting” or “analysis”. I recommend everyone to look into it, not only to become a better consultant/salesperson, but also to become a better buyer… I bought the Fieldbook to feed my “Toyota Way” habit. The book contains tips, stories and tools to implement the 14 principles of the Toyota Way.I opened the book at random, and saw the heading “ We don’t just build cars, we build people.” The headline is accompanied by a Trap section, which warns of a potential trap: “How do you refer to people?”. If managers refer to people as “heads”, “warm bodies” (as opposed to “cold bodies”?), “resources” or “FTEs”, this says something about how they really feel about their “greatest asset”… I was recently told I had used the word “resource” to refer to people several times during a workshop. So, take care what words you use, they might betray how you really feel 😉 More about the books when I’ve finished them…
 Last month, I’ve been mostly reading Thinking Beyond Lean by Michael Cusumano and Kentaro Nobeoka.
The book describes the move from single- to multi-project product development at the major automakers and the different strategies they use.
Typically, Toyota was the first company to move in this direction. At a time when other car makers were starting to adopt Toyota’s “Lean” product development model, Toyota started to think that their product development model should be improved.
Lean product development
What are some of the characteristics of “Lean” product development?
- Development is led by a “heavyweight project manager”, someone with a lot of authority, well-respected because of his technical experience and who has a clear vision of the product to built.
- Development teams are cross-functional and co-located: designers, engineers, production engineers all work together from the start and work is integrated frequently. At the end of the development process, the product is well-integrated and ready to be produced efficiently.
- People stay on a team beyond a single project, to preserve the implicit knowledge, processes and working habits.
Agilists will recognize many traits of this model. The “heavyweight” project manager is odd: imagine someone who’s the onsite customer, the coach, the manager and the technical lead all rolled into one. It’s astonishing that Toyota is able to grow such supermen.
But, Toyota started to see some drawbacks…
- because the teams wanted to make ‘their’ car the best they could possibly build, lower-end models started to get high-end features. This not only made the cars more expensive, but the distinction between models started to blur. Some of the models became competitors and “cannibalized” each other’s market.
- to reduce costs, car makers increasingly (re)use common parts. The major shift is towards common “platforms”, the base of the car. However, it was hard to coordinate the different independent projects to reuse parts and to transfer knowledge from one project to another.
- team members became more generalists, less specialists. This is great for working as a team, but there were fears that the engineers would lose their technical “edge” and would no longer be innovative.
These drawbacks are not unique to car makers. Similar problems are encountered by teams working “vertically”: each team builds one application from start to finish. The resulting systems are “silos”, completely independent applications with nothing in common.
What to do then? Move back to a “horizontal” organization where people are organized by what they do, not what they work on? Create a design group, a chassis group, an engine group…? That’s great for innovation in each area and reuse. But it’s hellishly hard to coordinate all those departments to build something that has conceptual integrity. There’s a real danger that each department will optimize their own work, at the expense of the overall result.
I’ve seen many organizations flip-flop between the two models, never satisfied with the results.
Beyond Lean
Toyota didn’t go back to the old model. They went the “Development Center” way:
- There are 4 development centers
- 3 development centers each develop several models. The different models in a development center typically share a small number of platforms.
- the fourth development center is responsible for research and parts that are common to all models
- Each development center is run by an experienced ex-heavyweight project manager, whose job is to coordinate the effort of the product project managers in the centre. There’s now a hierarchy of ‘chief engineers’, so that each of them only has to coordinate with a limited number of other chief engineers.
- Each development center has a simplified matrix structure:
- there a small number of functional groups (e.g. chassis engineering, power-train engineering…)
- product development is still done by heavyweight project managers, using a team composed of people from the different functional groups.
- For each component in a car, the appropriate level of reuse is determined:
- Is this something that is unique to one model, something that distinguishes this model from the others? Give the model’s project manager authority.
- Is this something that is common to the models in the development center, like the shared “platform”? Give the the development center’s manager authority.
- Is this something that is common to everything that Toyota makes? Is this something that requires a large R&D effort (like developing a hybrid engine)? Give the authority to “Development center 4”.
- For common parts, there is a limited choice (maybe 3-5 options), from which each team can freely choose. A new option is only added if it’s clearly superior to existing options; one of the existing options is dropped, to keep the number of choices down.
This system reduces complexity while promoting reuse within an appropriate scope. They’re still able to develop products quickly but also to reduce costs by reuse. And as Toyota grows, this structure keeps the number of communication lines and people to manage within manageable bounds.
What about agile software development?
That’s great for cars, what can we learn from this? Already, some people in the agile world are looking beyond single projects, because the same advantages and disadvantages as in Lean Product development are starting to appear. What can we reuse?
- Group several small agile teams in one unit, managed by an experienced agile team leader, who can coordinate the teams and see opportunities for cooperation.
- Reuse at the right level. Take into consideration the cost of reuse; the wider the scope of reuse, the larger the cost.
- If you use standard components, provide a small list of options. Too many choices means you won’t benefit from reuse; too few choices and chances are that none is a good fit to the problem.
Oh, and if you need to plan and coordinate multiple projects and their dependencies, look up “Critical Chain“.
|
|
