Portia Tung and I will co-present “Pinocchio: On Becoming a Lean Leader” at the SPA 2010 conference in London on May 18th 2010.

Come and play with us to sharpen your leadership skills!

Come and learn how we’ve applied the Toyota Way management principles to introduce Lean and Agile methods in such a way that the companies can sustain the change.

My second visit to Helsinki. Last year’s Scandinavian Agile was great. This year’s was even better.

What Went Well

• Presenting the Toyota Way with Portia. I presented this session for the first time at XP Days Paris 2006. Since then, it has been changed and refined each time it’s run. Most importantly, it includes the stories and experiences we accumulated by applying these techniques over the past years.
• Meeting the other participants over coffee, lunch and dinner and at the pub.
• Running a “Conflict Resolution Diagram” systems thinking session with some 15 participants. More about the technique later.
• Helping Artem Marchenko to run the Business Value Game. It’s always interesting to see how other presenters run the game and “steal” their good ideas.
• The location: beautiful and cold autumn Helsinki. The conference center was ideal for the first day: two large presentation rooms and  three smaller workshop rooms, connected by a large open space with coffee and cakes.
• Getting tips for more books from Tom Poppendieck after the Toyota Way session.
• Visiting the Reaktor offices, getting a tour (including the “Russian” room) and discussing sauna’s, Steve Jobs’ management style and the difference between being able to do business analysis and teaching others to do it.
• Discussing Business Value modelling at the Open Space.
• The open space session announcements became more and more original and fun as each presenter tried to top the presenter before them.
• The conference went smoothly and everything was well-organised. Great job, conference organisers!

What Went Wrong

• I didn’t know the contents of the sessions. The schedule overview only contains session titles, with no way to click through to a detailed session description. There were no “session adverts” at the start of the conference, where session presenters could tell me why I should go to their session.
• The morning program was too cramped: what looked like two back-to-back 60 mins sessions were actually two 50 mins session with a 10 minute break. I prefer longer breaks. For example: at XP Days Benelux we have 30 minute breaks between sessions.
• Overrunning the timeslot for the Toyota Way session. We stayed in the timebox during rehearsals, so we need to ensure that we can do it live too.
• The Open Space didn’t make very good use of the room space: the working groups were too close to each other, so that it was difficult to understand each other with all the noise around us. All working groups stayed in their appointed place, while there was plenty of good space going unused in the middle of the room. That just shows how little we question arbitrary constraints.
• To avoid the noise and overcrowding problem, we ran the Conflict Resolution Diagram session downstairs in the coffee room. Unfortunately, we weren’t the only ones, so the session was still too noisy and cramped.
• A participant told me he walked out of the Toyota Way presentation shortly after the beginning because it  looked “too basic”.

Puzzles

• Why the need to make “controversial” statements and speeches? It seems to me that the Agile community prefers infighting over advancing the state of the art and delivering value. That is, while there is value in the items on the right, we value the item on the left more. Sectarianism (“Scrum vs Kanban”, “Agile vs Lean”) does not help me do my job.
• Why no Post-Its at the Open Space? How can you expect me to work without Post-Its?
• Why are so many sessions only about theory, even the one that told us to distrust presenters who present only theory without any concrete examples? Where did you do this? Who were the people who applied this? What were their results?
• What does a maniac with a power drill pointed at me have to do with involving people in Kanban? Karl, your Kanban presentation scared me

Lessons Learned

• If you want to run an effective open space, you need the right kind of space. Ideally, separate spaces or rooms that are sufficiently private to allow for discussion and work AND sufficiently public so that it’s easy to go from one space to the other.
• The Conflict Resolution Diagram technique is very simple. It’s also incredibly difficult because you have to question openly, approach a problem with an open mind, take the time to understand the real problem before prescribing a solution and be willing to surface and question all your assumptions. But the reward is huge: you’re able to transform “either this OR that”, “this VERSUS that” and “this OVER that” statements into “this AND that” statements. We can have our cake AND eat it too, if we choose to live a meaningful life and learn to apply some systems thinking.
• The Toyota Way presentation can become better and can be delivered better. See for yourself at XP Days Benelux 2009.

