Tag Archives: Kanban

2011: Another big year

Posted on by

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

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

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!

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