In this interview, Larry Maccherone, the director of analytics and research at AgileCraft, explains how you can better use data within your software team. He digs into metrics and measurements within an agile environment and how to determine what data is valuable.
Josiah Renaudin: Well, welcome back to another TechWell interview. Today I'm joined by Larry Maccherone, the director of analytics and research at AgileCraft and a keynote speaker at Better Software East who will be talking about making better decisions with data. Larry, thank you very much for joining us today.
Larry Maccherone: Well, thank you, Josiah. I'm really pleased to be here.
Josiah Renaudin: Absolutely. Before we really dig into the actual meat of the keynote, could you tell us a bit about your experience in the industry?
Larry Maccherone: Sure. I was working on a Ph.D. at Carnegie Mellon University in 2009, where the Ph.D. was really on software engineering metrics; it wasn't very agile-specific. But Watts Humphrey and I, Watts was my advisor, came up with a way to reintroduce metrics back into the agile world, that it largely rejected it—throw the baby out of the bath water, so to speak—because it was hurting agile transformations. We came up with a way to actually do metrics in an agile environment that didn't actually harm the agile transformation.
I gave a talk on that at the 2009 agile conference and I got three job offers out of that talk. The tool vendors wanted me to come work with them and essentially implement this concept into their tools. Their customers were asking for metrics but the coaches were resistant—being the agile coaches, were resistant—so I seemed to have a way of bridging that gap, so that's how I ended up moving over to the agile world, and I was there for seven years or so.
Josiah Renaudin: I think so often with these discussions, if it’s agile or DevOps, we start talking about the actual topic without defining anything. Can you define metrics and measurements, especially within an agile environment?
Larry Maccherone: I really use the words metrics and measurement more to sort of connect with what people are asking for, but really, it's about feedback. Think of a Fitbit, you wear a Fitbit. What if you were to tie the Fitbit to the ceiling fan? That would be silly, right? Because you defeat the purpose of the Fitbit in the first place. The purpose of the Fitbit is to give you feedback so that you can help improve yourself, and I like to think of metrics as feedback, primarily. The other way that I like to think of metrics is in terms of insight.
I have this mnemonic called ODIM. ODIM is basically what I'm about to say backwards. Measurement leads to better insight, better insight leads to better decisions, better decisions leads to better outcomes. And the reason I like the mnemonic ODIM instead of MIDO, which would have been in the order I just said it, is that while that's the effect of measurement, you actually have to start with the outcomes in mind when you're building a regiment.
The NBA has a star. I won't name who it is here because some people get upset, but someone, he's one of the top scorers in the NBA, but some statisticians noticed that when he was out sick or injured, that the team had a better chance of winning. But he was still a high scorer, so how did that happen? Well it turns out that, really, how many points you score in a game are a function of how often you take the shot times what the percentage likelihood it is to go in, and he was a high scorer for the NBA only because he took more shots than all of his teammates who had a higher percentage likelihood of sinking the basket. He was literally stealing balls from his teammates who had a better chance of getting it in. The outcome that the team wants is winning games, and the outcome that maybe the individual wants is to be high scorer so he can renegotiate his contract. But really, you need to pick you measurements in such as way that they drive back to the right outcomes.