Genchi Genbutsu on TV

Many years ago there was a very interesting and infuriating series on BBC tv called  “Back to the Floor“. The premise was simple: let a company director work different jobs “on the floor”, follow them with a TV camera and see what they’ve learnt. I didn’t know the term “Genchi Genbutsu” yet, but I thought it was an excellent idea.

And it made for interesting television:

• most executives weren’t very adept at performing tasks, to the amusement of their employees who had to teach them
• the executives received a veritable barrage of problems that people experienced on the floor. The executives were invariably suprised, these problems never reached the boardroom. They had no idea.
• the executives returned humbled to their boardrooms to tell their fellow executives of their adventures and all the obstacles they had to overcome just to get some work done

Each episode always ended with the executive ordering that actions be taken to solve the problems they had encountered. And so, Betsy and her team finally got someplace to brew a cup of tea. And everybody was happy.

And what have we learned today?

Infuriatingly, almost all of the executives only experienced “Single loop learning“: they had seen some problems and taken action to solve those problems. And then they went back to the order of the day. Nothing had really changed, except for Betsy.

Very few executives asked the uncomfortable questions: “why is it that we never hear of those problems?“, “why is it that these problems don’t get solved?“, “why do people have to overcome so many obstacles to get their work done?“.  When one executive asked questions like this, you could see the other managers squirm and try to avoid being blamed. Only a handful of them took action so that the whole management team went back to the floor regularly.

No manager that I can remember went so far as to look for systemic causes of the problems. That’s probably a bit too much to ask in only a week, and a week that’s full of “real work”. There’s no time to think, we have to overcome all those obstacles!

Do you go back to the floor? What do you see? What do you do about what you see? And what do you do about the causes of what you see?

What have you learned today?

Imagine this situation: the CIO of a large company decrees that from now “all applications we develop must be browser based“. This becomes a non-negotiable constraint for every new project.

Unfortunately, a browser platform is not the best platform for all types of applications or all environments. A browser based application may not deliver the best user experience or support intensive workloads. It may be hard (or impossible) to access peripherals. It may be impossible to clearly show complex data sets. And when the network goes down, everybody’s work grinds to a halt.

But all the nice developers and project managers say “Yes boss!” and struggle to find workarounds for these difficulties, to satisfy the users. All of these workarounds make development and maintenance more complex. Users make do with what they receive and add more workarounds to deal with the deficiencies in the applications.

The real requirements

What he really meant was that from now on “all applications we develop must run on a small number of standard environments, be easy to deploy to all our users and centrally managed so that development, release and application support costs stop growing.” What’s the difference between this statement and the previous one? This statement sets a goal and constraints within which creativity can flourish. The first statement stifles creativity and stands in the way of achieving the real goal.

How do we find out what the real goal is? Because someone had the courage to ask “Why?” until it was clear what value we were generating for whom. As the “Discovering Real Business Requirements for Software Project Success” book says:

A requirement describes some value we need to deliver to someone.

Do your “requirements” fit this definition? Why not?

The value of analysis

The difference in value and cost can be staggering. The first statement costs the company lots of money and frustration from everyone who uses, develops and supports hobbled, complex applications. It’s a world of compromises. It doesn’t have to be this way. The second statement gives us a fighting chance to achieve the goals.

All it requires is someone to play the role of analyst to help the customer clearly describe what they need. Someone who acts like a detective to discover the real motives and issues.

A good analyst creates options and keeps them open as long as possible. The “Discovering Real Business Requirements for Software Project Success” book helps to get to the core of the problem. This fits well with a quote from “The Toyota Product Development System: Integrating People, Process and Technology“:

