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

April 24, 2015

Kanban from the Inside: 11. Systems Thinking, Complexity, and the Learning Organization

Filed under: Books,Kanban — Tags: , , , , , , — Mike @ 12:02 pm

This series of short excerpts from my book, Kanban from the Inside has reached Part II (Models). For the next few chapters we look outside to other important bodies of knowledge.

I’m not going to reproduce here chapter 11’s tour through Systems Thinking and related fields—I’ll jump straight to some of my conclusions. If they leave you hungry for the detail, you’ll have to read the book!


The Method’s Design

Several elements of the Kanban Method have their roots in the models outlined in this chapter. In particular:

  • The transparency practices (Chapter 1) create new leverage points, making the system more open to challenge and improvement. Furthermore, they can promote self-organization, a strategy for resilience in the presence of uncertainty.
  • Core practice 5, Improve collaboratively, evolve experimentally, connects collaboration (Chapter 3), knowledge, experimentation, shared learning, and evolutionary change.
  • Kanban shares with Lean (Chapter 13) a Systems Thinking approach to leadership (Chapter 6). In the long run, organizations get the leadership they deserve, the kind that their system recruits, encourages, and promotes. It follows that the most enduring organizations are those that have paid attention to this.
  • Albeit implicitly, the first foundational principle, start with what you do now, points both to Systems Thinking and to evolutionary change. I’ve added some extra emphasis by abstracting from this principle the understanding value (Chapter 7)—the goal is for organizations to value understanding and to have the discipline to make it the precursor to change.
  • Evolutionary change is explicit in the second foundational principle, agree to pursue incremental, evolutionary change (see Chapter 8, agreement).

Earlier chapters have made it clear that the Kanban Method leaves room for interpretation. This is a strength. It is articulated sufficiently clearly for a community to rally around it, yet it is applied with sufficient diversity that its community continues to learn, to develop lower-level practices, and to share experiences. It is satisfying to observe that the Kanban community itself demonstrates in some measure all five of Senge’s characteristics of the Learning Organization.

Application

Neither Kanban nor Systems Thinking should be one-off exercises or specialist, “ivory tower” disciplines that are kept separate from where the “real work” is done. John Gall advises this (sometimes known as Gall’s law):

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system[1].

Don’t worry that every step must be right first time. Keeping the system in motion with safe-to-fail experiments, there’s a limit to how much harm any one step can do, and any local difficulties will soon shake out. Under these conditions, suboptimization—the localized improvement that makes things worse globally—is less a problem than the loss of momentum caused by fear of it. “The perfect is the enemy of the good,” as they say.

[1] Gall, John. 2003. The Systems Bible: The Beginner’s Guide to Systems Large and Small, 3rd ed. Walker, MN: General Systemantics.


Next up: 12. Theory of Constraints (TOC). Previously: 10. Patterns and Agendas. Start from the beginning: 1. Transparency.

November 11, 2014

STATIK, Kanban’s Hidden Gem (my #lkce14 talk)

Filed under: Kanban — Tags: , , , , , , , — Mike @ 2:19 pm

[Updated – see end of article]

The 2014 autumn conference season closes with Lean Kanban Central Europe 2014, one of my favourite events of the year. My talk expands on the STATIK part of last week’s keynote.

It starts with the underpants gnomes, who (like many) might implement Kanban thus:

  1. ???
  2. Put up a board
  3. ???
  4. Profit!

It finishes with purpose:

Know what you’re delivering, to whom, and why

For at least one audience member, the key slides are in the middle, slides 33-34. I described as “a little old fashioned” the idea that we deliver incrementally in order to get feedback. As per last week’s keynote, we need to be validating relentlessly right through the process; only then can we hope to anticipate customer needs. The change to “hypothesis driven development” isn’t just a change of jargon!

Statik, Kanban’s hidden gem from Mike Burrows

Update: This sketchnote captures slide 50 beautifully:

Sketchnote

I wish I could do that!

September 18, 2014

A process of knowledge discovery

Filed under: Kanban,leadership,lean,Values — Tags: , , , , , — Mike @ 3:32 pm

Creative knowledge work is a process of knowledge discovery. You might say that this statement goes a long way to define creative knowledge work and let the rest be left the imagination, but there is still plenty to be said about the process of knowledge discovery.

In Kanban from the Inside I make 16 mentions of “knowledge discovery” – clearly it’s an important term! They are concentrated in these chapters:

  • 4. Customer Focus, about the value
  • 10. Patterns and Agendas, which introduces the Kanban Lens
  • 20., 22., and 23., which take us through the STATIK implementation steps Model the Workflow (aka Model the Knowledge Discovery Process), Design Kanban Systems, and Rollout respectively

The presence here of the customer focus value is a clue that I leave precise technical definitions to others. Instead, I describe the coming together of attitude and actual practice, which (in general) values encapsulate superbly. My conclusions could be summarised as follows:

  • Aim not merely to take orders or to satisfy requirements, but instead to anticipate and meet needs at the right time
  • Be humble about how little you really know; proceed accordingly
  • Be humble about how inadequately your process uncovers needs; help it to adapt
  • Even after delivery, expect to learn more about how needs are being met; validate!

In short—and with apologies to Stephen Covey—begin humbly with the undiscovered need in mind.

I use the word “humbling” every time I retell the story of my first introduction of an explicit post-delivery validation step. Tired of seeing my teams deliver against unneeded requirements, I insisted on it out of pure frustration and with a “that will teach them” kind of negativity, aimed mainly but not exclusively at our customers. The effect on the whole process was however nothing short of profound; the end result being real collaboration at every stage of the process!

Nowadays, and with the advent of the likes of Lean Startup and Lean UX in which validation is formalized, we know that a commitment to validation is a highly repeatable way to catalyze a shift from requirements-driven to hypothesis-driven development. The Kanban Method doesn’t make this commitment explicit, but it is a widely recognized practice fully in keeping with the customer focus value and the core practices of “Manage flow” and “Implement feedback loops”. And for me personally, there’s no going back.

 

October 4, 2013

My notes for the Portfolio Management panel at #lkfr13

Yesterday I had the privilege of sitting on a panel on the subject of portfolio management at Lean Kanban France. Our facilitator was Thomas Lissajoux and my co-panelists were Ian Carroll, Chris Young and David Joyce.

Thomas did us the great service of asking for some notes ahead of time. I found his headings really helpful, and I’ve decided to share my notes. And here they are…

How would you define ‘portfolio management’?

I see portfolio management as managing at that kind of level where maintaining the right balancing between competing projects is as big a challenge as any individual project.

What are the specifics of a lean/agile approach?

Depressingly, I see too many people talk about portfolio management like it was a sausage factory. The story goes like this: “just pay attention to the quality of ingredients going into the machine and success is guaranteed”. I doubt that this metaphor works very well even for sausages!

A lean approach means several things:

1)     Paying attention to the balance of demand and capability (supply), managing WIP relative to capacity and relative to lead time aspirations

