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

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.

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 ironies 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.

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

"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" ?

I mean developers talk to each other about how they work and make what they are doing explicit (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.

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 bottlenecks, remove issues, and improve performance, with minimal 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 can be some kind of memory that transcends individual staff.

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..

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.