• Classical product development reduces the number of solutions early.
• Lean product development reduces the number of problems early and leaves as many solutions available as possible, for example by set-based development or by using tradeoff curves.

Is there someone who has the courage and skill to ask the right questions? Who has the tenacity to dig until they find the real business requirements?

Takt time

Takt time is the rate at which customers buy a product. Takt time determines the speed at which a Lean manufacturing runs. For example, say we sell 576 units of product A. If we have a 8 hour shift, we need to make 72 units per hour, or 1.2 units per minute. We have 50 seconds per unit.

Every step in the production process must now deliver their contribution to the product in 50 seconds.

What if there’s a step that can’t deliver in 50 seconds? Then we have a bottleneck. We’ll produce and sell less than we could. We apply the 5 focusing steps to increase the bottleneck’s capacity so that they can deliver in 50 seconds or less.

What if there’s a step that can deliver in less than 50 seconds? They still deliver every 50 seconds, even if they have to slow down. If they delivered more frequently, we’d build up lots of work in process as other steps can’t use its output faster than once every 50 seconds. Or we might build unsold goods.

Slowing down? Isn’t that inefficient? Yes, but we’re not optimising the efficiency of a single step. We’re optimising the whole value stream. If a step has a lot of spare capacity, this could be used to work on another product, but only if it doesn’t endanger the delivery of the first product.

Using Visual Management, the value stream tracks actual production rate regularly. The steps won’t run perfectly as clockwork, there will always be some variation. The production rate displays allow everybody to react (speed up, slow down a bit) to keep to the takt time. The takt time works as a metronome that synchronizes musicians.

Takt time isn’t (always) the drum beat

In Theory of Constraints, the Drum-Buffer-Rope system synchronizes the speed at which each step in production runs. The “Drum Beat” is the rhythm, the steady pace at which the slowest step (the bottleneck) runs. The rest of the system works to that beat. Again, no use producing faster than the bottleneck because we’ll only create more work in process.

The two concepts are quite similar and I sometimes confuse them. There’s one clear difference:

• takt time is customer-focused, outward looking
• drum beat is bottleneck focused, inward looking

If the customer is the constraint, a base (if not outspoken) premise of Lean, takt time equals the drum beat and drum-buffer-rope implements customer pull.

Takt time in software development

What is the equivalent of takt time in software development? If you’re Microsoft, you know approximately how many copies of Microsoft Office are bought every day. You could run your disk duplication and packaging plant at this takt time. But that’s not what I want to talk about.

Takt time = the rate at which you release a new product (version) to users

How often do you put new, valuable features in the hands of your users? Every day? Every week? Every month? Every quarter? Every year?

The logic of slow takt times or how to kill all your Agile teams with one simple decision

Most teams I work with, including Agile teams, have long release cycles. Long by my standards. Some of this is under control of the development team, but the release cycle is often dictated by other concerns. Often, operational teams (systems engineers, DBAs, support) reduce the number of releases.

Operational teams are often stressed, in fire-fighting mode and jerked around as projects miss deadlines and make last-minute changes. To reduce the load and ease the pressure, they reduce the number of releases. Fewer releases means more complex and error-prone releases, as more features are batched up in one release. These releases require more effort and have more issues. Fixing and patching those issues requires more work. Business people, under pressure to generate more value faster push harder to get features out of the door. Corners get cut, features get released under the guise of fixes. More work. The logical reaction is to reduce the number of releases again. Which makes the problem even worse. And so on.

Reducing the number of releases, increasing the overhead of releasing is the perfect way to demoralise and ultimately kill any Agile team. Why should we define short iterations and releases, if it takes so long to get something in production? Why should we collaborate tightly with customers if the software is outdated by the time it gets into the hands of users? Why should we focus on business value if potentially valuable features gather dust in an endless release process? We might as well switch to waterfall.

