Some advocate hierarchical approaches such as multi-tiered Kanban or Scrum of Scrums, keeping what feel to me like an old-school programme office busy with daily updates, at non-negligible cost to the subordinate development teams. But when the WIP at granularities coarser than Feature don’t change that quickly, isn’t that just wasteful?  Aren’t these approaches designed serve the needs of particular organisational structures created on the IT side over those of the paying stakeholders (or for that matter the development teams)?

So if you’re considering implementing such a structure, ask yourself: what is the problem you are trying to solve?  Is this the solution you really need?

I’m all for making work visible: not just the in-progress features but the initiatives that they belong to too.  And to all stakeholders together, keeping work visible until it is implemented, bedded down and delivering value, closing a loop between prioritisation and benefits realisation.  Facilitating a process that happens as much on the business side as it does in IT.  Blurring the lines even.

But with WIP at each level limited aggressively - including only a small buffer of prioritised but unstarted work - and the level of reporting detail chosen appropriately, is it really such a big deal?  As reporting problems go, it’s easy!  The rubber hits the road in facilitating that next priority call, understanding the bottlenecks, holding out for better outcomes.  No system will do those things for you, so don’t over-complicate things; concentrate instead on making that difference.

Or am I missing something?

Commentary on the twelve principles of agile software

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

Kanban: Check. We pull business value through the system, creating flow.  It should be recognized however that sometimes we create value by means other than delivering software (sometimes even by not delivering software!).  Furthermore, the act of improving the system generates value as it increases the capability of the wider organisation to generate value.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Kanban: Check. We actively limit work-in-progress (WIP), facilitating late prioritisation and minimising the impact of change on lead times.  We actively work to clarify the customer’s priorities so that the team can manage risk by properly sequencing work.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Kanban: Check. We make deliveries at intervals consistent with customer need and transaction cost.  We seek to minimise transactions costs attributable to the software development process, thereby making shorter delivery intervals economically optimal.  Highly advanced teams look towards continual deployment concepts to limit the inventory of complete yet not deployed software. We believe the best requirements come from software already depoyed being exercised by the customers/users. Achieving flow to the end-user generates higher value faster.

Business people and developers must work together daily throughout the project.

Kanban: Check. The development team and customer must learn together, in relation to both the problem domain and the delivery process.  The visual element of Kanban promotes transparency and creates triggers for customer interaction.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Kanban: Check. Build processes that respect individuals; empower them to learn and to improve the system.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Kanban: Check. Visualization and models allow face-to-face conversations to scale effectively. Limiting WIP prompts teams to have conversations DURING difficulties.

Working software is the primary measure of progress.

Kanban: Delivered business value is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Kanban:  We work within and share responsibility for the capability of our system; sustained long-run capability cannot be built at the short-term expense of the individual.

Continuous attention to technical excellence and good design enhances agility.

Kanban: Check.  And we look to increase capacity by identifying and reducing the failure demand that results from inattention to quality.

Simplicity - the art of maximizing the amount of work not done - is essential.

Kanban: Check.  Furthermore we actively manage work-in-progress, minimizing work not finished.

The best architectures, requirements, and designs emerge from self-organizing teams.

Kanban: Check, and process too. Leaders (inside and outside the team) must foster emergence, not squash it.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Kanban: Check. Continually even.

Conclusions

So there you have it, no fundamental conflict but a couple of clarifications and some changes of emphasis too.  It has to be said that these small differences do add up to a shift of mindset, but it is one that much of the Agile community has taken on board as a result of the increasing influence of Lean.

If I were to pick out a key thought it would be this:

The development team and customer must learn together, in relation to both the problem domain and the delivery process.

This lesson would be recognised by much of the Agile community I’m sure.

Key chapters for me:

Chapter 3, A recipe for success.  The recipe has been developed significantly since this blog post (which is still worth a read).  I’ve followed much of recipe myself (some of it pre-Kanban), and it rings true to my own experience.  But full credit to David - if there exists a more effective version of the recipe than his, I would very much like to see it!

Chapter 11, Establishing service-level agreements.  I had heard about this and the related concept of “classes of service” before but it’s all a lot clearer now since reading the book.  It’s a thought-provoking chapter but I had the nagging feeling that it was just a stepping stone to something else (a prioritisation and scheduling mechanism based on risk-adjusted cost of delay) and David kinda confirms this.  That’s not to play down the importance of this chapter though - it definitely adds real sophistication to the generally-accepted core of Kanban, and if a practical guide can lead on to new thinking, that’s a thoroughly good thing.

