Upcoming

Posted on by

A busy few weeks ahead:

  1. Sept 21: Limited WIP Society Manchester, Manchester, England
  2. Sept 29-30: Pre-conference Kanban tutorial at Agile Cambridge, Cambridge, England
  3. Oct 3-4: Lean & Kanban Benelux (LKBE 2011), Stuurboord, Antwerp, Belgium
  4. Oct 17-19: Lean & Kanban Central Europe (LKCE 2011), Munich, Germany
  5. Oct 30-Nov 2: Conference on Lean Enterprise Software and Systems (LESS 2011), Stockholm, Sweden

I have good reason reason to be excited about all of these:

Manchester is the closest big city to my home since I moved away from London in 2009; props to Ian for getting this meetup up and running.  While we here, I must mention Zsolt and the Budapest meetup that I attended this week.

The Kanban tutorial in Cambridge with David Anderson kick-starts what we hope will be become a regular training offering in the UK.  And yes, I’m an associate, currently the only one based in the UK.

I look forward to LKBE and LKCE not just as speaking opportunities but as the chance to catch up with some of the people who have challenged and inspired my thinking over the past couple of years.

LESS is where we reach out and learn from other communities and disciplines.  And I can’t wait to return to Sweden – I just wish I had held on to more of my childhood Swedish!

Anyway… I hope to see you at one or more of these great events.  Look me up!

“Influencer”, or Kanban and models for change

Posted on by

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)

Posted on by

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!

A funny thing happened to my ROI

Posted on by

Over time, exciting things happen to ROI when you remember to ignore sunk costs.

Consider three projects with lead times of 12, 6 and 3 months respectively, each having an ROI of 33% (no IRR calculation here, just a simple payback of 1.33 for every 1 invested).  Comparable, right?

For the sake of simplicity, let’s assume (i) that burn rates are constant on each project, and (ii) that any uncertainty in the ROI figure derives entirely from the payback element and not from the cost part.

What do these projects look like after a month of progress?

The 12 month project is now an 11 month project.  For a further investment of just 11 months’ worth of work we will get the original payback (1.33 times the 12 month cost), giving a return of about 45%.  Pretty decent!  Or not…

Our 6 month project will return 60% on its remaining 5 months work, and with only 2 months left to run, our 3 month project has an ROI of very nearly 100%.  We will double the money we’re about to spend!

Amazingly, even if the 3 month project had started with an ROI of 0, after a little less than a month it would still look better than the 12 month project.  This is not say that we would want to start a project with an ROI of 0 (though we might), but low worst-case estimates should be much less of a concern on projects of short duration.

Corollaries

  1. If you’re into ROI comparisons, don’t make the mistake of comparing the historical ROIs of current projects.
  2. If adding a new project to your portfolio will delay projects already running, the economic impact may be very much worse than you realise.  Same goes at task level of course.  Limit your work in progress!
  3. The economics of splitting out partial, earlier deliveries from your long project may be very much better than you think, even if the highest value parts of the project are still some way off.

I could go on.  Short is good here people!

Intangibles, value and risk (or: Portfolio thinking)

Posted on by