It doesn’t have to be this way. The first step is to regain the trust of the operational teams: release on time, deliver great quality code, involve operational teams in planning and retrospectives, treat members of operational teams (who are often involved in many projects) as members of your team: listen to them and optimise the whole value stream.

Once we’ve established trust and created one team, we can start to talk about improving and going faster.

Operational Excellence AND Customer Intimacy, but not at once

In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.

We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.

A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.

Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.

Effectiveness AND Alignment, but not at once

This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.

If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.

Managed and Agile, but not at once

I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.

What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.

Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.

Heijunka

Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.

Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.

Heijunka means making and keeping work humane.

Which small step can you take to make your work more humane?

One of the Toyota Way principles is « Nemawashi », take decisions by consensus.

Building consensus is a slow process, but it’s necessary to get everybody on board before taking a decision. Otherwise, the implementation will be delayed and (unconsciously) sabotaged by those who didn’t agree or weren’t involved.

It’s not just about building support for your ideas. The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original.

But there’s one big misunderstanding about consensus.

Consensus doesn’t require Compromise

It’s tempting to dilute our idea to reach consensus, ensure that everyone gets a bit of what they want, so that they’ll agree to go along.

It doesn’t have to be this way. In “Extreme Toyota” the authors show how Toyota embraces conflicts and doesn’t settle for compromises. They identify six contradictions that are central to Toyota’s way of working:

• Moving gradually and taking big leaps
• Cultivating frugality while spending huge sums
• Operating efficiently as well as redundantly
• Cultivating stability and a paranoid mindset
• Respecting bureaucratic hierarchy and allowing freedom to dissent
• Maintaining simplified and complex communication

“This AND that” sounds better than “This OVER that”… I want to have my cake and eat it too

Enter the business consultants

A few years ago I worked on a project that automated the whole value stream of a business unit. The main challenge was that the different departments had conflicting needs. No surprise there.

One of the conflicts was between the production department that did the work on customer demand and the sales department that sold contracts for doing the work to the customer . The production department needed standardised products with little variation so that they could work efficiently, predictably and hit their Service Level Agreements; the sales team needed customised products so that they could tailor their offering precisely to what the customer needed.

This is a classical conflict. The business consultants on the project called this “Operational Excellence” versus “Customer Intimacy“. And the consultants said we had to choose. It’s one or the other, you can’t have both. It’s like Henry Ford’s saying: “You can have any color car, as long as that color is black.”

Examining the conflict

It’s clear, you can’t have both standardised and customised at the same time. There’s a clear conflict. But we have a tool to deal with conflicts: the Conflict Resolution Diagram. Let’s apply the tool:

The diagram says:

• To have a growing, profitable business unit (A) we need to sell what the customer needs (C) and deliver it reliably and cheaply (B).
• To produce reliably, predictably at low cost and to hit the Service Level Agreements (B) we need products with little variety (D).
• To create an offer that responds to the customer’s need and to grow our market (C) we need to vary our products per customer (D’).
• Conflict: we can’t have little variation (D) and a lot of variation (D’) at the same time, but we need both.

Questioning assumptions

We deal with the conflict by questioning the underlying assumptions. Can we find fault with our logic? Bill Dettmer recommends to restate the relationships in “extreme wording”. For example:

• There’s absolutely no way to have both low and high variability at the same time! Well, duh!
• The only way to be profitable and reliable is to have low variability! Well, it was hard to fault this reasoning as this company operated on large volumes with low margins and tight competition.
• Customers always need special cases! Not always, but customers were no longer satisfied with one-size-fits-all offers. If this company couldn’t offer customised products, the competitors would be more than willing to get a new customer.
• We could have low variability and yet vary per customer if only we didn’t have so many customers! Going niche wasn’t an option for economical and legal reasons.

We looked at it every way possible and couldn’t find a fault with the reasoning until…

Finally, some clarity

The Logical Thinking Processes have a set of “Legitimate Reservations”, a set of critical questions we should ask. The first one is simply called “Clarity“: is the meaning of every word and sentence clear to everybody?

