Skip to main content

Lead and Lag Measures for Agile Transformation

"Oh for goodness sake, you put it in upside down!"
"I'm sorry, Secret. I thought the pointy end went in first."
-Secret Squirrel and Morrocco Mole, Secret Squirrel

I'm always excited to learn something new, and this week a colleague introduced me to the "Lead/Lag" concept of measuring the performance of a change program such as an agile transformation.  He also introduced me to the "Secret Squirrel (and Morocco Mole)" Hannah-Barbera cartoon series from the 1960s, which briefly seemed to be a more interesting thing to discuss, but I'm pretty sure you guys should all pursue that on your own without further commentary from me.  We agilists are a fun bunch.

From wikipedia
Seriously, though, this Lead/Lag thing gets you exactly where you want to be as you design your agile transformation, and it keeps you from drowning in a pool of agile purism. "Is not Scrum/Is so Scrum" is not the discussion you want to be having for very long, especially when accompanied by ineffectual slapping. You want to be looking at "Is not valuable/Is so valuable."  And yet if you solely focus on "what is valuable for the business," what makes you different as an agilist from anyone else?

This is a serious question and I will conjecture that some of us in the agile/lean community focus so much on "pure" agile behaviors because we are worried we will lose our identity if we throw ourselves whole-heartedly into a process of self-improvement which deviates from some well-known agile or lean script.  Witness the large-scale prejudice of the agile community against the PMI and the BABOK.   We've got excellent pioneers working to put PMI/BABOK/CMM insights to work in agile shops, but they need to be very brave and very impervious to sarcasm.

Anyway, enter the Lead/Lag indicators, perhaps in a Secret Squirrel flying saucer. The lean/lag concept, as most of you probably already knew, is one where you purposely track two sets of measures over time with the expectation that they will correlate. For an agile transformation, the "lead" measures would be things like:
  • Do you have teams that develop iteratively?
  • Is there a card wall?  and even
  • Would Jeff Sutherland certify this team as one following "pure Scrum"?
You can empirically measure how many teams you have that do these things over time, and how well those teams are doing your local form of agile "correctly," as specified for your company, and this is certainly something you want to do if you are heading up an agile transformation program in an enterprise environment.

The "lag" measures, however, are the ones which will motivate your stakeholders.  They will be things like :
  • Increased speed to market
  • Higher code quality
  • Better ROI on dollars invested in IT projects
As you design your program, what you want to do is motivate your stakeholders using the lag measures, and build a case as soon as possible for a correlation between what you measure around the penetration of your chosen agile practices into a firm, and what impact those measures seem to have on things of value to the business.

Thought of this way, there are things you should think about measuring that you might not otherwise do, because they are "obvious" to you as an agilist.  One example is "transparency."  As agilists, we take it for granted that since agile produces working software with every iteration, a program office running a set of agile practices will have the ability to measure EXACTLY what percentage of planned scope is complete at ANY time after the release plan is created.  But for someone new to agile, this concept is not obvious.

So one thing to think about is creating side-by-side snapshots taken at two-week intervals of the "project health dashboard" your PMO keeps on its waterfall projects, and corresponding snapshots taken at the same interval of the health of your first agile projects.  If you're honest, most likely the agile projects will track red at first, not least because the team is processing a lot of new stuff.  Later the projects will go yellow and green.  That's good.

But what is GREAT is that while your agile "health" dashboard is telling the truth every two weeks, the snapshots of the waterfall projects will show a pattern of "all green until red" or "all amber until red" or "all red, then suddenly green," or the like.  The point is that in a waterfall project, you JUST DO NOT KNOW if you are actually okay or not until the day you go into user acceptance testing, and sometimes not even then, if UAT looks bad enough.  By measuring "transparency of project health" through snapshots at the company where you are introducing agile, you make the change concrete and immediately apparent.  This is the type of metric that will "motivate" even the most senior and agile-unfamiliar CIO "elephant," in the terminology of Dan Heath and Chip Heath.


I am on the road, so I can't get my teenager to explain this graph to you in detail, but the general idea is that by measuring some simple and straightforward things, you will be in a position to do some dynamite and statistically interesting "lean/lag" metrics reports to your agile transformation sponsors weeks or months into your project.  The faster you can get a correlation between "we did this agile practice, and here's the benefit to the business," the faster you're going to get enthusiastic buy-in from your stakeholders, instead of eye-rolling and nervous references to the "TQM" fad from the 1980s.

Moreover, measuring this way keeps you honest.  What key business performance indicator can you impact most quickly in your context, and how?  Maybe you should lead with automated testing, not the business case.  Maybe it's the opposite.  But even if you don't share with your stakeholders (in many cases the truth is something to be very careful with), YOU should know what you're doing and how it matters to the business, with as much quantitative evidence as you can muster.

So don't stop with "we're agile!"  Drive directly to "we're agile, and you can tell, because the business is already better."  Don't settle for putting the pointy end in first.


Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …