Positive Incline Mike Burrows (@asplake) moving on up, positively

June 3, 2014

“How deep” rebooted: values-based depth assessment

Filed under: Kanban,leadership,Uncategorized,Values — Tags: , , , , , — Mike @ 3:23 pm

[Update 1: do read this post in conjunction with the previous one—Pulling change through the system—I don’t make it clear enough here that the purpose of the assessment is to help generate priorities for change]

[Update 2: the assessment tool has come a long, long way since the version still downloadable from here. Do yourself a favour and go to agendashift.com to use the latest version online.]

It’s fair to say that I have a complicated relationship with the Kanban Depth Assessment tool. With some excitement, I tweeted this picture from the 2102 Kanban Leadership retreat:

A few months after that tweet, I blogged How Deep is “How Deep is Your Kanban”?. Fortunately, I was able to channel my frustrations into something positive, and the eventual result was Introducing Kanban Through its Values.

Meanwhile, I find the tool useful in practice, even if flawed. That’s awkward!

Two years on from the Mayrhofen retreat we’re in Cascais, Portugal for this year’s retreat (#klrpt), and I have the opportunity to test a values-based realisation of our original idea, which I drafted only last week for the final chapter of my book (yay!).

Focusing on outcomes more than benefits, I asked participants to identify and categorise aspects or features of systems they would expect to see in mature Kanban implementations. This picture shows just a small selection:

2014-06-03 12.44.06

(I should explain that “Leadership & the Leadership Disciplines” pragmatically lumps together leadershipunderstandingagreement, and respect. I was actually rather gratified that Pawel Brodzinski expressed the concern that I didn’t give them sufficient individual prominence.)

Now for the measurement part. Sebastian Sanitz presented the Agile Fluency Model (Diana Larsen and James Shore), which uses a simple four-point measurement scale; Sebastian used the metaphor of learning a new language to explain what the different points on the scale feel like.

Since this morning’s workshop I have replaced my prototype’s ten-point scale with this more well-defined four point scale:

  1. Our system exhibits this aspect barely, if at all
  2. Our system is somewhat capable of exhibiting this aspect
  3. Our system exhibits this aspect convincingly, for the most part
  4. Our system departs from this only very exceptionally, understanding and managing the consequence when it does

These are applied per aspect; there are typically half a dozen or so of these per value category. I aggregate results within each category using a geometric mean (compared with a simple arithmetic mean, this gives more weight to lower/weaker scores, ie the aspects likely to be in most need of attention).

You can download the spreadsheet here: values-based depth assessment.xlsx. Some screenshots of the assessment worksheet and the radar chart visualisation are shown below. For the book, I will incorporate a time-based view from Ruben Olsen.

Screen Shot 2014-06-03 at 15.05.42

 

Screen Shot 2014-06-03 at 15.07.24

I honestly believe this to be an improvement on the old tool, but I know that there will be those that would still prefer to see it based on a checklist of low-level practices. I’m afraid to say that you’re unlikely to get that from me! Still, I’d be grateful for feedback, soon enough that I can accommodate it before the book’s publication (September, fingers crossed). If it takes additional work to separate the tool from the book—context matters, after all—that’s fine.

February 21, 2014

My InfoQ series on Kanban’s agendas, Agile India 2014, and some overdue thanks

Filed under: Kanban,Values — Tags: , , , — Mike @ 3:57 pm

Over the past few weeks InfoQ has published a series of three articles I’ve written on Kanban’s agendas. Older articles don’t link to newer articles so I list them here in order:

  1. The sustainability agenda
  2. The service orientation agenda
  3. The survivability agenda

Some thanks are overdue. Luke Hohmann (who saw a very early draft) and Ben Linders (InfoQ editor) weren’t just encouraging (which they were), they rightly insisted that I had some work to do. Quite a bit of work as it turned out, but for their thoughtful and at times robust comment I’m very grateful.

Next week I’m speaking at Agile India 2014 in Bangalore, on the Scaling Agile Adoption Track (day 1, Wednesday afternoon). Values and agendas might just get a mention! Here, Ellen Grove deserves a thank you for requiring me to address the challenges of scale more directly.

Working in parallel on talks, short posts, longer articles and the book really works for me. The trick now must be to finish the book before I find yet another avenue to explore!

September 16, 2013

Stand up meeting, thinking tool, leadership routine

Filed under: Kanban,lean,Values — Tags: , , , , , , , — Mike @ 11:47 am

My last post was on the provocative side; to restore this blog’s usual balance, here are some antidotes to some of the problems I described. These are ways to use your kanban board to help you look at your process from the perspectives of customer focus and flow, two values from that middle direction layer.

Imagine you’re facilitating a stand-up meeting in front of your board. If you have a physical board, you’re probably heading (in your mind at least) towards the board’s right hand side so that you can stand looking left across the board. If you use an electronic kanban tool, you can achieve a similar effect by turning your laptop or monitor monitor to the left a bit (ok, I’m kidding).

Now scan the board from right to left (in other words working your way backwards from the end of your process towards the start) and ask these questions of the columns:

Customer focus:

  • Whose needs are explored in this stage of the process, and how? Whose aren’t, and what risks does that pose?
  • What do we learn in this stage that we don’t (or can’t) know earlier? In what ways do the activities of this stage help us anticipate what will be needed?
  • What is still to be learned? Are outstanding uncertainties best dealt with by pressing on or by going back?

Flow:

  • How do work items leave this stage in the process? By what criteria do we know that they’re ready? How are those criteria expressed? How is the state change communicated?
  • Typically, how much time do work items spend in this stage? How much (if any) of that time is spent in active work?
  • What are the most significant sources of unpredictability? In the work in or the waiting? Waiting for internal availability or for external dependencies to be resolved?
  • How much of this stage’s capacity is absorbed in rework? Or in failure demand, which arrives only because previous work failed to meet customer needs adequately?
  • How do work items arrive into this stage? How do we know that they’re ready to be worked on?

You may find it helpful to ask some of these questions of individual work items too.

What we’ve done is to turn a popular protocol for standup meetings into a thinking tool. You can try it with other values, for example transparency (is it sufficiently clear what’s going on here?) or balance (are we overburdened here?), or some other concern that seems relevant.

Caution: questions like these already assume the following:

  1. That the process has sensible objectives (to deliver the right kind of things)
  2. That the work flow is scoped sensibly (starts with the right kind of questions, finishes with the right kind of result)
  3. That the work flow is organized sensibly (sequenced to generate high value learning as quickly as possible)

I’ve encountered plenty of processes where these assumptions are open to challenge. For example:

  • A change management process whose objective was the approval or rejection of design changes, disconnected from any actual implementation process. Needless to say, any customer satisfaction delivered out of that process was somewhat short lived.
  • My bank’s account opening process. A frustrating process and several weeks later and I still don’t have online banking, let alone two additional products that I would be willing to pay for. I sense an institutionalised lack of curiosity into my needs and what might be in the way of delivering on them.

Some acknowledgements are in order:

  • The first set of questions questions are heavily influenced by Michael Kennedy and the model of the Knowledge Discovery Process. That’s a Lean product development model, but I find that many processes are usefully understood in those terms.
  • The “whose needs?” questions (the first bullet) point to the very important question: “who holds a veto on delivery?”. This is one of many good customer focus takeaways from Lean Software Strategies by Peter Middleton and my friend Jim Sutton.
  • The idea of understanding a process by walking through it backwards is an old Lean trick. I don’t know for sure how it was discovered and popularised, but Steven Spear describes very well its use as a leadership routine inside Toyota in his book The High-Velocity Edge.
  • Failure Demand is a concept I associate (in the nicest possible way) with John Seddon.

These are all great ideas. Combining them with visual management and practised routine makes them (as well as the values) accessible and actionable, don’t you think?

September 11, 2013

Is this Agile’s Achilles’ heel?

Filed under: Kanban,leadership,lean,Values — Tags: , , , , , , — Mike @ 12:27 pm

I’ve been refreshing my talk on Kanban’s values and I paused – as my audience is invited to do – on the middle layer of the “onion”, the direction layer of customer focus, flow and leadership. Then it struck me: it’s in this layer where the alignment with Agile seems the least comfortable.

For the inner layer (drive), it’s very easy to find Agile practices that support the values of transparency, balance and collaboration; that’s an exercise I often lead audiences through. The outer layer (discipline) is interesting but relatively uncontroversial. Understanding, agreement and respect: how would you expect to succeed without those?

But look closely at direction. Could this be where Agile implementations lose their energy or come unstuck? Could it be that this is Agile’s Achilles’ heel? Looking at its three Lean-inspired values in turn:

  • Customer focus: How many Agile implementations are team-focused or technology-focused, lacking in external perspective? Does the identification of the Product Owner (PO) role encourage customer focus to be confused with product focus? How often does the customer get relegated to a source of raw material for the machine, expected to serve it instead of being served?
  • Flow: Yes, rhythms are important. In their right context, timeboxes are indeed powerful. But to place them on a pedestal, to deny the benefits of decoupling input, output and control rhythms, to fail to see smoothness as something worth striving for… Well, you get the picture.
  • Leadership: It seems to me that the obsession in some quarters with bad management makes it harder for others to talk about good leadership. Add to that an industry built around managed Agile transition, roles with “Master” and “Owner” in the title, confusion about the meaning of self-organisation, and so on. What a mess!

In short: confusion, contradiction and conflict where what’s needed is direction.

If you’re doing a better job of anticipating and delivering on your customer’s needs, that’s meaningful improvement, very likely a meaningful indication that you’re moving in the direction of increased agility.  If the flow of work is faster, smoother, more predictable and less burdensome, likewise. And clearly it’s important to sustain these things, so organisational capability must be an improvement focus in its own right.

Keep making progress on these things in tandem, and it’s clear that you will keep delivering benefit to the customer, those inside the system, and the wider organisation. I would go as far as to say that when so-called improvement is at the expense of one of these groups, then you have to ask whether it is really an improvement at all. Direction matters.

You don’t have to buy in to the Kanban method to see and accept this. But it is a very good starting place; it’s the humane, start with what you do now approach to change, an alternative path to agility. And it’s not confused!

May 22, 2013

Making a case for “leadership disciplines”

Evoking the 70’s bumper sticker “A dog is for life, not just for Christmas“, I suggested in my last post that

Agreement is not just for the kick-off meeting

Let’s extend that thought to the first group of Kanban’s values. What if we positioned understandingagreement and respect not as initial conditions for a learning environment but as leadership disciplines expected of everyone who has responsibility immediately around it?

Putting Kanban to one side, what would your Agile implementation or other significant change initiative have looked like had there had been sustained outside commitment to the following principles:

1. Understanding is a prerequisite for effective change

  • Change will be based on an understanding of genuine problems or opportunities, framed such that upsides and downsides can reasonably be demonstrated and managed
  • Change increments will be sized according to our understanding, safety never compromised (recalling J curves, bet-the-company bravado and so on)

2. Agreement will not be taken for granted

  • Change will be implemented through agreement between those (or between representative of those) who
    • request or recommend change (the instigators)
    • understand what needs to be done and estimate its impact good and bad (the designers)
    • will implement it
    • will be impacted by it

    Clearly, the more these groups overlap, the easier it gets.

3. Respect is a key test

  • Each change will be conducted respectfully
  • Collectively, change will
    • remove sources of frustration and other barriers to success
    • raise levels of trust and safety
    • create the space for creativity and excellence

What if the “skin” of your “culture bubble” was made up of a group of people who are committed to using their authority to represent and defend those three values? What effect would that have, both on the team and on the wider organisation? Rather than those inside the bubble, perhaps it is this group that should be our first concern?

If not our first concern, then at least a different concern. A focus on leadership discipline at the boundary that promotes change inside in the direction we want (including but not limited to customer focusflow and leadership), sustained internally by the drive of the more practice-focussed values of transparencybalance and collaboration.

It strikes me that this formulation (a minor refinement to the model I presented in Chicago) begins to tackle two common misgivings around Agile and Lean.

Misgiving #1: Hierarchy vs collaboration

This misgiving is most commonly associated with Lean, although similar misgivings are sometimes expressed about Agile, in particular around the Scrum roles. How can an apparently hierarchical management system be reconciled with a culture of collaboration?

Let’s be clear about one thing: I have no interest whatsoever in replicating a shop-floor management hierarchy with its team leads, supervisors and so on. But what about leaders already at the periphery of the change initiative? If they’re expecting to see understanding, agreement, and respect and have learned to live those values themselves, won’t that have an effect? I see this expectation catalysing creative collaboration inside the boundary and facilitating collaborative problem-solving across it (thereby growing the initiative’s scope). Doesn’t this give a good picture what the effective leader (or manager) as coach looks like?

To further illustrate the potential for de-emphasising hierarchy, let’s see less of this (me, 2012):

alignment

and more of this (me, 2013):

change-team

Perhaps hierarchy is like iteration – just as it’s interesting and useful to see how far we can take these ideas (many people now assuming that they’re axiomatic to Lean and Agile respectively), it’s also interesting and useful to describe and explore universes that don’t depend on them quite so fundamentally.

Misgiving #2: The “mindset get-out clause”

I have long wished to challenge those who say that Agile can’t work here because the organisational mindset is wrong (or that Lean failed for the same reason). I find this chicken-and-egg excuse hard enough to swallow when expressed with genuine regret; when it’s accompanied by disrespect (of which “pigs and chickens” is but a mild form) I despair!

If we’re agreed that an incremental, evolutionary approach makes sense both for product development and process improvement, wouldn’t it make sense to approach mindset and culture in the same way? With some kind of plan of attack maybe?

Here’s my starting approach in two steps:

  1. Find the skin of the bubble: I’ve learned the hard way that improvement that isn’t end-to-end is often futile; reaching out upstream and downstream is therefore essential. It’s also natural for me to reach out (or up, if you like) to managers – I was one myself and I have no difficulty in identifying with them.
  2. Speak there the language of values: Don’t just gain an understanding of the problem for yourself; insist that shared understanding and agreement are essential, that respect is both a means and an end, and that their discipline as leaders will be critical not only to initial wins but to lasting success. Then explore the other values as you seek alignment between external and internal goals. Balance was for example a key theme of the early part of my last engagement, moving later into transparency and customer focus.

Real life is of course a little messier than I’ve described but I’m glad to have crystallised much of what I’ve been doing over the past few months.

Acknowledgements

Joshua Kerievsky for broadening my understanding of “safety” (see #techsafety) and Liz Keogh for “respect is a test”, both at #LKNA13Michael Sahota for “culture bubbles”; Steven J Spear whose book The High Velocity Edge (mentioned here) is still exerting its influence.

I’m grateful also to Jim Sutton and Martin Burns for feedback on earlier drafts of this article.

February 11, 2013

Hear me interviewed on SPaMCAST

I had the pleasure last month of being interviewed by SPamCAST’s Tom Cagley. It’s now up as SPaMCAST 224 – Mike Burrows, Kanban Values. I’ve never appeared in a podcast before and I’m very pleased with the result. Thank you Tom!

I reference these posts:

We touch on some more general aspects of leadership, on what it means to be a change agent, and on why some improvement efforts are ineffective. It may become apparent that the issues raised by “Potato, tomato” and “Agreement: it’s not about you” were on my mind at the time too.

London Lean Kanban Day deserves a link after I described it rather vaguely as being “in London, in March”. I’ll be doing a new version of “Kanban the Hard Way” that (naturally) features values. It’s not quite a values-centric talk – that’s in the works for LKNA13, more on that soon.

 

January 27, 2013

Potato, tomato

Filed under: Kanban,lean — Tags: , , , , , — Mike @ 10:18 pm

I tend to avoid direct comparisons between Kanban, Lean, Agile in general and Scrum in particular. One reason for this is terminology – dialogue is hard enough when opinions are strongly held, but try to engage in it when there is confusion over language! Ouch!

That’s the background to this rather cryptic tweet (watch out for another one later):

Here then are some working definitions that I use. Think about how you use these terms; perhaps that in itself could be the starting point for an interesting conversation.

Self-organisation, self-management

Self-organisation is what’s happening when systems reconfigure themselves in response to environmental change, without external direction. Often associated with resilience, it’s a phenomenon frequently observed in nature and in a wide variety of social systems.

A team could reasonably be described as self-organising if it adjusts its structure or process when faced with conditions outside of the norm (that’s an example, not a definition by the way).

Self-management describes an ability of people, teams or systems to manage or regulate themselves.

A team that prioritises its own work in some predetermined manner and can be relied upon to produce some output in a predictable manner with a minimum of outside intervention can justifiably be described as self-managing. We all know inviduals who are like that too. Again, this is not a definition.

Teams can be either, neither, or both of these. When neither are present, we can expect ineffectiveness (lack of direction or failure complete), inefficiency (the team – by choice or otherwise – is highly dependent on people outside of it) or fragility (no expectation that change will be met positively).

A well-functioning Scrum team encourages both self-organisation and self-management by setting clear boundaries for the team and defining certain roles within the team. Kanban encourages us to make process constraints explicit and evolvable whilst allowing freedom of choice within them. Two approaches that are at the same time very different and yet surprisingly similar in purpose. Mutually exclusive? No!

Increment, iteration

An increment is a piece of work or change that is both meaningful from the recipient’s perspective but still small relative to the whole. Loosely, an incremental delivery approach means that we aim to deliver what we can when we can, in (say) shippable features. Predictability is achieved through (amongst other things) careful sizing and attention to flow.

Iteration is about repetition. Loosely, an iterative delivery approach is one in which we aim to deliver as regularly as we can. Predictability is achieved through (amongst other things) careful attention to commitment.

Within a process we often see elements of both approaches. Towards the input and outputs of a process however we tend to see one dominate over the other. We might see for example regular prioritisation meetings at the input and continuous delivery at the output. Conversely, requests might just arrive when they do but releases are according to a fixed schedule.

Over long enough timescales, either approach is capable of supporting evolutionary delivery, in which the key driving force is feedback from the customer or market. In both cases, we may also see evolutionary change happening to the process itself, perhaps to a degree that implies a change of delivery approach.

I bring these up because of the seeming near-identification of Agile with Scrum and iterative delivery in the one hand, and the equally simplistic identification of Kanban with incremental (or continuous) delivery on the other. When I see authors equate Agile with iterations and put up Kanban as a direct alternative, I despair at the sloppiness. Are they really that uninterested?

Potato, tomato

After excellent bread, the humble potato is my carbohydrate of choice. Like Rabbi Lionel Blue (this reference identifies me as a long-time listener of BBC Radio 4’s Today programme) I would happily eat boiled potato with a side order of potato salad and call it a good (if slightly unbalanced) dinner.

Through my childhood, I ate tomatoes almost exclusively in ketchup form. I now enjoy them in a variety of processed and unprocessed forms. Often in combination with potato.

The shock of the different

Does it come as a shock that things can be different and yet not mutually exclusive? Good together, even?

Time for another cryptic tweet:

That was almost a year ago. If I were to tweet that again, I would pick up a baton thrown down by Torbjörn Gyllebring and give it the until now unused hashtag #andban.

The Kanban method is not a delivery process, it’s an evolutionary method that works with your process, whether that’s iterative or incremental, Agile or not. Applying Kanban will very quickly tell you things about your process, help you understand it better, help your organisation learn and improve. Potato, tomato.

January 8, 2013

Kanban: values, understanding & purpose

Filed under: Kanban,leadership,lean,Values — Tags: , , , , , , , — Mike @ 8:45 pm

I’ve had a fantastic response to my previous post, Introducing Kanban through its values – it seems to have resonated with a lot of people. Followup discussions in a number of places over the past few days have helped me take the ideas a little further on and finish with some extra clarity.

Here then is the conclusion that I wasn’t quite ready to reach last week. I hope it both satisfies those who expressed disappointment that learning didn’t make my final list and reassures those who worry that values are somehow too fragile to write down.

Values

Kanban has at its heart a value system that includes Understanding, Agreement, Respect, Leadership, Flow, Customer Focus, Transparency, Balance & Collaboration.

Having this list as a commentary on Kanban’s principles & practices is helpful at three levels:

  1. We can cross-check and perhaps reframe (e.g. for teaching purposes) our understanding of the method. As it turns out, this reconciliation will pick up areas where perhaps the method definition itself could usefully be strengthened, though that wasn’t in my mind at the beginning.
  2. At any given time, we can use them to help us reflect on where we are as change agents and validate the approach we’re taking on the ground. This may heighten self-awareness &/or help identify areas of risk or weakness (as it did for me, though retrospectively).
  3. It identifies some characteristics of learning organisations (in the sense of, say, Peter Senge) that Kanban helps to foster. I don’t mean (as some have worried) “Kanban defining for me my company’s values”, but it suggests some good things to expect and encourage, as implicitly or explicitly as your situation demands.

A note of caution: at any level, don’t expect anything good to come from espousing values inauthentically. When in doubt, understand and reflect first.

Purpose

Some time after identifying that third level I had a lightbulb moment: we often say what the Kanban method is (an evolutionary approach to change) without saying what it is actually for! Change what? To what end?

Let’s fix that then:

The Kanban method is an evolutionary approach to building learning organisations.

Put like that, learning is right up there in Kanban’s purpose. That’s a relief! In retrospect I might have done well to start there but I’m journalling my thinking process as honestly as I can.

Interesting Addenda

On agreement, Greg Brougham brought to my attention Ackoff’s distinction between agreement in principle (a theoretical kind of agreement) and agreement in practice (an agreement to live with the consequences of a decision, accepting that agreement on “better” can be effective where consensus on perfection is impossible).

David Anderson would add Pragmatism (with a big P), referring to a philosophical tradition that describes a process in which theory is extracted from practice and applied back to practice. I expect we’ll see that one again.

Doing some blog archaeology, I revisited my Kanban in a nutshell post (March 2010) and confirmed that I took the same tool-first (or worse, tool-only) approach that I worried about in last week’s post. Health warning needed! I’m relieved to find that Learning together (June 2010, a collaboration with Jabe Bloom looking at Kanban and Agile principles) came not too long afterwards

Acknowledgements

I really do value collaboration, and I’m grateful (proud, even) to have these as collaborators: Dave “Value System” White, Arne “Learning” Roock, Hermanni “Understanding & Purpose” Hyytiälä, Patrick “Variety & Resilience” Steyaert and Jabe “Learning Together” Bloom. David “Leadership” Anderson has on multiple occasions actively encouraged me to pursue lines of thought or language even when they seemed to be in conflict with his. And if you tweeted, left a comment, posted on kanbandev or Google+ or in any other way encouraged me to explain myself better, thank you.

January 3, 2013

Introducing Kanban through its values

[German translation]

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: understandingagreement,  respect and 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): transparencybalance, flow and collaboration. However, I found it helpful to depart from the this obvious sequence and was compelled to add an additional one – customer focus – 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). These however are less important, less axiomatic, less “core”.