Now, we had already noticed that the different departments seemed to have different definitions for the same word. There were even differences in the way they described the different products to us. Were we talking about the same thing?

The breakthrough came when we asked “What do you mean by ‘Product’?” A product for the Production department wasn’t the same thing as a product for the Sales department. And the accounting & finance department had another definition of product. But… That’s not a bug; it’s a feature: if a Production-Product is different from a Sales-Product, can we have Production-Products with low variation and Sales-Products with high variation?

After a lot more work we came up with a way to standardise Production-Products on a small set of “building blocks” and let Sales create Sales-Products by mixing and matching the building blocks according to customer need. Then we mapped Production-Products onto Accounting-Products. And everybody got what they wanted: Operational Excellence AND Customer Intimacy.

Embrace conflict

We didn’t settle for a compromise, but spent the time to really think through our conflicts and come up with a solution that satisfied all needs. A conflict can be an opportunity to come up with an innovative solution.

You don’t have to settle for compromises if you think about it.

I’m looking forward to next week’s Integrating Agile conference in Amsterdam. On the program, a nice mix of local and international speakers. A keynote by Henrik Kniberg is bound to be interesting. I heard Rob Thomsett at the London Agile Business Conference, so I expect to be challenged and entertained. Some other sessions look interesting too, but it’s hard to tell without further session descriptions on the site. Recommendation to the organisers: TO decide if I want to go to the conference and which sessions I’ll attend I NEED to know what each session will be about.

Toyota Way

The program also features a new version of the Toyota Way session, most recently presented in Paris. I’ve presented about this topic since 2005 and the presentation keeps changing as I learn more. This time it will change more than usual, as I’m co-presenting it for the first time with Portia. As usual when working with Portia, we have more new ideas than can fit in one session.

So, what is the session about?

We present the principles and practices of the Toyota Way and Lean Management. We explain how we apply them by giving examples from our experience. We show how each of the principles does not stand alone but forms a system that brings enduring improvements.

What’s in it for you?

• See how the Lean Management principles of the Toyota Way have made Toyota a learning and improving organisation.
• Understand how Lean and Agile relate to each other.
• Learn how to apply this in your own organisation to make Agile and Lean transformations endure.

Lots of material

To give you an idea of what we talk about in 45 minutes.

All of the wisdom in those books! Plus several years of experience applying these ideas in the real world.

It’s a bit harder to take a picture of experience. Although there are some wrinkles and gray hairs I could trace…

Merci François!

Portia and I will present an updated version of this presentation at the Integrating Agile conference on June 18th in Amsterdam. See you there.

Portia, Vera and I have published a new version of the Agile Coach website. There you’ll find coaching tools we use like games, tutorials and presentations. Topics range from introductions to Agile (the XP Game, the Business Value Game, XP Loops, First Five Steps to Become Really Agile), Theory of Constraints, Real Options, Toyota Way, Interviewing techniques to Agile Fairytales.

More materials and translations will be added. All of these games are licensed “Creative Commons“, so that you can use and reuse them. If you want to help translate or improve the games, let us know.

We run retrospectives after each session so that we can improve. You can read the results of the retrospectives on the Past Events page. This transparency allows you to verify if we really take the feedback into account.

Come and play at XP Days

If you want to play the “Business Value Game” or “Mirror, Mirror on the Wall… Why Me?” come and see us at the Mini XP Day Benelux in Mechelen, Belgium (May 11th) or XP Days France in Paris, France (May 25-26th). Or invite us to come and play in your company or usergroup. Or better yet, download the games and play them yourself.

Last January I presented an overview of the Toyota Way at a Zenika seminar in Paris.

Claire has written a summary of the session (in French).

There’s a very simple way to improve productivity.

How much time do you spend on “bugs”? Finding them, analysing them, fixing them and making sure they don’t reappear. Not to forget the time spent writing the bug.