A bit technical this one, bringing together some loose strands after the excellent Kanban Leadership Retreat in Reykjavik, Iceland (#klris):

Strand 1: This begins with Patrick Steyaert and I in conversation in the #klris hotel bar (the bar conversations alone were worth the plane fare!). I was talking about the way business valuations (as performed by financial analysts and as observed in the markets) depend on capability. Patrick uttered the one word “Intangible”, in reference both to the Kanban class of service (a heading for improvement work, experiments etc) and to the part of a company’s valuation that derives from brand and capability.  Aha! Now I’m completely reconciled to the David Anderson terminology (whether or not he consciously intended this interpretation), thank you Patrick!

Strand 2: Maarten Volders repeatedly encourages me to bring Kano analysis and other models of product development risk into the way I teach classes of service. This idea resurfaced in a small session in Reykjavik on Kanban and Complex Systems (or “Mega projects and all the crap that goes with them”) led by Rich Turner. Perhaps you wouldn’t apply Kano analysis to (say) a defence project, but it is certainly true that the risks of these large projects are multi-dimensional. Maarten, you are right of course, thank you for forcing me to make the connection!

Strand 3: The timely publication of Alistair Cockburn’s post Agile in Tables. and in particular the first figure (under “Risk-Value-Tail table”). I will continue to draw a more S-shaped curve than Alistair’s but I like (and will use) his names for the curve’s three regions:

  1. Pay to learn
  2. Build business value
  3. Shine & gloss (aka the tail)

I like too Alistair’s risk categories:

  • Business risk: Are we building the right thing?
  • Social risk: Can these people build it?
  • Technical risk: Will all the parts of our idea work together?
  • Cost/schedule risk: Do we understand the size and difficulty?

To bring these strands together:

Alistair’s “Shine & gloss” might seem hard to justify in pure dollar terms, but try saying that to Apple! And history seems to be more on the side of the Toyota way than the Motorola way [1] when it comes to improvement.  More broadly, the mindset of striving to minimise all work outside the “Build business value” category seems at best simplistic, at worst blinkered both to risk and to the bigger economic picture.  Rather than minimise or ignore these other aspects, it seems much more useful to make choices and policies explicit and invest carefully across classes.  A portfolio-based approach if you like.

[1] “No Six Sigma project is approved unless the bottom-line impact has been clearly identified and defined” – Pros and cons of Six Sigma: an academic perspective /via Wikipedia

On remote coaching

Posted on by

This week I did my first Skype-based coaching session (my first at least as consultant rather than manager) and I’m pleased to report that it was a satisfying experience all round. An away-from-the-Kanban-board discussion avoids getting sucked into day-to-day minutiae; instead it’s an opportunity to step back, review and plan. It has a lot in common with the Agile retrospective, but a good model is A3: we need to get behind the annoyances and what may be over-personalised issues and work hard on finding the words to express root causes and potential ways forward in ways that lead to positive change.

Away from the board we can think bigger too. How can we work better with teams upstream and downstream? Are we involving the right people promptly and effectively enough? Can we help bring about higher level change that would have greater and longer-lasting impact on projects beyond our own?

Of course it helps immensely that I already know the client well, having working relationships and collaborative partnerships that go back several months, spending weeks on site (abroad) getting to know both the issues and the people. From the client’s perspective, it’s a cost-effective way to ensure that progress is reviewed regularly and that appropriate interventions are made before we get to the point where more hands-on support is again warranted (which will happen!). From my perspective, it creates the capacity to support multiple clients at once. Mutually, we learn from each other’s experiences and manage the peaks and troughs in demand. How very Lean!

Ask the wrong question…

Posted on by

In what order should projects be tackled in order to minimise WIP[1]?

I was thinking about the tendency of project portfolios to contain a very wide range of project sizes. There is for example a 2-orders-of-magnitude difference between a 1-person-month project and a 10-person-year project, and this is by no means extreme.

Let’s look at a concrete scenario. Imagine a project portfolio consisting of a single 1-person-year project and twelve 1-person-month projects, a relatively mild example. Attempting to do everything at once would lead to a worst-case peak WIP of 24 person-months. Let’s not do that!

Some more sensible approaches might be to:

  1. Do the large project before the smaller projects
  2. Do the smaller projects before the large project
  3. Run the two halves of the portfolio in parallel

But however you cut it, you have a WIP of 12 (or 13 if you’re careless) person-months near the end of the big project; the smaller projects are almost irrelevant. The best you can do is to control is when and for how long the WIP remains high.

Yes, I really did ask myself this question. D’oh!

A better question

How can we rework the portfolio in order avoid (or get us out of) a high WIP situation?

Put this way, the answer is more obvious. The maximum WIP is seen at the end of the large project. What if we could make it smaller? Splitting it into two equal phases with a meaningful interim deliverable (no cheating!) would halve the maximum at a stroke.

Lesson

You cannot easily manage your way out of a high WIP situation; you need pre-empt it, attacking it at source, here the wide variation in project sizes.

[1] Premise: at the level of the project portfolio, the money spent on unfinished projects is a good analogue to the number of unfinished features at team level. In fact, by accountants and Kanban practioners respectively, both are often called “work in progress” (WIP). Accountants of the Lean variety will agree with the Kanban practitioner that it is not a good idea to treat WIP as valuable assets. I am considering the merits of tracking portfolio WIP and wondering what we would do with the information.

Book review: Personal Kanban

Posted on by

Personal Kanban: Mapping Work | Navigating Life
Jim Benson (@ourfounder) and Tonianne DeMaria Barry (@sprezzatura) #pkflow

What a lovely little book, a book for anyone that wants to organise their work more effectively, making no assumption that the reader is the slightest bit interested in software development, product development, manufacturing or Lean anything.  It’s a book our mums might read and enjoy, and I say that with absolutely no disrespect.

And yet it’s a great complement to David’s Kanban book.  Personal Kanban has to deal with a wide variety of work, anything from project work to calling the accountant to booking that silver wedding anniversary trip[1].   If David’s book is ultimately about improving the effectiveness of IT development, Jim & Tonianne’s book is much more about dealing with the mess of daily life (wherever that mess originates), with the goal of balance as well as effectiveness.

We have then some great material on prioritisation (drawing on ideas from Corey Ladas), loads of handy Kanban design tips, and an eclectic array of board designs.  Having read this book, I will think much more situationally about Kanban design – I certainly would never have thought of an “emergency response Kanban” for example.

The proof of course is in the pudding, and our landing wall is now home to a Kanban board that has business administration/development tasks and family to-dos combined,  including several of the feelgood variety.  It was our shared response to a total kitchen rebuild that got brought forward at short notice and a crazy travel schedule that generated a backlog all of its own.  Quick & dirty – nothing more elaborate than stickies on the wall – but still very helpful to the temporarily overburdened family.  My youngest caught the bug meanwhile and his A-level revision plan got the same treatment.

Reservations?  Only that I wanted more, but making the book bigger might have ruined it!  I know that the authors are big on collaboration, but quite understandably this fundamental aspect of “team” Kanban doesn’t come out in any major way and I am keen to explore this gap further.  Does Personal Kanban support collaborative working or collaborative management in ways that are new, interesting or different from what we know already from implementing Kanban at larger scales?  Watch this space as I find out.

[1] Coming up in July, we’re thinking the Isle of Man

Lines not boxes

Posted on by

Richard Veryard’s recent post on Emergent Architecture reminds me of the architectural meme “lines not boxes”. It’s a powerful approach that I followed explicitly in much of my time in enterprise architecture and web-centric development (“trust in open protocols and formats rather than closed technologies”) and I believe that it has value as a metaphor for process and organisational design too.

People aren’t boxes

Traditionally, we organise people by assigning them roles defined in terms of skills and tasks. Whilst some people seem to need the certainty that goes with this, it’s a practice I have actively resisted, whether as team member or manager. Putting people into boxes constrains opportunity, responsibility and creativity.

It seems to me more humane and more supportive of learning and growth if instead we make visible what needs to be done, define what good results looks like, maintain the minimum set of policies needed to ensure reliability, then create the space in which people can perform. And it can work for whole teams, where responsibility and creativity become manifested in self-organisation.

“Done” is only the start

Where there are different teams supporting different parts of a process, an over-emphasis on “what done looks like” has the effect of holding work back even when unfinished work could have considerable value downstream. In our “lines not boxes” metaphor, this is like defining the interchange formats to be used between systems but neglecting the communications protocols that carry them. An extreme example is the stage-gated waterfall approach to projects, where documents need not only to be completed but also reviewed and signed off before they may be acted upon in later project phases.

Under time pressure and faced with document-centric hurdles, smart teams learn to reach out and collaborate outside of the formal process. Smart organisations encourage this – making collaborative problem solving part of the process, building on successes rather than merely defending uneconomically against every eventuality (not to mention protecting every rear end). Once this is allowed to happen, it is my experience that artefacts start to get delivered in negotiated chunks and lead times take a significant turn for the better.

This is good news indeed: organisations build structures and introduce process overheads as they grow and rarely do they encourage flow. It is a relief to discover that bottom-up, flow-based approaches such as Kanban can prove effective even in the face of functional silos, not only helping teams to work more effectively within their functions but highlighting where a small investment in collaboration between silos will reap big dividends.

Crucial Conversations, Respect and Kanban

Posted on by

About a month ago, Benjamin Mitchell kicked off a thread on kanbandev called How does the Kanban Method reduce fear about role changes if change is emergent/unpredictable, mainly a discussion of what Kanban meant by “respect”. I couldn’t quite put my finger on it at the time but I was not completely satisfied. Now that I have finished reading Crucial Conversations: Tools for Talking When Stakes are High (Patterson, Grenny, McMillan and Switzler) I have a much better sense of what I was missing from that conversation.

This excellent book is all about how to handle better those crucial conversations where opinions vary, the stakes are high, and emotions run strong. Highly recommended, and I have added the related books Crucial Confrontations and Influencer to my reading backlog too.

One (of many) very relevant part of the book explains how mutual respect helps to create a safe environment into which all participants in a crucial conversation can contribute. And without safety, the book argues, real dialog is impossible.  Where mutual respect needs to be created, focus on similarities instead of differences.

Now I can draw a parallel with what we do when we use Kanban to surface, investigate and address difficult process issues in organisations. Whether we are acting as internal staff or external facilitators, our task is to get the heart of things, to be “seekers after truth” (Senge-style). This requires dialog! Hence the “Respect for people” pillar of Lean, the “Respect current roles and responsibilities” of Kanban, and Deming’s “Problems are 94% in the system”. To these I could add some favourite phrases such as “it’s about the work”, “organisations have needs too”, and several more that move the focus away from the person to the work and to the broader system, creating safety. Speaking from recent personal experience I can say that they really help, together of course with the facilitative mindset that goes with them.

So when I hear hear managers or team members personalise their criticisms of others (“they’re so unprofessional”), see references (even in jest) to “evil management” or consultants speaking in ways that seem disrespectful of their clients, I cringe and (increasingly) I challenge. How do we improve anything by starting with blame? Instead, what reasonable explanations might there be for the behaviours we observe? What might we all be missing?

It’s easy to judge (and yes I see the irony: perhaps I’ve just been a little guilty of it myself here) but it doesn’t get us very far. Catch me making more serious infringements and you are invited to call me out :-)