Kanban – An Integration of Deming, Ohno, TOC, Satir and Nonaka

July 14, 2011 — Posted by Al Shalloway

My alternative title to this blog was "If You Say Kanban Isn't About People, then You Don't Know What Kanban Is." But that sounded too much like a rant. However, I have to admit, much of this blog is a rant. Smile

Kanban gets a lot thrown its way – statements like it's all about tools, it's not about people. Like all other agile methods, Kanban is grounded in respecting people.  But Kanban actually goes much further.  It is also grounded in the psychology of how people change (Satir) and how they learn (Nonaka, Toyota Kata).  In this blog I'll lay out how Kanban is a collection of respecting people, systems thinking, learning through small steps, theory-of constraints (the one, admittedly, non-people centric foundation), human psychology of change and how humans best create ideas and learn.   I will point out the ironices of saying Kanban does not attend to people all along the way.

Kanban's foundations in in taking a systems thinking approach – particularly Deming 's system of profound knowledge.. Deming's # one principle is respect people and to use systems thinking to improve the work environment for people. And most particularly, allow people to drive this improvement as they are most aware of the changes needed (shades of self-organization!).

Kanban also takes particular advantage of Taiichi Ohno's work (the implementer of the Toyota Production System ). Ohno was instrumental in creating what probably stands as the greatest example of a learning organization ever. Toyota achieved this by using Deming's PDCA cycle as the cornerstone for continuous learning. Learning and improvement is based on the notion of having well-defined (not static) processes so people could understand if improvements were being made or not. See the incredible Toyota Kata by Mike Rother for more.

To me, a systems that creates an environment where people can control how they work, includes management so they can help those doing the work and provides continual education in how to get their work done better is about as people friendly as you get.

Now, Theory of Constraints (TOC) is fairly a doing thing. So, maybe Kanban is only 80% about people. Smile

Virginia Satir is one of the most influential psychotherapists of all time. Her Satir Change Process Model is widely quoted in the agile community. Many people in the Agile community know of Satir through Gerry Weinberg (admittedly one of my all-time favorite people and authors). Gerry is continuously quoted as saying "no matter what the problem, it's always a people problem." What seems to be ignored about Satir, however, is her work about people having comfort zones. In particular, that when they are thrown out of this zone, they revert back to old habits and will actually sabotage success. Her work, elaborated by many others, argues that a continual process of small changes is more sustainable and will achieve greater results than overly abrupt changes, at least in the absence of a burning platform (see One Small Step Can Change Your Life: The Kaizen Way for more). Even when abrupt change is required, it is important to understand how to deal with the fear any significant change entails. William Bridges' Managing Transitions: Making the Most of Change describes this brilliantly.

So what has all of this to do with Kanban? Well, Kanban is the only Agile method that provides the people adopting it the ability to control their rate of change. Kanban was developed by David Anderson as a change management system. See more on this with my own Demystifying Kanban article or David's fantastic book Kanban . The irony is much of the criticism about Kanban being tool-centric comes from Scrum thought leaders, trainers, etc., who don't attend to this psychological aspect of the abrupt change Scrum often entails. Kanban does.