Nine core values of Kanban

1.    Understanding

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.

2.    Agreement

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.

3.    Respect

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

That kind of respect takes courage, taking us to our next value.

4.    Leadership

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.

5.    Flow

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.

7.    Transparency

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.

8.    Balance

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.

9.    Collaboration

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.

Reflection

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]

December 27, 2012

My 2012 in books

I’ll get to my book of the year in a moment, but I begin with the two books that have had the most direct influence on my work in 2012.

The first is Coaching for Performance: GROWing Human Potential and Purpose: The Principles and Practice of Coaching and Leadership by John Whitmore (2009). I’ve been using the GROW model described in this book not just as a coaching tool but as a gateway to A3, really appreciating its teachability, memorability and its reminders of the importance of framing and challenge.

Like the first, the second is new to me but not a new book. From Lean Software Strategies: Proven Techniques for Managers and Developers by Peter Middleton & James Sutton (2005) I have taken away a much stronger appreciation of the word customer, and I find myself repeating its advice often.

My book of 2012

I choose Paul Tough’s How Children Succeed: Grit, Curiosity, and the Hidden Power of Character not because it’s still fresh in my mind but because it’s a book that I hope will be read widely. Readable, thought-provoking and inspirational, it’s a book for anyone with an interest in the relationships between environment, learning, character and life prospects. That should be most of us.

