The "Show Me the Money" Approach to Software Development: An Interview with Michael Harris

Josiah Renaudin: Today I'm joined by Michael Harris, the president and CEO of David Consulting Group. We'll be covering his five-step Value Visualization Framework and the significance to your team or organization.

Michael, thank you very much for joining us.

Michael Harris: Thanks.

Josiah Renaudin: All right, first, could you tell us just a bit about your experience in the industry?

Michael Harris: Sure. I've done a lot of things in the industry, so I guess it's been over thirty years now. Most recently, for about the past ten years, I've been president, CEO, and owner of David Consulting Group. We focus on helping our clients improve their software development. More and more, we focus on helping them deliver value from software development, and that theme's going to come back again and again as we talk today, I think.

Before that, I was head of a fairly large software development group and a company called Sanchez Computer Associates, who were acquired by Fidelity Information Services. A lot of my thoughts, lessons, challenges that I see in the industry have come from that time.

Josiah Renaudin: Now, before we really dig into the meat of the interview, in short, can you explain your Value Visualization Framework for the software development lifecycle, and how you came up with it?

Michael Harris: Sure. Maybe I'll answer those questions in reverse order. How I came up with it was that I've been both in the trenches and working at an executive level with teams doing software development, and what I see happening is that, although within the context of software development all the developers, all the testers, all of their team leads and everything else work with the best interest of moving the software forward, often there's a disconnect to the business in terms of what the business actually gets out of it at the end.

This was brought into sharp focus in some work that I did in the UK with a major client in the UK probably about two years ago now, where there was a tremendous amount of money being invested in software development. It was core to their business value proposition, and yet the businesses were turning around to their software development and asking him to justify the value that he was providing for the money they were investing, and he couldn't do it, it was hard to do. He had a tremendous number of metrics, knew exactly what productivity was, was working with a lot of offshore vendors, but couldn't actually pull out a statistic and say, "This is why we're delivering value." As we dug into that a little bit, we saw that half of the problem was the business actually wasn't really providing the information to allow the software development group to prioritize by value, as opposed to prioritizing by other things.

Over a period of time, what's evolved is this Value Visualization Framework. It's a way for people in that sort of situation of, "Justify what you're doing and maximize the value you're delivering to us." To actually go through a series of five steps and come up with some metrics around value. This has to be a collaborative process, so when I talk about the five steps, the first one is to define the units of value delivery. You can't do that without a conversation between the business and the software development group. The units of value delivery might be, say it's a website, it might be the number of subscribers, it might be the hours saved in a particular business process if it's an application for in-house staff. There's a unit of value that the business consider, "We'll be getting value if we have some of these units of things.

Then for a particular project or story or feature or epic, you need to define the value of that particular story or epic in specific units. If we're using number of subscribers for instance on a new website, then you have a number for that, so, "We think that this particular story or epic will produce maybe fifty new subscribers once we deploy it." That really is, again, a heavy interaction with the business, but now the IT and the software development team have to come in and say, "Well, just how big do we think this particular story might be?" We can define the size in a number of ways. What we're really looking for here is to get an agreed view, an early stage of, "Is this complicated? Is it going to require a lot of resources? Is it going to take a lot of time?" Story points is not a bad proxy for this, but there are other things you can do it with function points and other things. The key is that step three is to define the size.

Then step four, this one's a really critical one in terms of economic value, is that you have to define the cost of delay. For this particular story or project, what's it going to cost us if we delay it? That's a real critical metric for prioritization against economic value, and it's one where people stop and balk and say, "How can we possibly define that?" You know what, t-shirt sizes. If you can just say, "Small, medium, or large." That's better than what we've got at the moment, because this is the sort of thing that the development team should be making their decisions on when they're prioritizing, picking up one story over another story.

Finally at step five, once the story is actually delivered, then there is where you actually quantify the economic value, because economic value is changing over time, and if we project a value up front, that could change dramatically, so I'll come back to my example of, "How many subscribers is this particular story or project going to deliver when we deliver it?" It may be that you're growing a new website, you're selling advertising on that, and there's some steps, some critical sizes in terms of number of subscribers that define the value that you can get, the money you can bring for the advertising. When you started the project that might've been twenty dollars per subscriber. Let's be realistic, let's say, .001 dollars per subscriber. By the time you get to actually deliver it, because you've got more of a critical mass, and this particular project's going to attract even more, you might've doubled that value. Equally, you could've halved that value.

This is something you look in retrospect, what would be a scenario where you might halve that value, maybe the world's moved on. Maybe you had some breaking news, some big thing that everyone was looking at, at the start of the year, and so you were getting a lot of traffic, but now you're not getting so much traffic, and so the actual advertising that you can sell is smaller. This is why it's important to do step five when you deploy, so you get an accurate visibility of what the true economic value is, rather than the guess from right when the project started.

To summarize the five steps again, define the units of value, define the value of a particular project in those units, define the size somehow, define the cost of delay, and then finally, step five, quantify the economic value when you deploy it.

Josiah Renaudin: Over the course of your description there you used the word “team” a few times. How important is collaboration when it comes to defining values and making key development decisions?

Michael Harris: There's two levels, really, I think. One is the interaction with the business. This is critical. One of the things that I've seen time and again in my career is that the business is very good complaining about what software development provides, but doesn't provide enough information first for the software development team leads and teams to make good decisions about how they prioritize their work. You can't have it both ways, you can't provide scant information and then expect good results. The collaboration between the business and software development team is actually critical.

