Positive Incline

Oh dear, the most embarrassing of lead time diseases! There’s a black hole lurking at the bottom of your CFD, on your Kanban board tokens are piling up under “Ready for Release”, and your “Released” and “Implemented” columns look depressingly empty.

Common root causes:

1. Inattention to the release and implementation process
2. Lack of capacity (whether on the part of the project team or customer) to release &/or implement
3. The system as built isn’t the one expected by the customer
4. The world has changed

Clearly the first two aren’t mutually exclusive. Fail to plan or to reach agreement, and you may find that your customer or some critical resource on which your release depends is unavailable, perhaps for a long time. Lesson: take nothing for granted.

Agile methods have the most to say about the third cause. Forget blaming the specification if you get into this situation - products (not just documents) must be developed in partnership with the customer and the risk shared.

Sometimes there’s not much you can do about that last one. Volcanos, credit crunches, takeovers, high level changes of budget or focus do happen, and generally speaking it’s not worth trying to mitigate against them. But we live in a changing world, and projects need to be managed flexibly, serving the greater interest. Embrace change!

Symptomatic relief

Putting the (sometimes correct) “abandon” option to one side, extricating a project out of this situation involves both hard work and creativity. Do (or do again) what should have been done earlier: start with the customer, work backwards on implementation and release plans, revisit requirements as necessary. Try parallel running, emailed spreadsheets or screenshots, re-purposing, “re-customering” even - whatever it takes to get eyeballs on the system.

During this period you may be able to deliver positive business value even before systems are officially switched on, with (for example) data quality or business process issues revealed and addressed that might otherwise have gone undiscovered. This has happened for me on multiple occasions, so don’t despair, keep a positive eye open.

Prevention

We know already that the answers lie in small batches (”release early, release often”), visibility, engagement, automation. Taking a Lean approach, strive continually to reduce transaction costs - in this context, mainly testing, release and implementation costs - and (more sophisticatedly) factor risk into the batch size calculation. Both will lead to yet smaller batches, shorter cycles and a much reduced likelihood of project failure. Once again: go for flow!

Still suffering volcano aftermath, I and my co-driver took the borrowed car back to Budapest from the UK, arriving before dawn this morning. So I’m making this one short:  a tip and a regret.

Tip: Consider adding “On Hold” columns to your Kanban board, especially “Development On Hold”.  When you have too much in play, it pays dividends to make explicit what work is to be put to one side .  At worst, you prevent the waste of talking about it every day; at best, you create real capacity.  Reinstate work only when it becomes genuinely top priority again, and no copping out with “background projects”!

Regret: The “counting tickets in columns” method for generating CFDs (see Kanban in a nutshell) is nice and easy, but I have to admit that I wish now that I had better control over the display of data from abandoned (one, small) and reorganised (e.g. adopted or outsourced) projects.  They have annoying negative effects on the chart that are difficult to remove retrospectively.  But would I go back 8 months and use an electronic Kanban board?  Maybe, not sure - I still love my wall!

The testing bottleneck episode came out mid-way through a fantastic week’s skiing in Val Thorens; since then I got stranded by in Budapest by the volcanic ash cloud, made it home (5 days late) after an epic 25-hour drive, and I have a borrowed car to return next week!  So to get the Lead time diseases and treatments series back on track I’m combining the closely-related episodes 3 and 4.  I’ll introduce them separately before discussing them together.

3. Feature starvation

I don’t recall seeing projects suffer for lack of needed features, but what happens when there has been a failure to prioritise and articulate clearly the next few features for development?  Developers tend not to sit on their hands doing nothing, so work expands to fill the available effort.  This plays out in several ways:

• Gold-plating work currently in progress
• Implementing non-urgent features
• Inventing un-needed features
• Indulging in standalone refactorings, framework-building, etc

In other words a tendency to add bloat, risk and downstream workload for marginal or even negative benefit.  Not only is the delivery of value sub-optimal, lead times will increase in ways that are hard to pinpoint. The smart product manager needs to recognise and treat the problem at source, which will be uncomfortably close to home!

4. The overwhelming backlog

Maybe it’s just me, but “backlog” seems to come with an implication that the work contained therein does actually need to be done (and soon), and therefore carries overtones of “push” rather than “pull”.  I try to avoid the term therefore, and my advice to backlog worriers is simple: don’t!

• Don’t be overwhelmed (yeah, right)
• Don’t think in terms of clearing the backlog
• Don’t over-prioritise
• Don’t over-engineer - sometimes synergistic features line up at the right time but don’t force it; YAGNI

The first two are a prelude to shifting to a mindset of prioritising for delivered business value, letting go of the rest.  The last two are about controlling work in progress even in those early Kanban columns, not committing prematurely, going for flow.  But realise that the combination of low WIP and an obsession for business value demands timely and high quality interaction with stakeholders; this may prove to be a significant constraint.

