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

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

Find ways to…

Filed under: Kanban,leadership,Portfolio — Tags: , , , , — Mike @ 9:55 am
  1. Find ways to visualize your work
  2. Find ways to limit your work in progress
  3. Find ways to manage flow
  4. Find ways to implement feedback loops
  5. Find ways to improve (collaboratively, using models and the scientific method)
  6. Find ways to encourage leadership (at every level)*

Then ratchet it up, in terms of both creativity and persistence. Keep finding ways to…

As Larry Wall (of perl fame) says: there’s more than one way to do it. We all think we know what a kanban system should look like, but the further you depart size-wise, speed-wise, scale-wise or complexity-wise from what’s typical – where the board sees a worthwhile and manageable amount of movement each day – the more creative you’ll need to be.

A card wall visualisation may not even be the best starting point. Look at what you have – your existing practices, your existing data. Kanban is after all the start with what you do now method.

(* Yes, that sixth one is a principle of the Kanban method rather than a core practice like the others, but it still works. See also Small Acts of Leadership.)

October 29, 2012

When will this project be ready? (and some better questions)

A couple of good articles have caught my eye recently, both extolling the virtues of Critical Chain Project Management (or aspects thereof), namely:

Also announced in the last few days: Troy Magennis’s (@t_magennis) new book Lean Forecasting (“Rapid Forecasting Likely Staff, Cost and Delivery Dates of Agile Software Projects”). Meanwhile there’s always the classic Waltzing with Bears by Tom DeMarco and Timothy Lister.

Here on positiveincline.com I’ve made some small contributions of my own on the subject of planning, for example:

But there’s a problem with these technical approaches…

Is the when will this project be ready question always a good one to ask?   And even when it is a reasonable question, are we guilty of rushing to answer it when more interesting questions need to be asked first?  Questions like:

  • Why do you ask?
  • What will we need to prove?
  • What parts should we deliver first?
  • What else needs to happen for this to be successful?

Moreover, we risk a lot of needless pain and waste if we don’t take the trouble find out what kind of date we’re talking about.  Is it a “bad things will happen if we’re a day late” kind of date, or “I need some cost information so that I can make a priority call” kind of date?

I don’t expect the need for forecasting and schedule risk management to to go away completely, but let me leave you with another:

  • What needs to change in our organisation for the when will this project be ready question to be asked only rarely?

Answer that one, and you’re probably on a good path to a kind of processes that deliver predictability in ways more valuable than just date compliance. Worth exploring, surely?

October 23, 2012

No-one said it would be easy…

Filed under: Kanban,leadership,lean,Portfolio — Tags: , , , , , , , , — Mike @ 8:33 pm

