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.
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.
Comments
Kanban and SECI
Fri, 2011-07-15 14:20 — mattes3"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
Fri, 2011-07-15 15:02 — Al ShallowayWell, 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
Trust
Fri, 2011-07-15 14:19 — mattes3"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
Fri, 2011-07-15 15:01 — Al ShallowayThanks 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
Who trusts whom?
Fri, 2011-07-15 14:19 — mattes3"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
Fri, 2011-07-15 14:54 — Al ShallowayI 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.
Alan Shalloway, CEO Net Objectives
There seems to be a lot of bias out there getting in the way
Fri, 2011-07-15 21:29 — Jeff AndersonIt 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.
Jeff:Well said.Thanks, Alan
Fri, 2011-07-15 22:00 — Al ShallowayJeff:Well said.
Thanks,
Alan Shalloway
Alan, good rant :-) ....
Tue, 2011-07-19 11:49 — animikhAlan, 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..
Good stuff...
Wed, 2011-07-20 14:48 — Brad BartonAlan,
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