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

March 13, 2015

Kanban from the Inside: 5. Flow

Filed under: Books,Kanban,Values — Tags: , , , — Mike @ 10:36 am

This post is the fifth in a roughly weekly series of excerpts from my book, Kanban from the Inside. Chapter 5 is on flow. Like the preceding chapter, it is inspired by the third of the Kanban Method’s core practices, Manage flow.

CP3 (expanded): Manage flow, seeking smoothness, timeliness, and good economic outcomes, anticipating customer needs.


Organizations often get deeper into trouble because people think that the answer is to keep trying harder. They think that better project management will fix a problem of capacity management (scapegoating project managers, meanwhile), that stronger functional management will improve end-to-end performance (when it can easily make it worse), or that people should just try to do better (when the system is fundamentally unreliable).

Kanban’s unusual solution to this problem isn’t to address head-on the roles of project management and functional management; certainly it does not set out to replace them immediately with other things. Instead, it gives managers (and others, too, of course) the tools to see work and how it flows in new ways, together with controls on WIP that impact dramatically on problems of delay and unpredictability. Allowed the right scope, the improvements and the necessary new thinking grow hand-in-hand. If roles then need to change, fine!


It would be a mistake to think that managing flow is only a matter of removing impediments as they arise. Typically in knowledge work, we see work items vary widely in both content and value, and we see the overall workload varying greatly over time. This means that there will always be a place for managing work proactively:

  • Unusual risks and dependencies must be identified early and managed effectively.
  • Looking toward the medium term, anticipated workload must be met with adequate capacity.
  • Longer term, entirely new capabilities might be needed.

Being committed to self-organization doesn’t mean that you must always shy away from managing the most important work items more carefully. Not all work items are alike, and some are considerably more deserving of management attention than others. Dates—meaningful dates, at least—should be met. And when it’s justified by the business opportunity, it’s perfectly valid to sacrifice a little predictability and allow high-value items to jump the queue.


Next up: 6. Leadership. Previously: 4. Customer Focus. Start from the beginning: 1. Transparency.

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 24, 2013

Anticipating needs ahead of time

Filed under: leadership,lean,Values — Tags: , , , , , , — Mike @ 10:00 am

Last week’s post Stand up meeting, thinking tool, leadership routine included this line:

In what ways do the activities of this stage help us anticipate what will be needed?

“Anticipate” and “will”: two very future-focused words.

That emphasis on the future is captured very nicely in the closing words of the Toyota Customer Promise that I found displayed on a plaque behind the customer service desk at my local Toyota dealership:

…anticipating the mobility needs of people and society ahead of time

Think of a service on which you personally rely. Wouldn’t you be delighted if they anticipated your needs ahead of time? What process innovations would be needed in order for that to happen? How could that thinking be translated into your workplace, and how would it then be sustained?

These are important questions. They’re questions of customer focus, of flow, and of leadership, the three direction values. They’re important because an organisation that works on its capability to anticipate and meet future needs is a fitter organisation, and it’s the fittest that thrive.

There’s more where this came from! My book is going to be a while, but in the next few weeks you can hear me speak on Kanban’s values at:

Unfortunately I must report the postponement of the UKSMA annual conference at which I was to give the keynote. I’ll mention it here when it has been rearranged.

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?

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.

Powered by WordPress