In his classic book about Toyota, The Toyota Way, Jeffrey liker describe the 14 management principles that are guiding the way Toyota operates.  These principles explain why Toyota is different from other companies and so much more successful.

Principle #13 is about nemawashi: The way Toyota makes and implements decisions.

Liker describes the principle this way:

Do not pick a single direction and go down that one path until you have thoroughly considered alternatives.  When you have picked, move quickly but cautiously down the path.

And about the  process:

Nemawashi is the process of discussing problems and potential solutions with all of those affected, to collect their ideas and get agreement on a path forward. This consensus process, though time-consuming, helps broaden the search for solutions, and once a decision is made, the stage is set for rapid implementation.

How can we apply and use Nemawashi in our organizations and how does it fit a agile approach to software development?

There are two aspects of Nemawashi.  First of all it is a thinking process. By deliberately not deciding before all alternatives and risks has been considered, we avoid a kind of habitual thinking, where we just take the first solution that comes to mind, and start implementation immediately.  If we are always are guided by our habits, there will be very little innovation and new thinking. Second, it is a way to create support and engagement from everybody involved. By consulting people involved, carefully listening to their opinion and incorporating it in the proposal, the chances for successful implementation are much better, than if implementation and decisions are forced through.

A common understanding of agile development is that it is more about “doing” than “thinking” and most Agilists are sworn enemies of Waterfall processes with detailed planning up front planning.

So how is nemawashi different from waterfall planning?

Toyota has the concept of The Gemba – the real place, where actual work is done. Any planning activity is done close to or at The Gemba, and not in an ivory tower far from reality. Second  The process of considering alternatives and risks will be a process that is driven by experiments and trying out things – what in product development is called Concurrent Set Based Design.

The ability to do lightweight planning and quickly decisions, as we do it in agile development,  is based on having a software development system, that allows us to have low cost of change, and rapid feedback.  If we think that all processes in a company or in a development group will work the same way as we implement new features in our software, we may make a dangerous mistake.

There is a number of decisions that are not easily reverted, and  does require input and adjustments from many involved people to be successfully implemented. Examples are hiring of new staff, architectural decisions, and changes in organization.

If you hire new people, and have not assured they fit well into the team, or you have not carefully accessed, that they have the skills and competencies you are looking for, it can be very costly to correct. If you decide to start using a tool to manage your development process, because a vendor recommends it, or you know somebody else using it, you are likely to pay a high price, for a too hasty decision later.

A final quote from the Toyota Way:

If you’ve got a project that is supposed to be fully implemented in a year, it seems to me that the typical American company will spend about three months on planning, then they’ll begin to implement. But they’ll encounter all sorts of problems after implementation, and they’ll spend the rest of the year correcting them.

However, given the same year-long project, Toyota will spend nine to 10 months planning, then implement in a small way such as with pilot production and be fully implemented at the end of the year, with virtually no remaining problems.

Alex Warren, former senior vice president,

Toyota Motor Manufacturing, Kentucky

By Bent Jensen