Imagine how much time you could save if you stopped writing bugs.

How do you write bug-free software? It’s simple.

Jidoka is not enough

Great, you’ve implemented Jidoka. Your systems and people find issues quickly. Your team responds quickly to resolve any issue raised. You even improve your tests whenever another issue slips through.

You’re well on your way to deliver quality quickly. But there’s something missing.

Poka-Yoke

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

Poka-Yoke software

We can Poka-Yoke software if we really think about it.

In one case, a web application didn’t work because of an incorrect configuration parameter. Two tools each required a configuration setting. The two settings had to correspond. One configuration, created by the developers, contained ‘G004′. The other configuration, maintained by the sysadmin, contained ‘GOO4′. Can you spot the mistake?

Once we found it, the issue was easy to fix. How could we avoid it? Some thinking and experimenting showed that there was a way we could reduce the configuration to one setting, even with the existing tools. This type of error couldn’t happen again.

Thank you for reporting this error. Finding and resolving issues is a great trigger to add some Poka-Yoke.

It doesn’t have to stop here. Why wasn’t the mistake found sooner? Because this feature was only fully tested in the acceptance environment and the configuration error happened only in the production environment. Why wasn’t it tested in production? Because testing that part of the application could show confidential customer information. Next time, we’ll get someone who’s allowed to see the confidential information to test that part of the application in production. Poka-Yoke the software is the first step. Poka-Yoke the software process is the next step.

I had finished implementing this class. I just needed to add a comment to explain how to use the class. First, you had to call the methods A, B or C. Then, you could call methods X, Y or Z.

This class was very error-prone. Why not write a class with methods A, B and C? These methods return an object of a class that implements X, Y and Z. You can’t call the methods in the wrong order.

If I feel the urge to document, I stop and think. Isn’t there a way I could simplify? Isn’t there a way to change the system so that errors are impossible? The pay-off is clear: less time to document, more time to code.

Poka-Yoke is an ongoing process. It isn’t done until the system is so easy to use it doesn’t require a manual or training. It isn’t done until all testers have become specifiers instead of verifiers.

Doesn’t this take a lot of time?

Yes it does.

But imagine you only had half the issues you have now. How much time would you save? Now invest that time in finding root causes and making your work Poka-Yoke.

It’s simple. But not easy.

Jidoka is one of the basic elements of the Toyota production System. Jidoka stands for “automation with a human touch” or “autonomation”. The term dates back to the Type-G Toyoda Automatic Loom which automatically stopped when it detected a problem such as thread breakage. That meant that an operator didn’t have to keep watching the machine, but could quickly intervene when one of many looms detected and signalled a problem.

The same principle can be applied to the production line. Whenever a machine or, more likely, an employee detects a problem, they “stop the line” and signal the problem using an “Andon” board. Everybody can see that there’s a problem. The team leader can quickly come and help diagnose the problem and solve it.

The sooner the problem is detected, the easier it is to fix and the smaller the impact.  Thus, one of the important parts of Lean training is to be able to detect problems, raise them quickly, analyse and fix.

Jidoka and software development

Can we apply this production line principle to software development? Of course.

How can we detect problems and defects? One good way is to have a comprehensive suite of unit tests and continuous integration. Whenever we check in, our build server tells us quickly what we’ve broken. The build server serves as our Andon. Patrick Debois has several examples of Andons in his Visu-Wall collection.

Another way is to have a suite of automated functional tests, performance tests, code analysers and other tools that are run by the continuous integration server.

Good testers who are really involved from the start of the project and track the deliverables closely are a great way to implement Jidoka. The really great testers can tell us clearly what goes wrong and how to repeat the problem.

As long as you get fast, high quality feedback that’s something’s wrong, you’re implementing Jidoka.

Jidoka is an attitude

Is that all there is? Of course not. It’s not enough to detect problems, you have to do something about it.

The build broke? I didn’t check anything in, so it’s not my fault.