Two sides of the same coin

So… under-prioritisation tends to lead to bloat and (indirectly) to longer lead times; over-prioritisation also leads to longer lead times (this time through increased WIP) -  it’s an optimisation problem.  It’s a high stakes game, controlling perhaps the most powerful short-term lever on your development process.  Exciting!

Ultimately though, the lead time metric is only a proxy for real measures of success; the latter lie in the domain of the customer’s business.  Don Reinertsen’s superb book Principles of Product Development Flow goes much further than process-centric metrics and describes an economic approach to prioritisation; for introductions to the subject see articles from Dean Leffingwell and Silver Catalyst (the second hot off the press from last night’s LeanSSC keynote - I would so loved to have been there!).  But even if your organisation isn’t ready for an explicitly economic model, I hope that you find - as I did - that the concepts are helpful and motivating as well as enlightening.

Consider the following CFD, based on data from the early part of a new build project:

There are several interesting features to point out:

1. A somewhat S-shaped overall profile
2. The stepped profile at the project’s start
3. The “bulge” of items stuck in the Testing state

Each of these represents a learning phase; let’s examine them in turn.

The S-shaped profile

I had a strange flashback when I first noticed this shape - having encountered it before in Earned Value charts, where the shape represents the fact that when tracking completed deliverables against a project plan you often see ramp-up and ramp-down periods.

Here though, the overall height of the CFD at any point measures all known work, whether that’s work done, work in progress, work that’s prioritised, and even work that just on the “maybe” list.  Isn’t the overall work required fixed for the life of the project?

There are at least three drivers to this particular ramp-up:

1. As our understanding of the problem space increases, so does the known number of features required (or possibly required).  This process can get off to a slow start.
2. As development gets properly underway, the number of features increases because large features (the “epics”) are split into several smaller ones.
3. Feedback: what we learn from building and demonstrating the system creates opportunities for new and better requirements.  This process slows down as we get close to something releasable.

None of these disturb me fundamentally (I’m not of the “scope creep” school) but it does demonstrate the dangers inherent in making projections if it’s clear that requirements are still to be discovered.  There’s a tradeoff: if you want learning you lose some certainty.

I won’t deny that there are projects where certainty is of paramount importance (I’ve led some, with hard timelines mandated externally), but in most cases I would much rather take the learning approach.  You get to start earlier and deliver earlier, and there are opportunities to incorporate valuable (sometimes project-critical) feedback early, not just from within the confines of the project but from a changing business environment too.

[And yes I'm familiar with the argument that we should move away from organising work around projects, but that's definitely for another post]

The early stepped profile

Early in this particular project we tended to follow a regular pattern that looked a bit like planned sprints.  I had just come off a project that worked to time-boxed iterations whose CFD would have been similar,  but here this shape was merely a symptom of my unconventional working arrangements - I spent alternate weeks in and out of the offfice and planning activities were concentrated around set times.

It’s actually rather gratifying that this disappears over time as we establish good working patterns independent of my physical location.  Even so there’s still an unnecessary amount of work sitting in the Ready for Dev state at any given time (arguably the same could be said of Prioritised too), but we’ll revisit that issue later in this series.

The Testing “bulge”

I was happy to explain away first two CFD features but this bulge reflects a genuine problem.  Work really was piling up in the Testing column, flattering our development throughput whilst doing bad things to lead times overall.  We’ll focus on testing in the next post, but for now it’s fair to say that this reflected two wider problems, namely the absence of strong controls on WIP and the lack of clear exit criteria for each step in the value chain.

As a team we identified both issues in one of our retrospectives, the outcome of which was to define (1) WIP limits (see Kanban in a nutshell) and (2) how & when code review and feature demonstrations were to be conducted.  We addressed both sets of issues at the same time so we can’t measure their impacts separately, but it’s apparent from the CFD that the overall problem was reversed very quickly.

Points to take away

1. You can expect your CFD to reflect something of your project’s style
2. After a while it tells a story; feed this back into your project retrospectives
3. Changes in working practices can be reflected back surprisingly quickly

So you have your Kanban board (mine is a wall covered in Post-It notes), you’re maintaining a CFD and you’re measuring your development process’s lead times.  But despite the best intentions of you and your team you see your lead times creep up.  What to do?

Don’t panic

There will be some natural variation in even the best-regulated of processes, and it’s inevitable in a creative process like software development. Some (for example the Statistical Process Control crowd) will tell you not to worry unduly about variations within so many standard deviations of the mean, sensible advice that may stop you from wasting effort on investigations that may yield little benefit.  But still raise it with your team (it’s a great standing topic for regular project retrospectives), try to work it out together.  “Special causes” may be mundane (unplanned absence or environmental unavailability, say) or remain as minor unsolved mysteries with no lasting impact.

But don’t get too comfortable either