Much as expected, Lean Kanban Central Europe 2012 (#lkce12) turned out to be an excellent conference, probably the best-organised I’ve attended. Well done to the board (Markus, Pawel, Hermanni, Klaus and Karl) and everyone who helped behind the scenes.

The slides for my talk ‘Not “Portfolio Kanban” but “Kanban”’ are now up on Slideshare.  The most important slide is probably the one shown below (#30), which illustrates the scale of the what’s to be done “if we are serious as change agents” (a phrase I used more than once).

Four different directions of interaction to consider. Four different considerations (the “Agreement, Alignment, Models, Challenge”) for each direction. That makes 16 if all combinations are relevant (most will be). Hard work and worth tracking, so perhaps some new visualisations will be needed too – something to think about. I will be talking to David about incorporating some or all of this in the “Kanban depth” tool also.

October 19, 2012

How Deep is “How Deep is Your Kanban”?

[wonkish, sorry]

I’m busy putting the final touches to my portfolio-related talk for next week’s #lkce12 conference in Vienna. It owes a significant debt to David’s milestone talk How Deep is Your Kanban, but this leaves me with a couple of slightly embarrassing niggles.

Where in the assessment tool are:

  1. 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”?
  2. Challenge – The language of the tool is big on improvement, implicitly in the direction of “improved” or “fitter”. Isn’t this a bit weak? What about other drivers, direction-setters and pace-setters? Together with “leadership” and “alignment” (already well represented), adding “challenge” might go some way to address the “Kanban is too nice” perception and help complete the connection with Lean organisational practice.

Got that off my chest!

With that out of the way, keep an eye out in my talk for my son’s summer programming project – Kanban meets Design Factory meets Beyond Budgeting. It needs a better name than “Foo” though…

July 10, 2012

What’s your strategy for success?

All projects must have a strategy for success

So starts a thought-provoking post from Glen Alleman‘s blog Herding Cats; several months later and I’m still coming back to its central idea.  Ask yourself: what are you doing right now to ensure that the thing you’re building doesn’t just meet documented requirements, but is successful in achieving valuable business outcomes?

Before we get hung up on the word “projects”, how about:

“All initiatives must have a strategy for success”

If you’ve heard me speak in the past year or two you may have heard stories of how we used A3 as a way to get to the heart of what was important in our portfolio of initiatives, against which we could deliver value to the business (I’m deliberately steering clear of how that was organised – it’s not that relevant here).

Last year I majored on how A3 helped us identify the few business initiatives on which we needed to concentrate our efforts; this year in my portfolio-related talks I’ve drilled into one project whose A3 helped take it from #5 to #1 on our list of priorities.

Its strategy for success?

  1. Re-frame the initiative not as “deliver the next milestone on the roadmap” (in this case a new trade capture system) but as “face up to a set of significant challenges” – addressing some real business risks (which we quantified at the time) linked to some big-picture architecture issues which we planned to address incrementally.
  2. Reverse the implementation plan, starting not with the shiny new system but with something much more mundane, some strengthened business controls to create (i) some additional stakeholder “pull” and (ii) a safer environment for the several (and sometimes difficult) implementation steps that would follow.  A feedback mechanism designed both to amplify learning and to dampen any potential negative effects.

You may recognise part 1 of this strategy as the A3 approach working its magic.  Part 2 was explicit, documented in its A3, agreed.  What was seen previously as an IT delivery problem was now a business problem. And it worked!

Taking it down a level

What if we asked the “strategy for success” question more often?  For every piece of work?  Have it hanging in the air in every stand-up meeting?

I have in mind what might be described as a reversal of the V-model (article and image from Wikipedia):

Instead of that backwards-looking “Verification and Validation” arrow, what if we looked forward, asking ourselves questions like these:

  • How does the work we’re currently planning (and the way we plan to execute it) really stack up against stated business goals?
  • How do we know that the thing we will make operational tomorrow is what will be needed tomorrow, not just the thing that was specified yesterday?
  • For this current feature, do we know what sort of UAT experience we can expect? (And if not, why not?)
  • How many surprises should we expect in system test?  What are we doing to pre-empt them?
  • What am I doing to make my next handover (upstream or downstream) a zero-surprise non-event?

Asked daily, some of these questions are more tactical than strategic (in Kanban terms we’re in “manage flow” territory), but ask them often enough and we may crystallise out some new policies, refine our knowledge discovery process, perhaps trigger some concerted improvement activity – a strategy for change that’s supportive of our strategy for success.

So, looking at your work from business initiative right down to today’s work items, what’s your strategy for success?

June 25, 2012

Back from #klrat

Filed under: Kanban,leadership,lean,Portfolio — Tags: , , , , , , — Mike @ 2:02 pm

I’m just back after another week away from home – first a 2-day Kanban class in London, then the Kanban Leadership Retreat in Mayrhofen in the beautiful Austrian Alps. Such a treat!

You will not be surprised to hear that I found myself leading (or rather co-leading with Rich Turner) a further exploration into the application of Kanban to portfolio-level problems. By “Kanban” I mean not just kanban-style visualisations but conscious attention to WIP, flow, policies etc. I have to admit though that I got far more out of other sessions.

Yuval Yeret did us all a great service by (re)raising the topic of Crossing the Chasm. This spawned several intense discussions, mostly notably a “Compelling Reason to Buy” discussion that fully justified an additional session of its own.

Håkan Forss led a number of sessions, two of which I attended. The first was on Kanban Kata which he describes here and here – I have little to add except to say that (i) I love it and (ii) it fits very well with what I teach around the use of A3.

In Håkan’s second session he sought to challenge the sequence in which the practices of Kanban are listed. This might seem a trivial point (and at one level it is) but it led first to a fruitful discussion on rollout approaches and then to this, an unordered visualisation of the depth to which the practices are understood and applied:

Discussions like this get exciting when you realise that you’re part of something that will change the way we understand, teach and implement Kanban. My contribution was to make a connection between this picture and the use of the Story Mapping technique as a way to guide and organise a Kanban rollout. Probably the best introduction to the latter idea is this post of Yuval’s.

You could say that Håkan and Yuval had good conferences, but then we all did 🙂

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 25, 2012

Kanban: Thinking tools for portfolio-level problems

This is followup #4/n to my LSSC12 debrief, probably the last of the series (n = 4) but who knows.  If you haven’t already read followup #2 Portfolio stuff (sic) at LSSC12 please do so now, what follows should then make a lot more sense.

I put the deck for my hastily-arranged talk “Kanban: Thinking tools for portfolio-level problems” up on slideshare a few days ago.  I had only a couple of days to prepare it (and it shows, no doubt), but presenting it was still a lot of fun. In contrast to my earlier talk where interaction was programmed in, here it just happened, a real pleasure.

I will be giving a reworked version of this talk at a management seminar in London in June (if you’re based in the UK, send your manager!) and I’ll release an updated deck after that event.  Meanwhile, I’ve done a better job of summarizing how the Kanban practice “Limit Work-in-Progress” (which was always about so much more than just avoiding multi-tasking) points towards the generation of flow at portfolio level:

  • Apply “traditional” WIP limits where effective
  • Test the logic of your investments with A3
  • Make the full cost of your inventory visible
    • Effort, time, money
    • Cost of carry
  • Manage your inventory down
    • Decide what to finish
    • Work out how to release customer value incrementally
    • Break habits of over-commitment & premature commencement
    • Balance work & capacity across the board, seeking smoothness

To explain the first bullet, limiting business initiatives at the highest level can be effective (I’ve helped to make it happen), and naturally we would recommend Kanban at the lowest levels.  But between those extremes of scale, traditional(!) Kanban-style WIP limits can be hard to apply if there are a large number of projects, orders-of-magnitude size differences between them, or glacially slow progress, ie just what you might expect in many larger organisations. Clearly we will need to be more creative in how we begin to control inventory here.  After that we might move away from projects (especially projects of the fixed-date kind) as the default container for work.

My references to A3 are based on real successes which I spoke about last year at #lkbe11 (Antwerp) and #lkce11 (Munich) and my updated deck will contain a simplified example. The phrase “Decide what to finish” also appeared in last year’s talks, along with the more desperate “Decide to finish something“!

The rest is newer.  If you have any financial information about the work in your portfolio, think about re-purposing it for inventory management, aiming to generate flow by managing inventory down.  Think about cost of carry; see how it incorporates both cost and time into one measure, see that it can help to bring value and risk into consideration too.

I would be the first to acknowledge that Kanban at this level is very much in the early adopter phase.  I make a virtue of this, in that we have the opportunity to explain the Kanban Method as a pragmatic and actionable strategy, neither a leap into the unknown nor something that is primarily tool-driven (although it’s good to see the tools coming along quite nicely). I see the techniques I and others are exploring leading to better organisational feedback mechanisms that help to drive organisations in the direction not only of faster delivery but also of smoother flow supported by more stable teams. Real change, in the direction of effective, economic and humane – isn’t that what we all want?

May 23, 2012

“Who moved my risk?” and one of Kanban’s killer features

Filed under: Kanban,lean,Portfolio — Tags: , , , , , , , , — Mike @ 8:20 pm

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

I’ve put the slides for my scheduled LSSC12 talk “Who moved my risk?” up on slideshare.


  1. There are risks inherent in each piece of work; some of these are unique and specific to that piece of work but there are some easily-recognised varieties of risks based on time and expectation. Time does funny things to priority – it has a habit of making a nonsense of any priority scheme that is fixed in time. And don’t think that risks based on expectations aren’t real risks!
  2. There are additional risks that relate to the (in)capability of the system (lead time and throughput performance/predictability especially) when faced with a volume of work. Capabilities differ between systems, but less capable systems can still offer high capability on limited subsets of work, those subsets perhaps based on the varieties of part 1 above. It is a “killer feature” of Kanban that we can easily make variety explicit so that good risk-based judgements can be made within teams on a day-to-day basis. Furthermore, it is relatively straightforward to design resilient kanban systems that consistently deliver good results in the face of variety, something that many systems deal with rather poorly.
  3. Don’t get so focussed on the system that you can’t step outside of it to see what’s really possible. Avoid “backlog driven development” (I’m sure you can work out what this means) – quite apart from its grim economics, you need to be spending time with different kinds of stakeholders concentrating on working out what’s important – using imagination, thinking the unthinkable (good and bad), filtering out the noise, creating good possibilities and heading off the bad ones. To put it another way, backlog grooming (on steroids or otherwise) is no path to success. But there’s good news: limit your WIP, shrink your backlogs and work on growing shared understanding outside your system and your risk will seem very different. Who moved your risk? You did!

Watch out for the “triple” win of improvements that are good for the customer (effective), good for the organisation (economic), and good for the team (humane). To my mind, “effective, economic, humane” in my estimation beats “better, faster, cheaper”; less catchy perhaps, but where’s the humanity in the more traditional test?

How did it go?  That’s quite a lot for a 45 minute slot and I should probably have pruned it more. Also, I made a tactical error in thinking that we could do an interactive exercise before we had all warmed up.  Lessons learned.  Despite those improvement areas the feedback was pretty good and sufficient people were kind enough to tell me of the useful thoughts they took away that I’m happy enough with how it went.

I’ll write up my unscheduled talk on portfolio level problems soon.

Older Posts »

Powered by WordPress