For the benefit of UK readers I should mention that I had to import it from the US but it will be available here in paperback next month.

Honourable mentions

I approached How to Measure Anything: Finding the Value of Intangibles in Business (2010) with some caution, the title preparing me for a book that might be overly analytical and worryingly money-centric. Instead, it’s a broad, insightful and practical book about making decisions and managing risk in the presence of uncertainty. I’m delighted that the author Douglas W Hubbard will be a keynote speaker at the 2013 Lean Kanban North America (#lkna13) conference.

Turning to fiction, I’m grateful to Dave Snowden for introducing me to anthropology-cum-science-fiction author Ursula le Guin.  Since reading The Dispossessed (1974) in preparation for the CALMalpha event I’ve enjoyed a number of her books, sharing some written for younger readers with our foster daughter.  This one remains my favourite though – I was genuinely disappointed that it had to come to an end! As a sci-fi fan, how did I not encounter le Guin previously?

Thinking, Fast and Slow by Nobel laureate Daniel Kahneman was for many reviewers a best book of 2011 and I got round to it in 2012.  Well worth the effort.

The surprise package

I carried around a review copy of Agile Project Management for Government: Leadership skills for implementation of large-scale public sector projects in months, not years in my suitcase for several weeks and was more than a little surprised and humbled to discover my name listed in the acknowledgements! It’s not an easy topic topic, but author and fellow Agile North speaker Brian Wernham has done a good job of drawing out valuable lessons from reference projects around the world and calling out the kind of leadership necessary for project delivery in the public sector to improve.

Since first meeting Brian I have myself joined a large public sector programme so the arrival of this book turned out to be very timely. I should get round to a longer review in the New Year.

Next up

Top of my list for next year (already purchased and downloaded onto my Kindle) is The Culture Game: Tools for the Agile Manager (2012) by Daniel Mezick. Do you confront culture and mindset head-on, or regard them as something emergent? That has been a favourite conversation topic on Twitter and in conference bars and I’m really looking forward to reading Dan’s take on this.

« Newer PostsOlder Posts »

Powered by WordPress