“Influencer”, or Kanban and models for change

Consider this progression:

  1. Operating a development process, using Kanban as a visualisation and scheduling tool
  2. Continuously improving a development process, using Kanban to manage flow locally
  3. Relentlessly tackling root causes that lie outside the scope of the development process of #1 and #2, driven by the latter to improve flow end-to-end
  4. As needed, designing and implementing radical change at the levels of #1-3, driven by #3 to improve flow for multiple value streams
  5. Embedding a change management and improvement process/mindset that sustains #1-4 for the long term

Kanban implementations led by people who understand its principles will set out to do #1 and #2 together, though one might hope that #2 will follow from #1 even in a “cargo cult” implementation.  #3 and #4 become natural as peer teams in increasing numbers surface the same issues and learn to collaborate on their solution; #5 then becomes implicit, perhaps manifested explicitly in support structures.

Bottom-up progressions like these have a lot going for them:

  • They can be started by anyone, pretty much anywhere
  • They’re not disruptive initially (but don’t rule out later disruption)
  • Judicious reading, training, coaching and mentoring can speed the process

But (and the answers to these will vary by organisation):

  • What exactly are we trying to achieve?  How will we know that we’re on the right track?
  • From where will come the support necessary for success in #3-5?  What’s to stop the whole thing from hitting a ceiling of organisational indifference or fizzling out, failing even to sustain #1-2?
  • How long should it take?

I’m a bit skeptical when it comes to top-down initiatives too, so what’s the alternative?

Back in April I mentioned Crucial Conversations by Patterson, Grenny, McMillan & Switzler in my post Crucial Conversations, Respect and Kanban.  I went on to read Influencer (their book on influencing change) and am now getting stuck into Crucial Confrontations by the same authors.

“Influencer” is about influencing and leading change.  I like this book a lot; it appeals to me as a Systems Thinker and it has the most teachable model for organisational change I have yet come across.  I hope I don’t do the authors a disservice by presenting it thus:

MOTIVATION ABILITY
PERSONAL Make the undesirable desirable Surpass your limits
SOCIAL Harness peer pressure Find strength in numbers
STRUCTURAL Design rewards and demand accountability Change the environment

If you can’t remember the content of the boxes you can still remember to ask “why change?” and “how?” at each of the levels of Personal (e.g. you and your peers), Social (e.g. team) and Structural (bigger picture stuff, e.g. organisation, process-wise).  These are good questions to ask also of your development system and each of the systems that surround it – see my recent post on portfolio management for an example of a surrounding system.

This “everywhere out” approach may look daunting, but the trick is to look ahead, to try to pre-empt impediments to change and to identify leverage points, i.e. those places where just a little effort (e.g. policy adjustments, better articulated goals) might unleash significant changes in outlook and behaviour.  Examples could include lead time as an organisation-wide improvement focus, with (say) inventory limits as a policy lever and the availablity of Kanban training as an enabler.  Collectively, these hit most of the boxes above.

None of this is to rule out bottom-up approaches, since a growing number of positive examples (“bright spots”) are key to success in that Social level, and the stronger your base of social capital, the easier it will be to engage at the Structural level.  But let us draw some “meta advice” from the “Influencer” framework: take the trouble to understand how change works, in theory, in your organisation and in organisations similar to yours.  Look for those bright spots!

Kanban in its portfolio context (idea for LESS 2011)

Much as I love hands-on development, I can’t help but bring a manager’s perspective to Kanban.  When I see situations suffering with the all-too-common “massive WIP” problem (usually coupled with slow delivery and shared bottlenecks), my attention turns very quickly from team level to the management support systems that are failing to bring high level control to the overall burden of work that teams are expected to deal with.

Hence a growing interest in the field of portfolio management.  It’s not that large organisations don’t have the systems (I’ve had to provide data to enough of them!), it just seems that they’re so focussed on accounting for the past that they have little influence on future delivery.

Here are just some of the things that I believe a good portfolio management system should offer, and some pointers to how they might be turned into levers for improvement.

Point-in-time financial measures

1. “Inventory”: Money spent on work that has not yet been released.  Accountants might call this “Work in progress” (WIP) instead, but to the Kanban community this refers to the number of items under development.

2. “Required” (my word, perhaps there’s a accepted term): Further money to be spent before work currently in progress will generate value to the business.  Inventory + Required make up the total expected cost of building and releasing something.

These are point-in-time measures that can be trended over time and projected into the future.

Central to Lean and Kanban is the belief that managing down inventory (whether measured in items or in money terms) goes hand-in-hand with improving flow, and from improved flow we should expect to see growth in business capability and value.

But money spent stays spent. The only way to reduce inventory in the short term is to make releases, which means spending yet more money! The key to reducing inventory in the longer term is to plan (or replan) to release more incrementally, reflected in reductions in the “Required” measure.  Implicitly or explicitly, to achieve this across the board requires changes in policy (e.g. limits, risk appetite) &/or practice (e.g. how work is structured).

Rate-based financial measures

3. “Burn Rate”: How much money spent per month on the project or portfolio in question.

4. “Throughput” (again, there may be a better word for it): Completed work released (out of inventory) per month.

Like the point-in-time measures, these can be trended over time and projected into the future.

A gap between current burn rates and projected burn rates could be a sign of trouble, though the direction of the gap is crucial.  If to meet our commitments we must spend at a rate significantly greater than our current capability (i.e. because we can’t ramp up quickly enough), we have an overcommitment problem.  If the gap is in the other direction, it means we’ve kept out options open, a good thing so long as the result isn’t needless starvation caused by a lack of preparation.

Assuming that all projects survive until completion, the long term averages of throughput and burn rate will be equal.  High month-by-month variability of throughput could however be seen as an indication of the lack of flow.  It could even be an impediment in itself if (say) a business function is to be impacted with a short-term rate of change that it is unable or unwilling to sustain.

Non-financial measures

5. Headcount: Self-explanatory, often tracked alongside financial measures.  Ramping headcount up or down can be painful (and I say that from the heart!).

6. Work items: Features etc as managed in Kanban systems.  Slightly problematic though – whilst it clearly makes sense to track features at project level, can we be sure at portfolio level that one project’s work items (let alone their states) are comparable with another’s?  Although they don’t flow very fast, projects can of course be treated as work items too (and worth limiting in number as well as financially).

7. Lead times: How long projects take, based on actuals from completed projects, planned dates, or estimates based on budgets and burn rates.  It hardly needs to be said that shorter is generally better.

Reporting dimensions

8. Initiatives: The “why” behind the work; used as a reporting dimension it shows how effort aligns to strategy. Too many of these may indicate a lack of focus or alignment.

9. Organisation/sponsor/funding source/customer/market segment: Dimensions based on by whom and for whom work is done

10. Classes of service: see some of my previous articles.  See that we’re investing sustainably and that our development systems are robust.

Where next

I’m considering attending the LESS 2011 conference in Stockholm in late October.  What would absolutely make me go is the thought of exploring the boundaries between Kanban and surrounding systems (portfolio management and other existing support systems that might be turned to create “pull” for positive change) with like-minded people active collectively across these diverse areas (quoting the conference website):

  • Lean and Agile Product Development
  • Complexity and Systems Thinking
  • Beyond Budgeting
  • Transforming Organizations

But I can’t make this happen on my own.  Who else would be up for it?

Or you may have a portfolio problem (perhaps a “massive WIP” problem) of your own.  Get in touch!