Category Archives: Portfolio

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

Posted on by

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?

No-one said it would be easy…

Posted on by

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.

How Deep is “How Deep is Your Kanban”?

Posted on by

[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…

What’s your strategy for success?

Posted on by

“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?

Back from #klrat

Posted on by

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

More than mere tinkering

Posted on by

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!

Kanban: Thinking tools for portfolio-level problems

Posted on by

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?

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

Posted on by

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.

Overview:

  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.

Portfolio stuff (sic) at LSSC12

Posted on by

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.

LSSC12 Debrief

Posted on by

Two days of tutorials start today and I’m written this in a bit of a rush, but here’s my run-down of what has been an superb LSSC12 conference in Boston. Certainly the best conference I’ve been to (not counting last year’s unconference – can’t wait for Mayrhofen). Nice variety of formats to keep us interested, superb keynotes, varied talks, fantastic hallway/mealtime conversations.

My one regret was not making the Lean Camp openspace on Sunday which by all accounts was very intense. Just too much to fit in.

Monday’s daytime highlights:

  • Steven Spear’s keynote got me thinking a lot more carefully about what experimentation means. This one will stick.
  • Jeff Anderson’s talk was impressive, also a little controversial. I’ve been following his Lean Startup-inspired approach to change management for a while and have encouraged a couple of other people doing similar things to compare notes with him too. The controversy was around validation, in particular its granularity (person-level) and transparency (not a lot). My lasting impression though was of his ambition. Wow.
  • Michael Kennedy’s talk was very interesting. I struggled to hear him from the back of the hall in Antwerp but I’m so glad I gave him a second try here in Boston. I’m not quite as excited by the “tradeoff curves” specifically as some appear to be, but there’s definitely something important there, and I touched on it in my first talk on Tuesday (blog & slides to follow).

For Monday evening I organised an informal session on portfolio-level stuff (sic) to help define the space a bit better and to decide how (if at all) we want to carry the conversation forward. 23 people showed up at 20:45 in the evening – another wow. As expected, we found that the problem space is huge. As hoped, we agreed to use a mail group, and someone (I forget who, sorry) had the very smart idea of a hashtag (#ppm) on posts to kanbandev.

Tuesday was a big day. My scheduled speaking slot on Tuesday’s Risk track got extended as a result of the following speaker dropping out, creating an opportunity I couldn’t refuse to encourage people to attack portfolio-level problems with the Kanban method. My scheduled talk “Who Moved My Risk?” went fine, but the question-filled portfolio session was more than I could have hoped for. Thanks everyone! I’ll share slides and blog on both talks separately.

That’s enough about me. Other Tuesday highlights:

  • Greg Howell’s keynote on Lean in the construction industry. There’s a pattern emerging here, excellent keynotes from people outside our industry that help us to understand better what’s happening inside our own.
  • The Ignite talks were great, the format definitely works, more of these please.
  • The Brickell Key Awards banquet. Congratulations to Arne Roock and Jim Benson, richly deserved.

With my talks done, I could relax a bit on Wednesday. More great talks, including:

  • Don Reinertsen was on good form (is he ever not?).
  • Larry Maccherone and Karl Scotland on advanced metrics. Larry in particular is doing some amazing work in this area (I got a demo over breakfast). Karl prompts me to write a short followup post on this topic too.

Bring on the 2013 conference in Chicago!