The bigger irony, of course, is that Kanban specifically says you need to follow Ikujiro Nonaka 's SECI Knowledge Creation Framework. SECI stands for Socialization, Externalization, Combination, Internalization. Nonaka claims knowledge creation is a spiraling process of interactions between explicit and tacit knowledge. The interactions between these knowledge types lead to the creation of new knowledge. Kanban's explicit policies, long vilified by the Scrum community, provides exactly this type of learning. Why is this ironic? Nonaka, with Hirotaka Takeuchi, wrote the New New Product Development Game which is the inspiration for Scrum. Perhaps a greater irony is that Sensei Nonaka was not aware that he was the inspiration for Scrum until just before he keynoted at Agile Japan in April 2010 (along with myself, I'm proud to say).

To close out this blog, I am going to make a series of assertions that I posted on a user group in response to some statements about Kanban and people. Hopefully this will help clarify these ideas for you.

The skill/people/deliberate practice side is essential and is neglected.  One of my rants against Scrum is it ignores this with its attitude of "just do it."  It starts out prescriptive, demanding certain practices even when it requires significant changes up front.  One of the things I like about Kanban is it attends to the human side – how fast can people change.

  • The people aspects of development are more important than anything
  • That being said, there are rules (of the nature of software development) that people need to know
  • The system people are in has a significant impact on their behavior – improving this system can improve their behavior (and this is neglected in software development a lot)
  • Much improvement can be made by people knowing what to look at
  • Knowing what to look at (e.g., flow instead of how productive people are as measured by how busy they are) can be used to gel people into great teams
  • You can't get trust by working directly on it – in other words, saying trust us doesn't cause trust – you must work in a way that facilitates trust
  • Explicitly talking about how you are working enables people to understand your motivations better and this facilitates trust
  • Systems include a doing and a being aspect – these two aspects are inseparable from each other
  • The foundation of Deming is respecting people and attending to systems
  • The foundation of lean is Deming, plus just in time and autonomation (so respecting people is foundational)
  • People learning lean tend to ignore the people aspects of it and translate lean into tools – this is not good and is something anyone teaching lean has to attend to – but it doesn't make lean about tools
  • Although people creating software are part of a complex adaptive system, one can get macro-prediction in the development process. Micro-predictability, which is not possible is predicting whether a roulette wheel at a casino will come up red or black next. Macro-predictability is that more money will stay in the casino over the next month than will leaves it.
  • Putting people in good systems results in better results than putting people in bad systems – so attending to the systems will help the people's behavior
  • Trusting in your environment without demanding people always think is a sure way to fail
  • Management demanding people work a certain way is also a sure way to fail
  • People talking to each other improves their interactions and learning
Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

"The bigger irony, of course, is that Kanban specifically says you need to follow Ikujiro Nonaka 's SECI Knowledge Creation Framework."

Does Kanban really say so? Never heard of it.

Cheers
Matthias

Well, I think it does.  It says you need visibility in your process - that you discuss what your process is.  It may not mention the SECI method, but it is basically saying what SECI is saying. 

 

Alan Shalloway, CEO Net Objectives

"Trusting in your environment without demanding people always think is a sure way to fail"

For me, as a non-native English speaker, this sentence sounds like there is missing a word. Do you mean:
"People always think that trusting in your environment without demanding it is a sure way to fail" ?

 

Thanks for asking for clarification.

I meant that if you trust your environment will fix your problems (that is, you don't have to think) then you will fail.

Alan Shalloway, CEO Net Objectives

"Explicitly talking about how you are working enables people to understand your motivations better and this facilitates trust"

Who talks and who develops trust? Do you mean: Developers talk about how they work and help the business to trust them?

I mean developers talk to each other about how they work and make what they are doing explict (clear, not static).   This develops trust within the development team.  It also developers trust of the development team by management because they see that the developers are working together and learning.

Alan Shalloway, CEO Net Objectives

It seems to me that some die hard agile "traditionalists" can't get past some of the language that lean / Kanban uses to see it for what it is. Any mention of policies, standards, use of SPC charts and people are screaming murder around accusations of top down control, and using static manufacturing thinking to dumb down the much more complex field of software.

Kanban may look like it's about control at first glance, but deeper examination reveals that the control mechanism are given to Doers, so that they can improve their work. I can't think of anything more people centric than empowering people to isolate bottleecks, remove issues, and improve performance, with minimL management intervention.

As to scrum people not liking explicit policies, I never understood that, scrum is full of policies. You must have a PO, you must have a scrum master, the team must be cross functional, the team must have a backlog, the team should attend daily stand ups, etc, etc, etc. Kanban has way less policies to start, it just wants teams and the org to track them so there cannbe some kind of memory that transcends individual staff.

Jeff:Well said.

Thanks,

Alan Shalloway

Alan, good rant :-) .... "the people aspect of the development" seems to be something that gets the most lip service in my experience, whether its kanban or scrum or waterfall, or .
the incentive is always tied to completion of the project by the deadline at any cost. Unless the incentive structure is modified to clearly include a measure of team member satisfaction, and honest feedback, all processes remain incomplete. It is happening.. but slowly..

Alan,

I appreciate what you've offered up here. I hope folks take the time to get better acquainted with any referenced sources with which they may not already be deeply familiar.

I call this out because it isn't difficult to spot evidence of a great number of practitioners focusing on mechanics these days - whether implementing Scrum, or Kanban, or some other method - while completely ignoring the intent and thinking behind it.

Why is this distinction important? Because the truth is, the approach you've selected has nothing to do with whether or not you are respecting people. At the end of the day, that is something only the people themselves - leaders and contributors - control.

Best,

Brad Barton

Pages

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile