The Toyota Way - Use Pull Systems to Avoid Overproduction

Overproduction (waste) is one of the biggest tenets of the Toyota Production System. In this principle, Toyota recommends using pull systems to avoid producing overproduction.

Section II: The Right Process Will Produce the Right Results

Principle 3. Use “Pull” Systems to Avoid Overproduction

■ Provide your downline customers in the production process with what
they want, when they want it, and in the amount they want. Material
replenishment initiated by consumption is the basic principle of just-intime.
■ Minimize your work in process and warehousing of inventory by stocking
small amounts of each product and frequently restocking based on
what the customer actually takes away.
■ Be responsive to the day-by-day shifts in customer demand rather than
relying on computer schedules and systems to track wasteful inventory.

A tool Toyota uses to prevent overproduction is called kanban. A kanban is a sign. It could be well placed card signally that one area is about to run out of parts, or it could be an empty bin, indicating it is ready to be filled again with a specific number of parts. The kanban system is used for managing the flow and production of materials in a just-in-time system.

What is interesting is that even today, with all the electronics and computers at their disposal, you can walk into a Toyota factory and still see simple cards, and empty bins being used to manage production on the plant floor.

While kanban is a useful tool for managing inventory, Toyota still strives to eliminate the need for cards and signs, as inventory of any kind is seen as a form of waste. In Toyota’s view that is the greatest challenge. To create a learning organization that will find ways to reduce the number of kanban and thereby eliminate the inventory buffer all together.

This makes me wonder if there are ways we can reduce, or eliminate the kanban system we often use on our agile projects. The card wall.

The best time to post on your blog

For all you bloggers out there, here is an interesting post from ReadWriteWeb reporting the best time to post to your blog.

Best time : 1pm - 3pm and 5pm - 7pm (PST) on Thursdays.
Worst time : Between 3 - 5 pm PST on weekends.

This seems to make sense as there are far fewer readers on weekends, and 1-3 pm in the afternoon hits people just when they are preparing themselves to be distracted during that mid-afternoon lull.

I myself am a morning person, and like to hit people like you first thing in the morning

Happy blogging!

The Toyota Way - Long-term philosophy

Section I: Long-Term Philosophy

Principle 1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.

■ Have a philosophical sense of purpose that supersedes any short-term decision making. Work, grow, and align the whole organization toward a common purpose that is bigger than making money. Understand your place in the history of the company and work to bring the company to
the next level. Your philosophical mission is the foundation for all the other principles.
■ Generate value for the customer, society, and the economy—it is your starting point. Evaluate every function in the company in terms of its ability to achieve this.
■ Be responsible. Strive to decide your own fate. Act with self-reliance and trust in your own abilities. Accept responsibility for your conduct and maintain and improve the skills that enable you to produce added value.

I have always been fascinated by companies who have discovered what they stand for, beyond making money. I have been fortunate enough to work for one (ThoughtWorks). I tried creating another with some friends (CambrianHouse). And I look forward to getting up every day and continuing my search for others.

My current fascination is with Toyota. Toyota seems to know whom they serve, why they exist, why they are here.

Here is a quote from Jeffrey Liker’s interview with Jim Press, Executive Vice President and C.O.O. of Toyota Sales North America.

The purpose of the money we make is not for us as a company to gain, and it’s not for us as associates to see our stock portfolio grow or anything like that. The purpose is so we can reinvest in the future, so we can continue to do this. That’s the purpose of our investment. And to help society and to help the community , and to contribute back to the community that we’re fortunate enough to do business in. I’ve got a trillion examples of that.

How can that be? How does Toyota stay in business (and become the 2nd largest car maker in the world) if it isn’t focused on making money?

To see another way in which Toyota distinguishes itself, compare Toyota and Ford missions statements:

Ford Motor Company

1. Ford is a worldwide leader in automotive and automotive related products and services as well as in newer industries such as aerospace, communications, and financial services.

2. Our mission is to improve continually our products and services to meet our customer’s needs, allowing us to prosper as a business and to provide a reasonable return to our stockholders, the owners of our business.

Ford’s seems reasonable. It wants to continuously improve products, to prosper as a business, and ultimately provide a return for the owners of the business.

Compare this now with Toyota’s.

Toyota Motor Manufacturing (North America)

1. As an American company, contribute to the economic growth of the community and the United States.

2. As an independent company, contribute to the stability and well-being of team members.

3. As a Toyota group company, contribute to the overall growth of Toyota by adding value to our customers.

No mention of shareholder value. No mention of quality products. Nor the pursuit of excellence (all things Toyota is passionate about).

Toyota doesn’t see it’s purpose as making quality products that sell and make money. That is only in support of the mission. The true mission is:

1. Contribute to economic growth of the country in which it is located (external stakeholders).
2. Contribute to the stability and well being of team members (internal stakeholders).
3. Contribute to the overall growth of Toyota.

