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?
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:
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.