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

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