In other words, in order to contribute to external or internal stakeholders, it must enhance the growth of society. This is the reason for making excellent products. This seems so backwards to how most companies operate. Toyota wants its employee’s to grow, continuously improve, build high quality products, and learn, to create dedicated repeat customers that will last a life time.

Their reason for being is to keep doing what they do - enhance society.

The Toyota Way is made of 14 principles. We have only scratched the surface here with Principle #1.

In the future I hope to look more closely at each. In the mean time, if you have other examples of companies, that have found meaning beyond making money, I would love to hear about them.

To learn more about Toyota, and how it does what it does, I recommend picking up a copy of the Toyota Way by Jeffrey Liker.

Batch vs continuous flow processing

If you are at a cocktail party, and someone asks you to compare and contrast the differences between batch and continuous flowing processes, calmly lower your martini, grab the nearest table napkin, and proceed to draw the following picture:

Suppose we were in the toy car manufacturing business and there were three stages to building a car: the body, the wheels, and the paint. You decide the most optimal way to build the cars would be to batch them up into groups of ten, and send them from one stage to the next in one big batch.

If we assume it takes 1 min per car at each stage, then we would expect the following results:

Time to build first car: 21 minutes
Time to build first batch of ten: 30 minutes

Now, suppose we were to draw this picture on another napkin:

Only this time instead of manufacturing our cars in groups of ten, we build them one at a time in a one-piece continuous flow process. Were we to do this, we could expect these results:

Time to build first car: 3 minutes
Time to build first batch of ten: 12 minutes

In the continuous flow example, the first car rolled off the assembly in in 3 minutes (18 minutes faster than the batch process).

All ten cars were built in 12 minutes (an improvement of 18 minutes over the batch process).

To really impress your guests, you could then demonstrate your worldly knowledge and command of automotive history by explaining that this is precisely what Toyota figured out when it began competing with Ford’s mass production system.

Toyota realized that a continuous one-piece flow process:
* increases productivity - more cars in less time
* builds in quality - easier to spot defective parts sooner
* is more efficient - less material lying around
* reduces costs - less inventory

By this time, other party goers will have no doubt picked up on your conversation, and you will most likely be the life of the party with everyone hinged on your every word.

You could excuse yourself.
You could change topics.

Or you could pickup a copy of Jeffrey Liker’s excellent book, The Toyota Way, and prepare yourself for the next party.

The Toyota Way - You have a new assignment

The year is 1950. You are an up and coming manager at a young automotive company in Japan. Your county has just lost a world war. You’ve had two atom bombs dropped on you. Your industrial capability has been decimated. Your supply base is wiped out. And your consumers have little money.

Your boss comes back from the Ford River Rouge plant in the U.S., calls you into his office, and calmly hands you a new assignment. He wants you to improve your manufacturing process so that it rivals Ford’s.

Sound like something from mission impossible?

This is precisely the circumstances that Taiichi Ohno faced when he was tasked with this very challenge over 50 years ago. From which emerged the Toyota Production System (TPS).

Would you be up to the challenge?

The Toyota Way

Every once in a while you pick up a book you just can’t put down. This happened to me recently when I finally got around to reading The Toyota Way, by Jeffery Liker.

The Toyota Way goes deep inside the heart of the company. Jeffrey shepherds readers through the birth of the company, the development of its founding principles, and the ever so popular Toyota Production System (TPS) itself.

The book is full of stories about the birth of Lexus (Toyota exec’s basically got tired of driving European luxury cars into work everyday) and the revolutionary development of the Prius.

If there is one thing that is made apparent to me after reading this book, it is how young the agile software movement is, and how universal the Toyota principals are. They cross industry, transcend business, and could be used by many companies (more on this later).

I am also starting to appreciate how difficult it is to copy Toyota (I don’t believe you can). Toyota’s been practicing and refining these practices for over 70 years. It’s no wonder Ford and GM can’t catch these guys. It’s much more than the practices.

If you are looking for a great read, and hunger for more after reading Mary and Tom’s Implementing Lean Software Development, this book is for you.

Share, learn, and grow!

Ask tough questions

Ask tough questions at the beginning of your projects.

Why?

Because at the beginning of the project you:

• are new
• have nothing to lose
• have not spent any money
• are mostly still sane and rational, and
• have time to do something about it if you discover something you don’t like.

The beginning of a project is the time to ask those tough, uncomfortable, awareness generating questions that all too often go left unsaid because:

a) people are just being nice and are too polite to raise them, or

b) it’s still a big love in and everyone is still gazing lovingly into each other eyes.

There’s something
I have to ask you …

Like all strong marriages, if you are going to build a lasting relationship with your team, and your customers, you need to start preparing for the day after the honeymoon. Start talking plainly and frankly about how you are going to address some challenges you see on the horizon.

For example, if you start hearing things like:

So you want to replace your legacy mainframe application using a junior team, with no .NET experience, no OO experience, and no agile experience. Blindfolded. Interesting ….

You think one analyst will be sufficient to produce requirements for 30 developers? Tell me more!

You want to leave testing till the end of the project, while ensuring quality is job #1. I see.