2)     Paying appropriate attention to flow, because speed, predictability and timeliness matters (to the extent that there are economic penalties when we get these wrong)

3)     Expecting the way we manage the portfolio to keep evolving. That evolution needs to have some positive effects at project and organisational level that customers will recognise and appreciate, and there needs to be effective feedback in the other direction too (success and failures at project level should generate portfolio-level learning).

In which context/clients do you do portfolio management?

I’ve twice been in the role of portfolio manager myself, once with a $XXmillion annual budget, the second time at a smaller scale but with wider organisational impact.

Nowadays as a consultant I find that many problems on the ground point back to problems in portfolio management. Parts of the process get overwhelmed, and the organisational feedback loops aren’t fast or capable enough avoid real pain and cost. I’ve seen extreme cases where the whole portfolio seems to be grinding to a halt (there are reasons why this happens, a topic for another post maybe).

What about the previous situation and its shortcomings?

In many organisations, to get a project started it’s enough merely to sell the idea. The capability of the organisation to deliver and the impact on existing work is not given much consideration.

What key practices/tools/artefacts/meetings/metrics do you use?

  • The sheer number of projects (relative to the capability to manage them effectively)
  • Their value (with an understanding of the relationship between value and urgency)
  • Planned, potential and actual burn rates (making sure we have the capacity to deliver; too often the sum of all promises doesn’t match the sum of available effort)
  • Lead times
  • Amount of work in certain key states
  • $WIP

Tool-wise I’ve had success with

  • A3, as a means to test project rationale
  • Changes to portfolio reporting (feedback loops)
  • Customer validation – for its own sake and as a catalyst for process change
  • Regular customer meetings (cadenced)

What about the Kanban principles and practices at portfolio level?

They need to be applied with imagination. Add the phrase “Find ways to…“, perhaps “Find multiple ways to…”.

Core practices:

  • Find (multiple) ways to visualise work at portfolio level (transparency).
  • Find (multiple) ways to limit work in progress at portfolio level (balance).
  • Look at how policies can drive better portfolio performance (transparency again).
  • Pay attention to the feedback loops (and again!)
  • Keep improving and evolving (collaboration)

Foundational principles (or rather, their underlying values):

1)    Understanding: Make sure change is based on genuine understanding of how things work now, taking both internal and external perspectives

2)     Agreement: Always have the right people (ie those with a stake in the solution) solving problems at the right level, seeking agreements that will hold in practice

3)     Respect: the first two, plus creating the expectation that improvement will benefit people, not just the numbers

4)     Leadership: grow the next generation of portfolio managers (growing yourself in the process)

Additionally I would add that the portfolio mindset and Kanban are really complementary. Identify

  • different kinds of projects
  • different risk profiles
  • different stakeholders
  • different budgets/appetites

Make these dimensions visible (I mean an in-your-face, Kanban’s-killer-feature kind of visible, not just a filter on a report), aim for a healthy mix of work. With success comes trust in both your ability to deliver and the underlying principles and techniques that make it happen.

What challenges did you face?

Pretty much everywhere, far too many projects and projects that take far too long to deliver.

  • In one company, more projects than there were people, not just in IT but in the whole company!
  • In another, projects taking multiple years, little thought given to the possibility of incremental delivery

What key advice would you have for ‘change agents’ about to dig into portfolio management questions?

  • How is demand managed against capability?
  • Are lead times too long? (a very different question to the one of whether projects are late – dates tend to be genuinely critical on no more than 20% of a typical portfolio – though the long projects tend also to be ones most prone to delay)
  • Can you put a value on the amount of WIP (I refer to this as $WIP)? High shock value!
  • Another great metric once you understand it: What is that WIP costing in delayed business opportunity and delayed feedback?
  • Is the typical project process set up just to deliver to spec or to meet an evolving customer need? See recent posts Stand up meeting, thinking tool, leadership routine and Anticipating needs ahead of time.

What are the next steps? How can you improve/scale?

Quantify, visualise, sanity check. Look for imbalances. Look for sources of unpredictability, especially waiting. Look at the relationship between project size and predictability.

And remember that scale comes with addressing coordinating costs and other kinds of friction end-to-end, not from rolling out more process or adding layers on top.

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?

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

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.

March 28, 2013

Who is Kanban for?

Filed under: Kanban,Values — Tags: , , — Mike @ 2:30 pm

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.

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.

 

Older Posts »

Powered by WordPress