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.


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.

September 4, 2014

Did I mention that I have a book out?

Filed under: Books,Kanban — Tags: , , , , , , — Mike @ 3:57 am

Thrilled that I can move Kanban from the Inside to the “Published” column now! Complete with an awesome foreword by Luke Hohmann, It’s available in paperback on Amazon (I checked .com, .co.uk, .de and .fr) and a Kindle version will be available very soon. Reviews should start to arrive in the next few days.

[Update: As of September 29th the Kindle edition is now available, and a PDF e-book is also available via the djaa.com store.]

It has been quite a long haul, but I don’t regret a minute of it. It all started right here 20 months ago with a humble blog post Introducing Kanban through its values, but that title describes just 9 of the 23 chapters. There’s also all the “models”—Systems Thinking, Lean, Agile, Theory of Constraints and so on—and the implementation approach, STATIK. Serious work on the book started in July last year when I presented an outline to Janice and David; writing took a little less than a year after that, but then there’s all the other stuff…

I should mention that we can handle bulk orders and can produce corporate branded versions with your logo on the cover and your message on an inside page. Enquiries to sales@djaa.com. You can enquire after my own availability there also. In the immediate term given current workload, single days in the UK or an evening’s hop away.

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

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.

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


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]

September 23, 2012

Kanban the Hard Way

I’m just back from a fantastic Lean Agile Scotland, many thanks to Chris McDermott and team for putting together a great event.

The slides for my talk “Kanban the Hard Way” are now up on Slideshare.  In overview:

  1. Kanban works on your organisation – visual management, self-organisation, the knowledge discovery process
  2. Kanban works on your process – pull systems, leverage points, interventions
  3. Kanban works on your system – models for evolutionary change, the Kanban Method and its debt to Systems Thinking, Lean and TOC

I’ve given this talk several times now, sprinting through it as a webinar in half an hour, presenting it in the typical 45-minute conference slot (Lean/Kanban Southern Europe, Lean Agile Scotland) and twice as a 90-minute tutorial (BCS Manchester, Agile North). It’s an introductory talk that never fails to provoke good questions from experienced people too and I always enjoy giving it.

New in this iteration was a reference to Lean Software Strategies by Peter Middleton and my friend Jim Sutton.  I love their advice to treat any stakeholder who holds any kind of a veto over your delivery (my words, not theirs) as a customer. Not only will you do a better job of capturing requirements, it’s very good risk management advice too. The CFD on slide 30 shows what happens when you don’t pay enough attention to this.

Do get in touch by email if you would like to see the notes as well as the slides.  I never present it quite the same way twice so you might not recognise the talk you heard, but they should help with recalling the main concepts. Drop me a line also if you’d be interested in hearing this talk at your organisation or event.

May 31, 2012

More than mere tinkering

Not that I have ever needed much excuse to tinker, but LSSC12 has prompted me to make some significant updates to the materials for DJAA‘s 2-day class Successful Evolutionary Change with Kanban. And I don’t suppose it will be long before other providers follow suit.

Key changes, trailed by David at the conference after some testing on kanbandev:

  • Kanban’s foundational principles are gaining a fourth member on the subject of leadership, to be encouraged at every level from individual contributor upwards. I believe it fits very well – just as with the original three principles (which I like to summarise as “understanding, agreement, respect”), without leadership can you really expect success?
  • We are gaining an additional practice too (a 6th, to be inserted at #5): “Develop feedback mechanisms at workflow, inter-workflow and organizational levels”. A leaf out of Influencer‘s book, a good bit of Systems Thinking, and another reminder that Kanban is a method for driving organisational change, not a software development process, project management framework or process tool. Feedback mechanisms are a key part of what I’m already doing in the portfolio space and there’s no doubt in my mind that there is a lot of mileage in this practice.
  • References to “scientific method” have been replaced with “safe-to-fail experiments”, tying the improvement practices we already teach to the organisational understanding of Dave Snowden and other folks in the complexity community. Experiments were an important topic at LSSC12 and this change seems very timely.
  • There’s another acknowledgement of great thinking from outside the Kanban community in our adoption into our material of Michael Kennedy’s language concerning the “knowledge discovery process“. I love that we have found better words for what some of us already knew deeply but could explain only clumsily.

None of these changes are fundamental – rather they help to crystallise out some thinking that runs right through what we teach in our classes and bring to our consulting clients. That makes them easier to take away and to apply in imaginative ways, and that’s exciting.

My next public classes are in London (June 18th-19th) and Edinburgh (September 19th-20th) and you can register through our UK partners TeamProsource. And you might do yourself and your organisation a favour by sending your managers along to our 1-day event (June 11th). Not that managers (or for that matter non-techies) should feel the least bit excluded from our regular classes – some of the best designs of kanban systems I’ve seen in our classes have come from managers from outside of IT; they get it!

May 20, 2012

Portfolio stuff (sic) at LSSC12

This is followup #2/n to my LSSC12 debrief.

As I mentioned in my debrief, I organised an evening meeting on portfolio “stuff” to take place after the speakers’ reception. What kind of an idiot arranges a meeting for 20:45, after drinks, and with a deliberately vague title?  23 people showed up at that late hour, demonstrating a significant level of interest. If you’re one of those 23, thank you!

“Portfolio stuff” became “Portfolio-level problems” in my bonus talk the next day (my slot was extended due to the next speaker dropping out).  I’ll write up my talk more fully in the coming days, but what both titles indicate is a desire to spend some time identifying the problem rather than to announce that we have cracked how to do portfolio management.  To describe the problem (if there is indeed only one) in the terms of the presence or absence of a particular kind of solution is a kind of sloppy thinking I wish to avoid.

I must make plain that I take seriously the evolutionary approach of Kanban and its principles of “start with what you do now”, “respect current roles and responsibilities” etc. I use “understanding, respect, agreement, leadership” as a way of bringing together both these principles and some of the Systems Thinking approaches that we teach in our classes.

So lets start with a little understanding.  What does the problem space look like?

Limiting myself to the past 4 years, my direct experience ranges from leading a team of 15 (the whole of IT in that small company), responsibility for a team of 70 within a big name global enterprise, and looking at the work of an IT organisation of hundreds within one division of a major enterprise.  That’s quite a spread.

My Monday night group reported projects (if that’s the right word) ranging in duration from days to months. I’ve seen worse, ie years passing before anything gets delivered.  Orders of magnitude differences.

We defined “portfolio level problem” as problems seen, managed or originated (ouch!) above the organisational level of teams of individual contributors.

These include:

  • The challenge of translating the objectives of the organisation into actual work
  • The reverse of that challenge, seeing how actual work on the ground corresponds to organisational needs
  • Managing flow day-to-day, ensuring that important work has the help it needs to progress to completion
  • Managing and improving flow system-wide

Steering clear of:

  • Allocating individual people to their work (it distresses me that some writers seem to think that this is even a problem, let alone a solution).
  • Push, meaning any approach that seems to value starting over finishing. Includes any system with stage gates or focussed on backlog grooming that lacks strong mechanisms to balance supply and demand further down the pipeline.  It is not enough to limit what you start.

It’s a very interesting and wide-ranging problem space. “Portfolio management” might be the right name for it but I’d love to have a better one that didn’t carry the baggage of failing approaches.  “Portfolio Kanban” works well if it implies the method and thinking, less well if it means only stickies on whiteboards.  Perhaps we need to do some work to reclaim the phrase.

Upcoming posts will explore the applicability of the Kanban method and offer some techniques for use in this space.  Stay tuned. Meanwhile, a reminder to use hashtag #ppm for related posts to kanbandev.

Older Posts »

Powered by WordPress