If I understand you correctly, scope is fixed, budget is fixed, quality is fixed, and date is fixed. All we need to do is follow this 5 year Gantt chart and we will be successful? Is that correct?

Waiting to have frank discussions about these and other project pitfalls till the end of the project is too late. No one will want to hear it.

Raise issues early. Have frank, respectful discussions. And talk about these things while you are sane.

Don’t expect to resolve everything.

But have the conversation.

Bloomberg on Agile Part II (Risk Analysis)

Continuing on the theme of sharing agile project management techniques in the wild, here is another example of Bloomberg’s approach to risk management and planning. For Part I (on the benefits of working from a heap) click here.

As quoted from his book, Bloomberg by Bloomberg:

Don’t think, however, that planning and analysis have no place in achieving success. Quite the contrary. Use them, just don’t have them use you. Plan things out and work through real-life scenarios selecting from the opportunities currently available. Just don’t waste effort worrying about an infinite number of down-the-road possibilities, most of which will never materialize.

Think logically and dispassionately about what you’d like to do. Work out all the steps of the process - the entire what, when, where, why, and how. Then, sit down after you are absolutely positive you know it cold, and write it out. There’s an old saying, “If you can’t write it , you don’t know it.” Try it. The first paragraph invariably stops you short. “Now why did we want this particular thing?” you’ll find yourself asking. “Where did we think the resources would come from?” “And what makes us think others - the suppliers, the customers, and potential rivals - are going to cooperate?” On and on, you’ll find yourself asking the most basic questions you hadn’t focused on before taking pen to paper.

As you discover you don’t know it all, force yourself to address the things you forget, ignored, underestimated, or glossed over. Write them out for a doubting stranger who doesn’t come with the confidence in the project’s utility - and who, unlike your spouse, parent, sibling, or child, doesn’t have a vested interest in keeping you happy. Make sure your written description follows, from beginning to end, in a logical, complete, doable, path.

Then tear up the paper.

That’s right, rip it up. You’ve done the analysis. You’ve found enough holes in the plan to drive your hoped-for Bentley automobile through repeatedly. You’ve planned for myriad what-if scenarios. You’ve presented your ideas to others. You’ve even mapped out the first few steps.

But the real world throws curve balls and sliders every day, as well as the fastballs you practice against. You’ll inevitable face problems different from the ones you anticipated. Sometimes you’ll gave to “zig” when the blue print says “zag”. You don’t want to detailed, inflexible plan getting in the way when you have to respond instantly. By now, you either know what you can know - or you don’t and never will. As to the rest, take it as it comes.

I like Bloomberg’s approach to risk analysis and mitigation. Worry about the stuff you can handle, and don’t sweat the rest.

You are always going to be able to find reasons for not going forward with a project. And you can rest assured your plan won’t have events like loose lead programmer here, or have primary customer be poached by competitor here (both of which have happened to me). You just gotta deal with it and move on.

As the lord’s serenity prayer says:

Grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And the wisdom to know the difference.

Bloomberg on Agile

Bloomberg by
Bloomberg

A couple months ago I got tired of hearing Michael Bloomberg’s name and not know much about the guy. So, over Christmas I went out and picked up a copy of Bloomberg by Bloomberg - a self styled autobiography.

Turns out Bloomberg is a pretty interesting guy. Before becoming mayor of New York, he was a partner at the now defunct Salomon Brothers on Wall Street. After being let go (with a severance of $10 Million), Bloomberg went out and started up his own financial information company. Thus was born the Bloomberg terminal (a dedicated computer for bringing stock and bond traders market information rapidly). To make a long story short, Bloomberg did very well, and almost ran for president this year.

So what does all of this have to do with agile?

Read the following passage from the book, and observe the parallels with agile in how Bloomberg handles classic too much to do, and not enough time problem.

In computer terms, doing it whenever needed, on the fly, is working from a “heap”, not a “stack” or a “queue.” Working from stacks and queues is the rigid, bureaucratized method of operating; it makes you take out things in a pre-described order (i.e. last in, first out for a stack). But if you work from a heap, where input and output are independent, you can use your head, selecting what you need, when you need it, based on outside criteria that are always changing (e.g., what’s need now, such as responding immediately to a customer complaint or getting a gift for your spouse’s birthday when that day arrives and you’ve totally forgotten).

Michael definitely gets it. He knows things won’t go according to plan. He intuitively understands that priorities are going to change. And he places great value in being able to respond immediately to a customer (or significant others birthday).

Something I have grown to feel over the years is agile is nothing new. If anything it is as old as time. It is a natural way of working, that people instinctively do all by themselves.

This was just another example of an entrepreneur being agile back in the 80s.

The 3 fundamental laws of software project management

I read this somewhere (can’t remember where, but I think it was DeCarlo) and it has served me well. These laws have certainly held true for every software project I have ever been on.

1. The requirements are going to change.

2. It is impossible to gather all the requirements at the beginning of a project.

3. There will always be more requirements than time and budget allow.