Don’t rationalise away every problem and as a result miss opportunities for lasting improvement.  Even those seemingly mundane special causes may have serious underlying root causes that represent significant risks to your project.

What’s more, don’t compound that error by allowing a drift to low performance (very well described in Dana Meadow’s book Thinking in Systems).  Instead, surround your project with an expectation of improvement.  Free your team to be the engine of that improvement.  Review the data together in your retrospectives; experiment!  Establish performance baselines from your recent history (don’t set arbitrary targets - insert obligatory Seddon reference here!); you can let them and your tolerances for variation ratchet down over time as each improvement kicks in.

Learn to diagnose

Looking back over past projects, I recall some times of less-than-spectacular project performance, impacted by process issues that I’m sure will have been encountered countless times elsewhere.  I have seen them across a range of situations: in mature teams that I’ve inherited, in project turnarounds, and in new developments that I’ve led from the start.  I need not spell out here which disease belongs to which situation and thereby the degree of my culpability; it is better simply to assume that each was my fault!

These issues are like diseases - they have recognisable symptoms, common root causes and it’s often possible to recommend treatments.  So watch this space for these future articles:

1. Learning curves
2. The testing bottleneck
3. Feature starvation (with 4)
4. The overwhelming backlog
5. Kept on hold
6. Failure to launch

Of course other diseases are known, and more still are yet to be discovered, named and documented.  If you would like to add to my list, leave a comment here or drop me a line and I will discuss them when I wrap up this series.

Step back, squint a little, and think of your development project organised in a big to-do-list.  In your imagination, pin your to-do, in progress and done deliverables onto a board like so:

Hold that picture for a few more moments and visualise those tokens moving across the board as work gets done.  See how items pass quickly through the In Progress stage when only a few are allowed there at at any one time; watch the whole process slow down as work-in-progress (WIP) is allowed to grow.

That three-stage process is of course an over-simplification, so let’s map it out in a little more detail.  In Lean-speak, we’re identifying our particular process’s “value stream”.  Here’s a representation of mine:

In my model (yours may differ):

• Proposed items could (but perhaps never will) get done; they are subject to a prioritisation process
• Prioritised is where pre-dev analysis work gets done if any is needed
• Ready for Dev is a buffer between the prioritisation and analysis activities the the left and the core Dev and Test activities to the right.  It’s handy too for forcing the sequencing of some prioritised items ahead of others.
• Ready for Release is another buffer - we can’t always release immediately
• Released is Done, Implemented is Really Done^TM. When that distinction isn’t important, items go straight to Implemented.

The items here are all features, recognisable by the people that sponsored them, even where the team has chosen to break the larger ones down to manageable size.  On those rare occasions where we need to break work down into pieces smaller than a working feature (into tasks, say), that breakdown goes into our Trac system but not onto the board - we’re interested in delivering value, not just tracking how busy we have been!

Then there are two rules for choosing what to work on:

1. Pick a rightmost available feature (e.g. prefer one in Test over one in Dev)
2. Don’t move an item into a column if doing so will breach a work-in-progress limit.  If that leaves you with no available features, go and help someone else complete theirs.

In a sentence, Kanban is a WIP-limited, pull-based system for feature-driven software development.

What makes for an “available” item here will depend on local factors: roles, skills, approvals to make high-impact transitions (e.g. releases), and so on.  I’m told that some teams - especially those that (i) practice pairing, and (ii) don’t have much differentiation between roles - find that WIP is limited naturally, in which case rule 1 suffices on its own.

But every team is different!  Initially, my team did without WIP limits but found that work didn’t flow quite as well as we expected; later we added a limit that spans the Dev and Testing columns, set (with buy-in from the team) low enough to encourage pairing.  That limit is so rarely reached now (let alone breached) we could consider removing it again.

Add some local rules for dealing with exceptions such as rework or unplanned urgent work, and that’s pretty much all there is to it.  With a bit of thought there should be nothing about Kanban that precludes it from being implemented on top of an existing process - probably a good starting point for most teams.

The control tools

These are simple too:

1. The Cumulative Flow Diagram (CFD) - the counts of items in each column recorded over time and shown in a stacked chart, completed items at the bottom. Brilliant for visualising lead times and bottlenecks.
2. Lead times (read off the CFD or captured on a per-feature basis) tracked over time

Here’s a CFD:

If that seems too complicated, we can go back to the simpler to-do list model:

but bear in mind that your definitions of “To Do”, “In Progress” and “Done” may differ from your customer’s, so be careful.

What makes the CFD a really useful tool (I refer to mine a lot) is that the widths and heights of those coloured bands give (respectively) average cycle times (lead times if measured from the “Prioritised” stage) and WIP. It is very interesting to see how these correlate over time - they tell a story about the progress of your project that you can use in your retrospectives and feed into your improvement process.

Next up: a series on lead time “diseases” with some Kanban-inspired remedies.  Watch this space!