Small acts of leadership

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!

Progress update on the writing project

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.

Peter Senge on the purpose of Systems Thinking

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

Kanban is like onions!

I find writing abstracts for talks really hard. Here’s my latest – I’m aiming for something that would work whether the event was branded “Agile”, “Lean/Kanban” or something more general. What do you think?

Kanban is like onions!

 

Kanban’s value system can be organised into three layers – a familiar core that drives change, a middle layer that is about giving direction and alignment, and a protective outer layer of discipline and working agreements. Or from the outside in: discipline, direction, and drive.

 

This system (comprising nine values in all) can be put to practical use: it can help us engage more effectively with the organisation as it currently is; it encourages us to self-reflect on our responsibilities as change agents; it provides a convenient framework for the capture of community stories. There is strong resonance too with the unifying ideal of the Learning Organisation, suggesting that this values-based approach may have broader applicability.

 

And here’s a first sketch of the onion. I could give it roots (Systems Thinking, Lean, TOC, Agile etc) and let it sprout leaves (Learning Organisation), but that would be too much, right? Too much for my limited drawing skills anyway…

onion

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.

Three notes from my #lkna13 talk “Kanban through its values”

I’ve published on slideshare the slides for Monday’s talk at Lean Kanban North America 2013.

I’d like to mention three things that won’t be obvious from the deck:

1. Meldstrong

I have created meldstrong, a community site for capturing stories against values and other key topics. Some people worry (quite legitimately) values are too fragile to define; a way around this problem is not to try to define them but to illustrate them by example. I invite you to sign up and start leaving stories that exemplify Kanban’s values in action or show what happens when they’re neglected by organisations or their change agents.

The first story logged there is mine, and it briefly describes the collaboration that went into preparing the talk. I should say here that it understates both the effort put in by multiple people and the depth of my gratitude to them.

2. Bravado

What do you call it when change is initiated without understanding? Deming (after Shewhart, who measured the effect) describes it as tampering. This is often cited in the Systems Thinking, Lean and Kanban communities.

In Good to Great, Jim Collins uses the word bravado. Why focus on a word that describes the decision rather than its effect? I would say that this kind of bravado describes change that is not calibrated to the level of understanding that exists in the organisation. I’m not suggesting that we shouldn’t have a big, hairy, audacious goal (a BHAG), but that we should drive towards those goals through experiments that are (1) safe-to-fail – ie don’t inflict unsustainable damage – and (2) increase our understanding so that we cab me more ambitious in our change increments. Now flick back a few pages to the slides on J curves and evolutionary change. Do you like that connection?

3. Agreement

I remember very well from the late 70′s a campaign run in the UK based on this slogan:

A dog is for life, not just for Christmas

The Kanban version of this quote might be this:

Agreement is not just for the kick-off meeting

Agreement is a process, and it’s key to effective and lasting change. It will be needed with every increment, so practice it, value it! I spend a lot of time coaching around this one.

Who is Kanban for?

There’s just a month to go until Lean Kanban North America (Chicago, April 28 – May 2) and it’s time for a little teaser to my talk Kanban through its values.

Exploring Kanban from the perspective of its values has helped me understand and explain Kanban’s purpose, which in turn makes explaining Kanban much more satisfying. I described some of that thought process here, and how it helped me get from “what Kanban is” to “what Kanban is for“.

At the conclusion of my talk I’ll present a refinement of that statement of purpose (sorry, you’re not getting that here just yet) but there’s a corollary that I will share now, and it answers the question “who is Kanban for?”. I believe that Kanban is for knowledge work organisations that need to learn faster. It may strike you as ironic that there are organisations engaged in knowledge work that don’t learn quickly enough, have lost perhaps the ability or even the will to learn, but it seems to be widespread.

The use or consideration of other methods (Agile or otherwise) doesn’t seem much of a threat when we look at the problem in these terms. It’s not what they’re doing that makes Kanban appropriate, rather it’s the depth and urgency of that underlying need.

When transparency is not enough (or too much)

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.

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.

 

Agreement: it’s not about you

Google this morning gives 62 hits on “agreement” for positiveincline.com. Admittedly that includes some dupes, but it’s definitely an itch I keep scratching. Most recently:

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)?
Introducing Kanban through its values (January 2013)

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).
Kanban: values, understanding & purpose (January 2013)

Where in the assessment tool [is] agreement – “Agree to pursue incremental, evolutionary change” is a foundational principle of Kanban and the organisational scope of any agreement is surely assessable. As a change agent, have I achieved 360-degree agreement? If I have, won’t this help make change “stickier”?
How deep is “How deep is your Kanban” (October 2012)

That last one needs some modification. 360-degree agreement is all very well, but it places me at the centre. What happens when I go away? How much agreement is left? If the agreement is about change, is that change really going to stick? David Anderson this week reminded me that change often fails to survive a generational change in leadership. That’s a sobering thought if you’re in the culture game.

I’m struck by the difference in coaching models aimed at getting to “what will you do now?” and other models (the Triad model [1] is a great example) that are more indirect but no less deliberate. Could it be that we invest too much in getting agreement from other people and too little in supporting agreement between people?

I’m pleased to report that I do see some very encouraging signs of the latter kind of agreement in my own consulting and coaching work. It takes time though! I wish I could give some recent concrete examples, but NDAs & such prevent. One day perhaps.

You may enjoy Jason Yip’s article We agree… but… meanwhile. I did!

[1] See The Culture Game – a book by Dan Mezick – Triads are described about half way through the article, and the book it describes is well worth a read.