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.

From http://www.analysis-one.com/kpi-analysis.aspx

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.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica