Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.
One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.
But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.
If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.
Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?
This client first tried to do more features. They tried to do features in iterations. Oh, they tried.
By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of 12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.
I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.
If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.
So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.
Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?
They finally did fund this project, after about six months of hobbling along.
After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.
After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.
What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.
People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.
This is a dramatic story due to technical debt. I bet you have a story just like this one.
The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.
If you eliminated a technical debt impediment, would that change one of your costs of delay?
