Jaime Gago Condensing Information Systems From the Vapor Of Data

30Jul/140

Why You Should Measure Lead Time Systematically

devopsdays-logoAbout a year ago, I was interviewing quite a bit and many of the jobs had "DevOps" somewhere either in the title or the description, unfortunately several times I felt like the companies that were trying to hire me hadn't done their homework in terms of researching what DevOps is about. Luckily around that time Gene Kim was presenting at an SVDevOps meetup and gave an excellent tip about gaining fast insight about a company status in terms of DevOps practices: "Cycle Time" (aka "Lead Time") and "Deployment Rate".

Now let's face it while some people are already talking about "post DevOps", there is still a lot of room for improvement. It's just my personal experience,  so it has no statistical value, but none of the people at the companies I talked to could actually provide these metrics, and I've been talking to several Small Business, Startups and Enterprises that deliver Software and are located in the Silicon Valley; so that must mean something.

Now why would one focus on Cycle Time and Deployments rate (two very closely related metrics)?  In addition to being a supply chain critical KPI, the systematic measuring of lead time enables continuous improvement by providing a track record to compare against, basically without it to misquote Eric Ries any improvement tentative will be a success,  a success at seeing what happens... Yes once you start measuring the numbers might be scary at first, so scary that this is probably the reason in the first place that practice doesn't seem very common in our industry. The thing is whether a company that produces software measures it or not, it has a Lead Time and a Deployment rate, so Temet Nosce Neo!

I understand the "let's give it a shot and measure this one cycle time manually" approach, it's cheap in terms of resources and can be done in a snap, but it potentially can deliver wrong data, and if you're trying to make data driven decision, you're out of luck. It's ok to get an initial ballpark number, but since Cycle Time is so critical the measuring should be systematic and fully baked into the delivery pipeline (which yes ideally is automated). The manual sporadic measuring not only limits us to a sample that will be less and less representative of reality as the cycles counter increases, it also taints the actual measurement because of the "observer effect", we're only human and if we say we're going to pay attention to this particular cycle, chances are we'll have an effect on it that will make the measurement very close to useless. In that scenario manual sporadic lead time measurement is not only a waste of time but more problematically delivers wrong data to the business in general and to the software delivery team (developers, testers, analysts, ops, etc) in particular and that just plain sucks.

So let's act like scientist and not fall into the "Theater Ops" trap, because Science, after all, it works bitches!

 

 

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

No trackbacks yet.