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

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?


  • 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!

August 28, 2013


Filed under: Kanban,lean,Values — Tags: , , , , , — Mike @ 1:36 pm

It’s that time of year again, the season of mists, mellow fruitfulness, and a great series of European conferences:

I’m on the programme committee for LKUK13 and I know that there has been stiff competition for speaking slots at all these events. They’ll be great! And every year I’m surprised at how each one manages somehow to find a style all of its own.

Regular readers of this blog will know that 2013 has been for me the year of Kanban’s values. These form the backbone for my new introductory/something-for-everyone talk on Kanban. If you’re new to these ideas, why not come and join me? My talks are usually placed early in the programme so there’ll be plenty of opportunity for discussion afterwards.

June 18, 2013

Small acts of leadership

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

In case you thought leadership was only for other people:

  1. Do something fresh with transparency: try out a new visualisation on someone else; crystallise a pattern or policy out of the decisions you’ve made recently; review your feedback loops
  2. Check your balance: Overloaded? Not finishing stuff? No wiggle room? Too short term? Not enough experimentation?
  3. Foster collaboration: work on a problem with a friend; make an introduction; look at who works with whom
  4. Adjust your customer focus: identify your customer, the customer behind the customer, the deeper need behind their apparent problem, next year’s problem. Talk!
  5. Pay attention to flow: Can you see it? What is stuck today? Where do blockages repeatedly occur? Why is that?
  6. Grow understanding: go and see; share what you found; admit “we don’t know enough yet”; try an experiment (and dare to describe it as such)
  7. Seek agreement: That change you’re involved in… Whose idea was it, who’s implementing it, who’s impacted? All agreed?
  8. Show and expect respect: Do we still have to ask about this one?
  9. Develop leadership in yourself and in others: be an encouragement to someone else in their small act of leadership; share this handy list 🙂

None of these require you to wear a special badge. Try one!

June 6, 2013

Progress update on the writing project

Filed under: Kanban,leadership,lean,Values — Tags: , , , — Mike @ 1:05 pm

I’m continuing to make progress on the “onion” model. I’ve made the case in a previous post for the outer discipline layer comprising the values of understandingagreement and respect, I’ve resequenced the values pages on meldstrong, and I’m part way through the flurry of re-editing that this resequencing has necessitated.

I’ve finished (for now at least) the pages for drive, the inner core with its the more practice-focussed values of transparencybalance and collaboration. I’d love your feedback on those. They should now read less like the script of my Chicago talk and should each be capable of being read standalone.

Next up editing-wise is that middle layer of direction, comprising customer focusflow and leadership. Wish me luck!

If any three of those nine values resonate with you – whether they say to you “Yes that’s me!” or “Ouch, we need more of this!” – can I urge you to sign up at meldstrong and list them in your profile? The more that people do this, the stronger the inferences I can draw from the data. Thank you.

June 3, 2013

Peter Senge on the purpose of Systems Thinking

Filed under: Kanban,leadership,lean — Tags: , , , , — Mike @ 8:21 am

From a recent 5-minute video on John Hunter’s Curious Cat blog:

[The] fundamental rationale for all of this: it’s not to understand systems – that’s an abstraction – it’s to understand how it is that the problems that are the most vexing, difficult and intransigent come about. To get a perspective on those problems that gives us some leverage and insight on what we might do differently.
Peter Senge

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):


and more of this (me, 2013):


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.


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.

March 22, 2013

When transparency is not enough (or too much)

Filed under: Kanban,lean,Training,Values — Tags: , , , , , , — Mike @ 2:26 pm

Maria Alfredéen (one of my behind-the-scenes collaborators on the LKNA13 conference version of Introducing Kanban through its values) recently prompted me to consider the limits of transparency, something most of us in the Kanban community value very much. Could too much of the wrong kind of transparency get in the way of flow, either because we’re looking at the wrong things or because it keeps our attention too narrowly on the concerns of one part of the end-to-end process (and “suboptimising”, the cardinal sin of systems thinkers everywhere)? In other words, can transparency and flow sometimes be in tension with each other?

At the BCS-organised London Lean Kanban Day last Saturday, Clifford Shelley spoke of productivity metrics whose publication would cause more harm than good. I couldn’t help wondering whether they should have been collected in the first place (which I think is Clifford’s view too, though I didn’t verify this). On Twitter afterwards, I discussed with Pawel Brodzinski and Paul Klipp whether the appropriateness and effectiveness of transparency was a function of existing organisational culture, in particular of the amount of trust that pervades the organisation. We had surprisingly different perspectives on that, but I think we mostly agree that transparency does have its limits.

Customer focus to the rescue

Without making major changes to teaching materials, keeping the Kanban value system at the front of my mind when teaching does seem to make a difference. For one recent group, customer focus was the value that seemed to touch the most nerves, got conversations going (both lively and reflective), and influenced even their initial attempts at kanban system design. To me it seems significant that one of the values that doesn’t immediately jump out from Kanban’s principles and practices should have this kind of impact when made explicit.

For example:

  • When identifying work item types and their respective workflows, “Know what you’re delivering, to whom, and why” was the catchphrase (and it stuck – I had it played back to me the next day)
  • When exploring what self-organisation really means – and it’s not “working with people you like” as Dave Snowden joked on Saturday – we saw customer focus supplanting excessive role focus and task focus
  • Sensing near-completed work getting “pulled” towards the customer, this feeling strengthened by the deliberate way we reviewed board designs and later conducted stand-up meetings
  • Considering the positive impact on team and customer behaviour (I’ve seen both) made by introducing post-delivery validation. Did we deliver to the customer’s satisfaction? Is it meeting their needs as hoped? Are we happy that what we did is supportable and sustainable so that the customer and team will stay happy?

Revisiting those conversations on transparency and flow I now wonder: is customer focus the thing that will keep them in balance? I have reason to think so. Seeing work pulled towards a customer whose interests we care about surely puts local efficiency into proper perspective. So too does measuring things that matter to the customer (lead times, predictability, quality) rather than things that don’t (lines of code, hours spent in the office).

I now see customer focus not just as something nice or important, but as one value (of three) that help give processes and process improvement a good sense of direction. Part of an “outlook for improvement” as the current draft of my Chicago talk has it.

February 26, 2013

How complex systems fail

Filed under: leadership,lean — Tags: , , , , , , — Mike @ 7:40 am

From Steven J. Spear’s The High Velocity Edge, chapter 3 – How Complex Systems Fail:

In all the cases that we examined, there were common characteristics that led to painful results. People lacked a systems view – a full appreciation of how the work they did was affected by and affected the work of other people. Granted that, as Perrow pointed out, it was exceptionally difficult to understand all the nuances of how such as complex system worked, but the people in these cases did not advance their understanding when there were warnings that they should have. Rather than push for ever-better clarity as to how things should work, they were exceedingly tolerant of ambiguities regarding who was supposed to do what, how to convey information from one person to the next, or how to perform a particular task. And even when it was obvious that something was wrong, they worked around the problem, relying on extra vigilance and extra effort. Thus they imposed on themselves the same set of problems day after day, constantly turning down the chance to understand the complex interactions of people, technology, place and circumstances better and thus improve the system as its flaws were discovered.

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.


« Newer PostsOlder Posts »

Powered by WordPress