Tag Archives: Kanban

Release cadence, lead times and cost of carry

Posted on by
Reply

I once led a team that made 8 releases a year, or one release every 6 weeks or so. To use the jargon, a release cadence of 6 weeks.  Not exactly continuous delivery, but at the time it didn’t seem too bad either.  We had a dirty secret though: we ran phases of analysis, development, testing and deployment (yes, this was a phase, not just an event) in parallel, and our true lead time (from commitment to deployment) was actually closer to 18 weeks.  Those releases accounted for only one third of the work in progress; the remaining two thirds remained very much in progress.

What was the cost of that hidden inventory?  The calculation is actually quite straightforward:

Assume a burn rate of $12,000,000 per year (that’s not the actual number, but it will do), or $1,000,000 per month.  An 4.5 month cycle time means that on average we have 2.25 months’ work or $2,250,000 in inventory on our books. Multiply that by a suitable rate (let’s use 30% – I will explain this in a moment) and we arrive at an annual cost of carry of $675,000.  That’s a serious amount of money, yet arguably quite a conservative measure what the business stood to gain from lead time reduction.

Why 30%?  It’s just a parameter, but two justifications for my choice:

  1. An appeal to the rule-of-thumb figure of 25% for the annual carry cost of manufacturing inventory, which Don Reinertsen in Managing the Design Factory suggests underestimates the cost of carry in design work significantly.
  2. Because a portfolio with a target rate of return of (say) 15% will on average be half complete; the remaining work should earn twice that, i.e. 30%. See A funny thing happened to my ROI

[Addendum You may have spotted (as I just did) that my calculation gives a cost of carry equivalent to your portfolio return divided by the number of inventory turns per year. Perhaps that's easier to understand than justification #2]

Not convinced?  Look at it from your customer’s perspective.  How much could it be worth to them?

 

Intangibles matter

Posted on by
Reply

Elroy Dimson (Emeritus Professor of Finance at London Business School, writer on investment strategy) recently wrote

Risk means more things can happen than will happen.

Perhaps I have been reading too many physics books lately, but this quote got me thinking of parallel universes as a metaphor for risk management. How much do we really know about the universe we live in now? Are there future universes out there that we should try to create or to eliminate, that way shaping our journey into the unknowable?

Evil Spock!
One universe to avoid

In Kanban, Intangible work items are those that affect our destination some indeterminate or distant time in the future. They’re uncertain (we’re dealing in outcomes that may never materialise) and hard to value, but their potential impact is sufficient to make the habit of these small investments a very good one to nurture.

This isn’t the first time I’ve linked risk management with Intangibles; see for example “Intangibles, value and risk (or: Portfolio thinking)“.  I return to the subject as part of an ongoing conversation with my friend and collaborator Jabe Bloom (@cyetain) who has kindly given in to my pleading for him to publish his “Space Shuttle” exercise.  Read about it here.

Tempting as it might be to focus mainly on eliminating downside risks, it’s important to understand that a healthy portfolio actively seeks upside risks too. Invest in your people, and one of them might surprise you. Product and platform investments might leave you better able to take advantage of market opportunities that are hard to see right now. And as I’ve argued before, not every process improvement should wait on the identification of a cast-iron ROI. Keep investing in the 4P’s of capability (People, Product, Platform, Process) and help bring those happier universes into existence!

If that’s too fanciful for you, I finish with this from Wikipedia’s page on Intangible Assets:

Competitive intangibles are the source from which competitive advantage flows, or is destroyed.

Intangibles matter; the worst risk of all might be to underestimate them.

2011: Another big year

Posted on by
Reply

Some highlights (the work-related ones anyway):

  • Feb: Set up Positive Incline Limited
  • Feb: Kanban Leadership Workshop (aka Kanban Coaching Workshop) with David Anderson in London
  • Mar-Sep: Continued part-time dev management role in Budapest, Hungary (and a big thank you to my former colleagues at Encore International, now part of M&C Energy Group)
  • Mar-May: Kanban consultancy in Johannesburg, South Africa as a DJA&A associate
  • Jun: The Kanban Leadership Retreat in Reykjavic, Iceland (#klris)
  • Oct-Nov: The Lean/Kanban conferences in Antwerp and Munich and the LESS conference in Stockholm (#lkbe11, #lkce11 and #less2011 respectively)
  • Nov: Speaking to my local (Matlock) business networking group about Kanban. Not just for techies! (#MBCnetworking)
  • Dec: Joined DJA&A full-time (more on that next year)
  • Dec: Leading my first 2-day DJA&A Kanban class in London

Top posts of 2011:

Older posts still going strong:

Real Kanban Questions #3: What makes for a good improvement?

Posted on by
1

Or, given a proposal for change, how do I know it’s a good one?

Dangerous answer: “Because it has a good ROI”

Too often, ROI is used as a tool to justifying changes of questionable benefit. Grandiose schemes, off-the-shelf solutions, restructurings, divestments – we’ve all seen them. It’s not always terrible, but we can do better!

A better answer: “Faster, better, cheaper – pick three”

Changes that promote early feedback tend to improve both speed and quality, but cheaper? Don’t overlook the biggest cost of all, namely opportunity cost – another way of saying that overall benefit to the business must be a primary concern. And if the economics still don’t work, keep trying! Perhaps you can implement your change incrementally, working on the next small change as the previous one proves itself and the system adjusts to a “new normal”.

To see this in action, a couple of real examples:

  1. The sign-off that takes weeks of chasing to complete, never yielding any benefit in quality. Better? That was the intention, sadly not realised in practice, a situation tolerated for years. Faster? Quite the opposite. Cheaper? Again no.
  2. The deployment scripts that take not just “20% time” but hard, scheduled effort to develop. Yes there’s a cost, but the value of being able to deploy quickly, reliably and (let’s say) opportunistically is very significant. Faster? Definitely. Better? Check. Cheaper? Absolutely!

Even better than “pick three” is “pick four!”, where the fourth element is a compass check, looking for alignment to wider vision, goals, or values. Good values make for quick tests: the first example above might have been rejected on the grounds that was likely to add complexity, discourage collaboration and disperse accountability.

What’s your experience? Do you live in a world of ROI-driven change, and what is that like? Is your team good at finding improvements that make your process better, faster and cheaper? What happens when change is in conflict with wider concerns? Are those values made explicit?

Real Kanban Questions #2: How does the team know that customers are factoring architectural significance into their selections?

Posted on by
Reply

This Real Kanban Question is based on a Twitter conversation with @ThinkBA.

One set of answers (David’s) assumes the existence or creation of a process step for assessing architectural impact:

  • Make sure that this step is reflected in the team’s kanban system
  • Have policies for feeding back on items whose impact is determined to exceed tolerance
  • Refine these policies by making them specific to a class of service, allowing (for example) non-urgent items to have greater impact than urgent ones without the need for some special decision making process
  • Have a class of service for items expected to be high impact (platform improvements, say) and reserve some capacity for these so that they are analysed in good time

But what if that assumption doesn’t hold (or can’t be made to hold cheaply)?

“How does the team know?” is a “smell”, meaning that there may be a dysfunction to sniff out here!  It begs a number of questions:

  • Why doesn’t the team know?
  • What are the architectural concerns that the team wishes the customers to take into account?
  • Are there perhaps architecturally significant pieces of work that the team is anxious to get prioritised?  And failing to?
  • Armed with better information, would the customer make better choices (better for all concerned)?

In other words, the question implies to me that the customer and team are insufficiently aware of each other’s concerns and priorities, indicating that collaboration doesn’t feature enough in work selection and (moreover) risk management.

Let’s return to the key paragraph of question #1 (interestingly, another “how do we know?” question):

One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream.  Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team.  Horrible!  Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.

The opposite of “sucking the risk management problem into the development team” is “creating opportunity for collaborative risk management upstream”.  The more informed the customer’s choices, the better those choices will be, to the benefit of both customer and team.  Win!

Do you have a Real Kanban Question?

Real Kanban Questions #1: How do we know that the things we are working on are the most valuable?

Posted on by

That’s partly a question of perspective.  How is the input queue replenished?  Is the team deciding for itself and worrying about whether they’re doing it optimally, or perhaps having work selected for them and worrying that they’re having their time wasted?

One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream.  Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team.  Horrible!  Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.

Ultimately, only time will tell how valuable the work will turn out to be.  Collaborate, be transparent about the decisions you make and how you make them, keep feedback cycles short. For maximum effectiveness in the short run, reframe the question from “how valuable?” to “what will we learn?” and refocus the work accordingly.  If value is hard to measure and still harder to predict, you can at least learn to test your assumptions quickly!

Finally (and partly as a warning against getting hung up on the value question), remember that winning in long run depends on maintaining a healthy level of investment in capability-building work, alongside the more obviously urgent value-driven stuff.  The alternative is to risk being left behind, and you need no ROI calculation to tell you how bad that would be!

[While we're here, not long now until my Kanban class in London, 5th-6th December 2011. Info here, registration here.  Don't miss it!]

Lean reading marathon

Posted on by

I have just finished reading these five books in quick succession:


The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century by Stephen Denning


The New Economics for Industry, Government, Education by W Edwards Deming


Toyota Production System: Beyond Large-scale Production by Taiichi Ohno


Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother


The Lean Startup: How Constant Innovation Creates Radically Successful Businesses by Eric Ries

The Denning book has a very interesting take on old and new models of business leadership, with lessons that business can draw from the Agile and Lean development communities.  A good and interesting read but a couple of nits to pick:
1) Scrum receives special attention but without any real analysis of why (or why not)
2) With 70+ recommendations it was easy to lose track of the underlying principles

I would have left Steve Denning there, but he came to LESS 2011 in Stockholm this month, giving an excellent keynote and holding a Birds-of-a-Feather (BoF) session on leadership storytelling. I was greatly impressed by both, two of the best sessions of the whole conference. His book The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative is now on my reading wishlist.

I approached Deming and Ohno together as an exercise in going back to original sources – both books must surely be required reading for anyone interested in Lean, even if only as historical reference points.  I was however very struck by the timeliness of the Deming book nearly 20 years after publication and appreciated his warnings against the dangers of “tampering” (a word he uses with some precision) with systems that are prone to random variation.  The Ohno book gave great insight into the origins, influences and historical context of the Toyota Production System, and most especially the exceptional determination and clarity of vision with which Ohno and his mentors applied themselves.  My lasting impressions from this pair of books aren’t so much technical but the feeling that I have encountered some remarkable people.

Mike Rother’s Toyota Kata is my book of the year. I could only read it slowly, finding myself at regular intervals putting the book down to think!  It fills a big gap in Lean literature, explaining the Toyota Production System not as something fixed but as the result of decades of ongoing work, that work being the expression of a uniquely self-sustaining and self-renewing approach to management and leadership.  I wonder if there is an organisation outside the armed services that does this quite so systematically and thoughtfully?  There are lessons we can take away on making transformations endure, but still must be admitted that not many organisations have Toyota’s staying power. That’s a humbling thought.

Taking Ohno and Rother together, it seems clear that Toyota’s approach to improvement relies less on good tools or the employee suggestion box but rather on working towards process goals which would seem well beyond the reach of most other companies.  It is no wonder others struggle to keep up!  Continuous improvement seems such an easy thing, but it is no easy option when you are led with focus and determination, guided by a “True North” to which few would dare aspire.

Last but not least, Eric Ries’s Lean Startup book.  My expectations were driven downwards by the Twitter hype surrounding this book, but I was wrong to be so cautious!  There is real depth here, surprising insights right to the last chapter.  In particular, the “validated learning” concept seems set to be regarded as one of those oh-so-simple but elegant and language-changing ideas. It resolves so many of those frustrating loose ends that get argued about endlessly in Agile and Lean circles, such as the “why” of development work, the meaning of “done” and the appropriateness of metrics.  Now we have new and powerful ways to talk about the values, economics and direction of Lean development that sit very well with Kanban.

So, quite a marathon, but what a great investment!

Yes, Kanban scales

Posted on by

Yes, Kanban scales, but perhaps not quite in the way you expect.

Let’s start at the beginning. First follow the foundational principles[1]

  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Initially, respect the current process, roles, responsibilities & job titles

then adopt the core practices

  1. Visualize the Workflow[2]
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively (using models/scientific method)

These three principles and five practices are what define Kanban.  Not sticky note commandments (“On the first day thou shalt pull a sticky note from the Ready column and by the fifth day it shall be entered unto the column of Done”) but a collaborative framework for leading change.

But change to what?

Kanban’s home turf would appear to be software development, the focus of David Anderson’s book. But Kanban doesn’t come with a predefined process – we start out by applying it to existing processes – and it’s a not hard to imagine it being applied to other team-based “knowledge work”.

Personal Kanban scales this down to the level of the individual.  Some of the principles and practices lose emphasis in this transition, though this effect is lessened if we recognise that even personal effectiveness and improvement are best played as team sports.  The wide diversity of work typically seen in Personal Kanban tends to lead to very generic process designs and a lack of explicit policies, but this is counterbalanced by the idea of creating very context-specific Kanban systems, perhaps just for a season.  What could be more explicit than a specific process made visual?

So we know that Kanban scales down nicely; what about scaling it up?

This question is often taken to refer to things like the Kanban equivalents of “Scrum of Scrums”. Some organisations have replicated these with success, but to focus mainly on the mechanics would be an example of thinking at the level of sticky note commandments.

Instead: How might we visualise and manage flow across a whole business value stream of which software development is just a component?  At portfolio level, what could it mean to limit WIP and what kinds of effects might we expect to see?  These are great questions; to ask them as an act of deliberate change leadership is to start applying Kanban at scale, beginning a journey towards a Lean organisation.

So yes, Kanban scales. Not by adding layers of complexity as we scale up, but because the foundational principles and core practices aren’t actually very sensitive to scale.  Some might call that cheating!

[1] See http://finance.groups.yahoo.com/group/kanbandev/

[2] The back of my business card (see http://yfrog.com/hs7wx0j) has the pithier “Make work visible” and the Personal Kanban book says “Visualise work”. Both are fine I think.

A new box on top of old boxes

Posted on by

I just read these sentences in Implementing Beyond Budgeting (Bogsnes):

It is so much easier to add on than it is to take away. You buy a new a box and just put it on top of your other boxes.

Most of us start with Kanban by adding it on top of what’s there already; “start from where we are” is the advice (and it’s good advice).  But what will you dare to take away?

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!