As far as the software development team itself is concerned, I think the collaboration there is critical as well, because you need to make sure you're making decisions, prioritizing things, based on economic value, not based on the typical things that we do today. We're typically based on resource availability, we typically prioritize based on who shouts the loudest, and the loudest voice may not necessarily be the most economically valuable business project. The collaboration has to continue within the team, and it's a constant review. "Are we delivering the best value we can for the business, and do we have the information we need to be able to deliver that? If not, where can we get that information?"

Josiah Renaudin: One of the most popular methodologies right now, as everyone knows, is agile. It's something we hear about all the time. Can you compare your method to something like agile? I know yours is original, but what makes your process different and even, possibly, if you want to say so, more effective than agile?

Michael Harris: I hate to claim that it was an original; it's more of a accumulation of different ideas that we've gathered that we've gathered up over time. I love agile. I think agile is a great way to drive better business value, and this is really what you see, I think this is why businesses love it, but the problem with agile is that the value is implied, it's not explicit. When we're doing a waterfall project, we get a huge list of things that have to be delivered in a release. Generally there's some sort of threshold, they're in the release or rather not be in the release, so that implies some value, but there's such a big collection of them that really could be getting information about what the priorities were within that.

What agile does is it shortens the release time, and it creates a focus in terms of a backlog of prioritization that's come from the business, you hope, through the product owner, to prioritize what's being addressed in each sprint, by looking at things like size. Some of the ideas in the Value Visualization Framework are implemented in many agile processes. We're looking at size, we're estimating size, we're trying to work out how much we can fit in a sprint or in a program increment. But even in agile the value is not explicit, so we draw some information about the value from the prioritization, but especially in large agile implementations, what I see is that the business value, the economic value is lost. It may have existed when a business case was created, but by the time it's been broken out and broken down and there's an understanding between the product owner and the rest of the team, he's got some sense of priorities but not necessarily business value.

At the end of the process, and this is what head of software development in the UK was facing, at the end of the process he sort of lost in terms of what value was actually delivered by the team. He can say, "I think we developed the most top priority things." But doesn't really know how much value was delivered, and so because you don't have that explicit information you're always taking the chance that the agile team is still delivering the things that are being shouted for the loudest, and the things that are the best fit for the resources they've got available as opposed to maximizing the business value and looking to see what other resources they need to be able to do that.

What I see happening is that the value information from the business is not penetrating down to the individual team level in an explicit way. The Value Visualization Framework at least forces the team to ask those questions.

Josiah Renaudin: Value is a really important word here, so to close, I really want to dig into what the real, applicable value of going through this process is for a team or an organization. What benefits can teams expect to reap both in the short-term as well as in the long-term if they adopt this?

Michael Harris: Short-term, it starts a conversation. Short-term it has the teams, both the business team and the software development team focusing on economic value as opposed to most convenient path of least resistance. You know, "What resources have we got available? What skills have they got? Therefore we'll do that job first. What's the smallest job we could do? Therefore we do that job first." As opposed to the one which delivers the most value. I think in the short-term just having a conversation, and maybe not even being able to do all five steps. Maybe you can only do three of the five steps, but being aware that the other two exist is hugely important in terms of always trying to prioritize the most valuable job as opposed to the next easiest one to do.

In the long-term, I think what this does is it starts, and this is what is in play now in this client of ours in the UK, is it starts to allow you to measure what value is being delivered. If you can see, these were the requests for value that went in the front end of the system, this is the actual value that's coming out of the other end of the system if you treat software development as holistic system. Then as you see challenges with that then you can start to tweak the system to maximize the value being pushed through. You're now looking more at a type of system where you can actually start to spot bottlenecks that are preventing value from getting through the system. You're doing it based on maximizing value, as opposed to just maximizing throughput of stories. You want the most valuable stories through, not necessarily the easiest ones.

I don't want to trivialize that. I think it's important to say that sometimes what we do is we associate the biggest value things with the biggest things. The ones with the biggest size. Those things don't pass well through a system. Generally speaking, the things that pass best through a system if you can break them down to small size, break down stories, break down epics into stories, and so on. Often the most valuable things have to be grouped together in order to deliver their value. The complexity of it comes from breaking those things down into smaller chunks that can still deliver value.

This client that we work with has a phrase called “orphan stories.” What orphan stories are—there may be a business case that yields ten million dollars, for example, around a set of stories, and nineteen of the twenty stories that are needed to deliver the value go through the system, but one gets lost because in and of itself the development team had no information about how it fits with the overall business value, so it seems like a low-priority, fairly small story. But the twenty million dollars can't be delivered because only nineteen of the stories necessary are there—the twentieth one is stuck in the system, it's orphaned somewhere in the system. There's a delay on delivering the overall value, and potentially a really punitive delay, because of the orphan that's got left behind because it wasn't obvious to the team how it fit with the business value.

Josiah Renaudin: All right, fantastic. I think there's a lot of great information for people to dig into there. Thank you very much for stopping by and talking with us, Michael, about your five-step Value Visualization Framework, and I hope to hear more from you in the future.

Michael Harris: Excellent, thank you.

Michael Harris has more than thirty years of broad management experience in the IT field, including periods in R&D, development, production, business, and academia. An author and speaker on a range of topics related to the Value Visualization of IT, Michael is considered a thought leader in the international software development industry. He became president, CEO, and majority owner of David Consulting Group (DCG) in 2006 and previously held numerous senior executive positions in Fortune 500 companies, including: Fidelity National Information Services (NYSE: FIS), Sanchez Computer Associates (NASDAQ: SCAI) and MasterCard International (NASDAQ: MA).