What do you mean by “It doesn’t work”? It works on my machine!

Who said so? Oh, Bob… He’s so negative, he’ll find fault with everything.

Have you ever heard remarks like that? It’s not enough to detect problems, you have to do something about it. The only correct answer to someone who reports a problem is “Thank you!”. And then your team corrects the problem.

When the problem has been corrected you’ve done half of your job. The other half is asking why your existing Jidoka mechanisms failed to detect that problem in time:

• Why didn’t any of our developer tests catch the problem in time? How can we improve the tests in that area? Is that a situation that could happen in other parts of our code? Will we detect it there?
• Why didn’t any of our customer tests catch the problem in time? How can we improve our specifications in that area? Are there other blind spots? How can we improve those specifications?
• Why wasn’t this case tested? Did we misunderstand what was needed? Didn’t we do what was agreed? Do we risk more of such misunderstandings?

The biggest bottleneck in IT is learning. By reflecting on our problems, we learn to detect issues earlier.

Jidoka requires Transparency, Trust and Collaboration

If Jidoka was just a matter of installing tools and procedures, it would be easy to implement. But it’s surprisingly difficult to implement, because Jidoka requires:

• To make every problem visible. My pride might be wounded by admitting I made a mistake.
• To reward people who admit mistakes. Doesn’t that conflict with the Lean idea of “Right First Time”? Shouldn’t we reward only perfect people?
• To take the time to improve our problem-detecting systems. But there are so many issues to fix and I have so little time!
• To thank people who make problems visible. Yes, even that curmudgeon who always finds fault with everything. Yes, even that tester who delights in finding “bugs” in my beloved creations.
• To collaborate as a team to resolve problems quickly and completely. Whoever “caused” or found the problem, our common goal is to create high quality, high value work.

Being really Lean or Agile is hard. Really implementing those Agile Values is hard.

Have you made a problem visible lately?

Have you thanked a tester lately?

Have you improved your Jidoka tools lately?

If not, are you only doing half of your job?

Yesterday evening I was back in Paris to give a presentation about “Lean and the Toyota Way“. As I walked from the train station to the offices of Zenika, I came across a large billboard announcing “Dorothy et le magicien d’Oz”. It’s reassuring to see that the fairytales are alive and well.

My friends at Zenika had arranged a nice place and provided some fine drinks and snacks. More than 100 people showed up, among them many of the French Agilistas. I chatted for a while with them about agile, lean and the upcoming XP Days France.

And then it was time to start the presentation. The auditorium was almost completely full.

The Toyota Way

The presentation explained the 14 principles of The Toyota Way of Managing and the many parallels with Agile methods. As I go through the principles I illustrate them with stories from projects I’ve worked on. Each time I do this presentation it changes, as I learn more and discover more great ideas in Lean.

There were some great questions and discussions:

• “What can I do to introduce more Lean and Agile in my organisation?” – Apply the principles and values, set an example. Support and collaborate with others who apply these values.
• “Are there any incompatibilities between Lean and XP?” – None that I can see.
• “For Agile and Lean transformations to succeed we need support from management and workers. Often, we only have support from one of them.”
• “Lean coaches are very direct, not afraid of saying it as it is to management. Is that something they’re taught?” – It does seem so, judging from the documentary Kenji Hiranabe showed at Agile 2008, where a Lean coach almost made a factory manager cry by bluntly pointing out all the flaws in the production line.
• “Does Lean make you lose weight?” – A Gemba Walk a day helps

Unfortunately, I couldn’t stay for drinks afterwards because I had to rush to catch the last train back to Brussels. The next day I had another team to coach, another opportunity to “Develop exceptional people and teams”, the tenth principle of the Toyota Way.

I hope to see the participants again soon. See you at the XP Days France or a Zenika training session.

A bientôt!

What others say

Jean-Claude Grosjean summarizes the principles and contrasts them with the 7 principles of Lean Software Development and Agile.

