Introductions to the Kanban method tend to start with a description of the kanban card wall (a tool) and lead on to a description of its core practices. If you’re lucky, you’ll get to hear about Kanban’s foundational principles too.
Here, I’m attempting a different approach, one that gives equal weight both to the principles (which I believe should come first – they’re not called “foundational” for nothing) and the core practices by identifying the values that underpin them. In doing so we’ll cover most of the main elements of the method, so perhaps this works as a teaching framework too?
Regardless, the result is holistic (the values are widely applicable at multiple levels), remains true to Kanban’s purpose of driving evolutionary organisational change, and helps to address three misconceptions:
i. that Kanban is somehow a software development process
ii. that Kanban doesn’t have at its heart the kind of values that will both challenge an organization and guide its agents of change, and
iii. that Kanban is only for number-crunching tool-heads in control-driven organisations (I exaggerate this last misconception only slightly)
Moreover, I hope to demonstrate also that a values-based description is useful for other, more constructive reasons.
My starting point
From Kanban’s Foundational Principles in their usual sequence I identify four values: Understanding, Agreement, Respect & Leadership. The first of these requires a little justification but the other three can be read directly into the principles as they are typically worded.
The values behind Kanban’s six Core Practices are a little trickier, not because the they aren’t there but because the correspondence isn’t exactly one-to-one. I chose another four (that’s eight so far): Transparency, Balance, Flow & Collaboration. However, I found it helpful to depart from the this obvious sequence and was compelled to add an additional one, making nine in total.
As I expand on each of these we’ll uncover a few more candidates for inclusion – I’ll highlight in bold anything that looks like a value (abstract nouns, basically). With the one exception to which I’ve already alluded, they’re less important, less axiomatic, less “core”.
Nine core values of Kanban
Understanding is one of the less obvious values of Kanban. I read it into the first foundational principle, “Start with what you do now”. Understand the thing you’re changing, whether it’s the nitty-gritty details of a process, the way a process performs under conditions of stress, or something as abstract as your organisation’s overall approach to change.
Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
The Process Myth, Rands in Repose
In our Kanban training we teach a Systems Thinking approach that places understanding very high on our list of priorities. It’s right there in our early introductions to the method, the basis of the very first class exercise. Where does work come from? What characterizes different kinds of work? What approaches to the problems of change and improvement tend to succeed or fail, both generally and in your organisation specifically? Why might that be?
By definition, the absence of understanding is what characterises cargo cult implementations. Even with good intentions there’s a likelihood that understanding will be lost when change is driven top-down, justified weakly (over-relying on appeals to best practice for example) and passed unthinkingly between organisational layers. It’s no small surprise therefore that change projects have a tendency to disappoint. Unfortunately for the lazy or unskilled manager, understanding and its allied values of learning and alignment take effort.
Agreement is right there in the second foundational principle, “Agree to pursue incremental, evolutionary change”. I like to turn this around: would you reasonably expect to be successful in implementing change without it? Could it be that it’s lack of agreement that’s limiting your progress? Or perhaps there is some agreement but it’s not deep enough – you’re agreed on the existence of a problem but not on its impact or causes (see understanding)?
This principle might seem to suggest another value, that of incrementalism. I would however shy away from describing this this as a core value, for the reason that we promote incremental, evolutionary change because it has a high chance of success, not because its alternatives in radicalism or conservatism are never better alternatives. And if pragmatism is a value, it is a rather slippery one.
“Respect for people” is a pillar of Lean. Kanban applies this to the problem of organisational change in its third principle, “Initially, respect current roles, responsibilities & job titles”.
As in life, respect is a good guide when implementing change. Will it increase your chances of success if you start by implying that people are doing a bad job, or their roles are worthless? Probably not. Is it helpful to assume bad motives? Again, probably not. But does respect just mean “be nice”? Again no:
Showing respect for people does not mean you have to like them, agree with their views, and fail to challenge any half baked reasoning.
That kind of respect takes courage, taking us to our next value.
Leadership features in most stories of success but it was only in 2012 that it was added as a foundational principle, in the form “Encourage acts of leadership at all levels in your organization – from individual contributor to senior management”.
Much has been written on leadership and I won’t add to it here except to make a few quick observations:
i. You might wish for an autocrat – a Steve Jobs (or a Steve Ballmer) perhaps – but the “at every level” kind of leadership is something different.
ii. Not only is leadership something to value, management isn’t inherently something to despise either (remember respect?).
iii. Furthermore, neither leadership nor management precludes self organisation, where individuals, teams and systems have the capacity to adapt without central or senior direction. Rather, good leadership and good management create the conditions in which self organisation thrives.
iv. Good leadership involves challenge (we’ve used this word already). As agents of change we must be prepared both to challenge and to be challenged.
Turning to the practices, we start with the third one, “Manage flow”.
The management part of this practice speaks of tactical organisation and decision-making aimed at progressing work for optimal outcomes (effectiveness). At some level – though with widely varying degrees of success – this is universal.
Flow adds something much less common, a sense of smoothness and predictability; addressing impediments to these systematically is a powerful improvement approach, exemplified in Lean.
We also value flow in Csikszentmihalyi’s sense, that very positive state of complete absorption in what we’re doing. This kind of flow is hard to find when distraction, interruption and constantly changing priorities dominate the work environment.
6. Customer Focus
We haven’t finished with “Manage flow” yet! An expanded version of this practice might read something like
Manage to timely completion the smooth flow of customer-recognised value over a range of timescales
Value is meant in the sense of purpose (understanding the customer’s “why”) as much as in any monetary sense (taking care not to confuse utility with mere cost). A customer-focussed concern for completion means going beyond an activity-centric “task complete” or a product-centric “potentially shippable product”. In my experience, this is a surprisingly challenging concept whose impact can be dramatic.
Work done but not yet benefiting the customer is just sunk cost. We’ll return to this issue and address the “over a range of timescales” phrase when we look at the value of balance.
Transparency underpins three of Kanban’s core practices: the first, “Visualise [work]”, the fourth, “Make policies explicit”, and the fifth (another 2012 addition), “Implement feedback loops”.
Kanban creates transparency at multiple levels:
i. In making work visible
ii. In making visible the workflows that work items go through and the states that actual work items occupy at any given time
iii. In making visible the parameters, policies and constraints that guide decision-making and ultimately drive the overall performance of the system
iv. In making visible the impact of all the above in customer-focussed measures of performance
The first two types of visibility flow naturally from the kanban systems after which the Kanban method is named. The first three together create leverage points – points in our systems at which significant change can be effected for relatively little cost or effort. The fourth (a feedback loop) tells us that change is taking us in the right direction.
Kanban then is a way to evolve systems that learn and adapt, a strategy for organisations to find greater fitness relative to the competitive ecosystems they inhabit.
The second core practice is “Limit work-in-progress (WIP)”. Limiting WIP across a process has multiple benefits:
- Thanks to Little’s law, lead times (and therefore feedback cycles) tend to shorten; the customer is satisfied sooner and learning accelerates.
- Work gets started only when capacity becomes available. This creates flow from the work item’s perspective and keeps supply and demand in balance from the team or worker’s perspective (respect!).
- With just a little extra sophistication we can easily find balance between different kinds of operational work and between operational work and improvement work.
This last point suggests another principle, “Embrace variety”. Systems that behave well in the face of variety can be described as having a resilience that is good for customer, organization and worker alike, another example of balance. Kanban’s help in evolving resilient systems that can deliver predictability for a variety of work item types with a range of performance expectations (timescales perhaps ranging from hours or days to months or more) really is a killer feature.
For more on the role of balance in Kanban see David Anderson’s talk When is Kanban not appropriate [video] [slides]. My talk Kanban the hard way [video] [slides] includes an exploration of variety and resilience.
Collaboration features in the sixth (and last) core practice, “Improve collaboratively, evolve experimentally [using models [and the scientific method]]”.
Building on agreement, respect and customer focus, collaboration creates the expectation that we will look beyond our own team’s boundaries in addressing impediments to flow.
The full version of this practice (with the two optional parts included) speaks of working systematically in a way that improves understanding through observation, model-building, experimentation and measurement (empiricism).
“Using models” has a second sense that suggests values of curiosity and even generosity. Kanban actively encourages its practitioners to look outside the method to a growing body of knowledge. Kanban acknowledges roots in Lean, Theory of Constraints and Agile, foundations in queuing theory and complexity science, influences as diverse as Lean Startup and family therapy. Individual practitioners have their own personal favourite models – I for example draw on A3, GROW, and Influencer.
Why stop at nine?
It bothered me that the Lean value of customer focus can’t be inferred in any obvious way from the standard wordings of Kanban’s foundational principles and core practices – you could say that I had to cheat! I think though it fully deserves its place.
Less so these others that I’ve identified:
- Learning and alignment have strong associations with understanding. I fully recognise that a strong case can be made for each of these but I’ve gone with the one that I think best reflects Kanban’s roots in System Thinking. My most-referenced article emphasises learning, so this was a tough one!
- Challenge (also vision) and courage overlap sufficiently with leadership that I don’t regard them as axiomatic. See related post Dole out the 3C’s.
- Self organisation would rank high as an organisational design value but respect seems to be an adequate guide for the change agent. All else being equal, respect would prefer a solution allowing or building on self organisation over one that doesn’t.
- Resilience features strongly in my thinking but it describes outcome more than approach. Smoothness and predictability similarly.
Putting values to work
Let’s see our nine values together then:
Understanding, Agreement, Respect,
Leadership, Flow, Customer Focus,
Transparency, Balance, Collaboration
Admittedly, that’s quite a long list – longer than the initial three or four that I have quoted at every opportunity for some time – but not so long that we’re incapable of debating, remembering and referring to them.
Do any of these resonate with you more strongly than others? What does that say to you? I might explore that one at a leadership retreat – the differences between practitioners might be revealing!
Do any seem to be missing in your current environment? Again, what does that say to you? Does that suggest to you some things that really need to be put right?
For example, I can look back at times where lack of the right kind of agreement either slowed the pace of change or resulted in change that could revert too easily. From what I read, I don’t believe I’m unique in this.
I’ve made values explicit – this is transparency at work – creating an opportunity for challenge (namely that I want to see customer focus feature more explicitly in the core method), and increasing my understanding of at least one source of ineffectiveness. In an eat-your-own-dog-food kind of way, the system works! I like that.
Whether you or the wider community would choose the same values is an interesting question worthy of group exploration. How else might you go about it? I’d love to see some alternative attempts. Could the values I’ve chosen benefit from some additional structure or from being sequenced differently? Or are values so fragile that they’re better left unsaid?
Continuing a line of thought started a couple of months ago in my post How Deep is “How is Your Kanban”, could values provide a better foundation for a second-generation Kanban assessment tool? Does the current tool’s emphasis on practices hide the method’s true purpose? I really think that it might.
As to whether this is a good way to introduce Kanban, this can only be answered by testing it. I intend to!
[Update: I've written some stronger conclusions in a followup post, Values, understanding & purpose]