Chapter 14, Operations review.  This sounds mundane, but it illustrates how a single Kanban implementation can seed something much bigger right across a business unit, breaking out of the confines of IT.  A very timely read!  Taken with the surrounding chapters we have here as good a guide to scaling agile development as you’re likely to read, and it reaches much further than that.

The final few chapters (Part four, Making improvements) are also worth mentioning together.  They take us back to Kanban’s roots in TOC and Lean (particularly Lean product development à la Reinertsen) and the influence of Deming, all in the process of giving yet more great advice.  Nicely done!

Leadership and the mature team

Please give it a read. And be nice to Roy, he deserves it!  For the record, I actually agree with much of his original post, most especially in the value of coaching as a leadership model.

Another favourite red button of mine is “strategic” - a while back I had a team that in my presence would refer to it as the “the ‘S’ word”.   It bugs me particularly when it is used to refer to technologies or applications, and “X is strategic” means “our strategy is to use X”, and that, sadly, is the sum total of any strategic thinking.

So what are your red buttons, particularly in the realms of software development, IT leadership and leadership/organisation in general?

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!

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!

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.

In my previous post, I described a situation in which the testing bottleneck revealed by our Kanban board and CFD was more imagined than real: the work was getting done but completion criteria were inadequate; some clarity and some WIP limits soon fixed things.

Addressing mistakes like that early on in a project is easy, but here are a just a few of the ways in which we have contrived to make life on our projects difficult for ourselves over the years:

1. “Hey guys, we want to do a release soon.  Can everyone please do some testing?”
2. Analysis (and some design), development, testing and rollout in syncronised, pipelined phases
3. An impressively large automated test suite with a hopeless failure rate

Let’s look at these from a lead time perspective.

1. “Can everyone please do some testing?”, or sequential phases

Glossing over the apparent cluelessness, there are problems here common to any approach that has the same set of developers doing a large amount of development (over several months in this case), then downing their IDEs to start testing.  Features developed at the start of the development phase (including some of the most important ones) are already several months old before testing begins in earnest.  This adds a significant context switch overhead even where the original developer is now doing the testing (not something that can be guaranteed over these timeframes), added to which is the worry that the foundations on which that feature was built have since changed.  And those foundations aren’t merely technical - the business context in which the feature was conceived and development will have moved on too.  In other words, the wastefulness of long lead times is compounded by change, both planned and unplanned.

So if sequential phases are a problem, how about doing them in parallel?

2. Syncronised, pipelined phases

This is an approach that may seem attractive to teams that have the luxury of dedicated analysts, testers and release managers.  Why not let each team keep busy on what they do best and allow analysis, development, testing and rollout to happen concurrently?  So while we’re rolling out release 1.1 (on top of release 1.0), we can be testing 1.2, developing 1.3 and readying ourselves for 1.4.  Efficient, right?

Efficient it might be, but from a lead time perspective it’s dangerous.  What happens when one of these activities slips?  The others either stall or take on extra work to fill the slack period.  Taking the latter, “efficient” route adds to the workload of subsequent phases, thereby making the longer cycle the new normal and a descent to low performance begins.

I should mention that I have seen this pattern twice now: the first time it was entered into quite deliberately and lived with for a long time; the second time it was the consequence of allowing testing activities to spill over from one short development sprint to the next.  Those downward descents are so much easier to enter than to leave!

3. Automation (hopeless or otherwise)

However good its coverage, a test suite with an 85% pass rate is a burden, not a help; any new failure is lost in the noise.  Taking that figure to 99.something% was a challenging but worthwhile exercise, but I now take a hard line and insist on 100%, all the time.  “All the time” means that a failure becomes (in Lean-speak) a “stop the line” event.  Furthermore, the depth of the test suite needs to be such that the focus of the team’s manual testing activities can move from repetitive regression testing to focussed learning about the system, warts-and-all (”exploratory testing” in testing-speak).

Pulling it together

Recap: long, sequential phases are bad, whether syncronised or not.  Short cycles are better but aren’t immune to problems, especially if testing can’t be completed right away.  Automation is a help, except when it isn’t.

So: test as soon as features are developed, both by adding to the automated suite and via serious exploratory testing.  Make the regression test a non-event by running it all the time; stop the line when there’s a problem.  In short: practice Continuous Integration (CI) seriously, make learning part of the process, go for flow!

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

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.