Nicolas Martignole wrote a very extensive report on each of the principles and relates Lean, Scrum and XP.

Claude Aubry thinks “Obeya” is more beautiful than “War Room”. I fully agree. He currently tries to recreate the Obeya experience for an offshore team.

Thank you for the rapid and very detailed feedback!

On the 21st of January 2009 I’ll be in Paris to present an evening seminar on how to apply the Toyota Way management principles to Agile software development. The seminar is organised by Carl Azoury and Olivier Huber of Zenika.

To me, Agile is the application of Lean principles to software development. So, the presentation contains a lot of parallels between the two. A lot will be very familiar if you already know and practice Agile.

So, what’s left to learn? Some of the Toyota Way management principles aren’t in Agile methods. These principles are useful when we go beyond software development. There comes a moment in any successful Agile enablement when the development team is no longer the bottleneck. Suddenly, we’re faced with a completely different set of issues. Now that Agile gains more and more acceptance, we need to be able to deal with these new challenges or accept that most Agile transformations will either die or bring limited extra business value.

The more I read and learn about Toyota, the more I realise how much I don’t know and how many preconceived ideas I have to abandon. I need to keep learning. The Toyota Product Development System, for example, contains many counter-intuitive ideas like set-based design. Real Options thinking can help us understand why some of these techniques work. We’ve only started to scratch the surface of Lean ideas.

Toyota losing money? Impossible!

In the news, even Toyota is affected by the economic climate. They might even have to post the first loss since the early years. Isn’t Toyota invincible and perfect? Of course not. It will be a real show of faith in the Toyota Way if Toyota continue to keep on their workers, keep training them and keep improving to be ready when sales take off again.

Secretly, top Toyota management must be happy that this crisis happens now. One of their main concerns is complacency. No one should ever think that the work is “done”, now that Toyota is the biggest manufacturer. Hansei and Kaizen should be applied relentlessly, it’s always possible to do better. Nothing better than tough economic times to bring back the sense of urgency.

See you in Paris

The seminar is free, but you must register here. Don’t wait too long because places are limited.

See you there!

This Friday, Portia and I will present the “Real Options Space Game” at XP Days London. This strategy board game set in space allows players to experiment with Real Options concepts.

Real Options is a tool to optimize decisions: it helps us to consider and manage more possibilities and gives us more time to gather information, so that our decisions are better informed. The basic ideas are taken from financial options, but have been widened to be applicable to real-world management decisions.

There are several types of Real Options. Let’s see if the option metaphor is a useful one. How can we apply Real Options in the real world?

The option to delay a project

In this paper, Aswath Damodaran compares a Net Present Value (NPV) analysis with a Real Options analysis to decide which projects to fund when. Projects with a negative NPV now, might still become valuable later. That’s because the Real Options analysis takes into account the value of getting more information and therefore reducing risk and uncertainty.

We always have the Learning Option. We can always gather more information.

In the article, the delay is examined in a situation where the organisation has (or can buy) a way to get a hold on the market, like with a patent. We can create an option to delay a project even in a competitive market: if we have a shorter cycle time than our competitors we can afford to wait longer to start our projects. This gives us more time to gather market information. In a very volatile market, it can be more valuable to wait, to increase the odds of building the right product at the right time.

For example, if Toyota’s new product development time is 6 months shorter than a competitor, Toyota can afford to start development 6 months later. That’s 6 months in which to gather more information, six months in which they could see major swings in customer demand or in the market. That’s six months in which people can work on other projects.

So, if you decrease your cycle time you create options to

• Increase your cash flow
• Be first on the market
• Delay the project, take the go/no go decision later, when we have more information

By using Lean and Agile methods to decrease cycle time, we create real options. Starting later may be the right thing to do.

There are more fun real options, like the option to abandon a project. What could be the value of abandoning a project?

The handout for the Real Options session is not yet online, but you can download it from our site.