The Cost of Rework No One Talks About

The Cost of Rework No One Talks About Here’s a number that stopped me cold when I first saw it: 30 to 50 percent of all effort on software projects is spent on rework. Not building. Not shipping. Redoing work that was already done. That stat comes from software measurement research that’s been replicated across multiple studies — and yet somehow, it doesn’t come up in sprint planning, or project retrospectives, or any of the conversations where teams talk about why things are taking longer than expected. How to connect with AgileDad: - [website] ⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠ https://www.agiledad.com/ - [instagram] ⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠ https://www.instagram.com/agile_coach/ - [facebook] ⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠ https://www.facebook.com/RealAgileDad/ - [Linkedin] ⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/ https://www.linkedin.com/in/leehenson/

• 0:16Speaker 00

  Here's a number that stopped me cold when I first saw it. Thirty to 50% of all effort on software project is spent on rework. Not building, not shipping, redoing what's already been done. Just makes me sick to my stomach. That stat comes from software measurement research that's been replicated across multiple different studies and yet somehow it doesn't come up in sprint planning or project retrospectives, or any of the conversations where teams talk about why things are taking longer than expected. Because rework has a great cover story. It gets filed under iteration. It gets called part of the process. It hides inside phrases like, "We need to revisit this."

• 1:01Speaker 00

  And, "Well, requirements changed." It's practically invisible on a project tracker because it looks exactly like regular work. New tickets, same effort, different outcome. But the hours on the ticket aren't the real cost. The real cost is everything the hours did not capture. When a team reworks a feature, the time's the obvious part. Four days to build it, three days to rebuild it, that equals seven days total. The budget takes a hit, the deadline slips. That part's the part that gets noticed. What doesn't get noticed is that rework code is slower to write than the original code. Research from software measurement firm Scope Master found that productivity on rework runs about 25% lower than on the initial builds.

• 1:46Speaker 00

  Because you're not writing it from scratch. You're navigating decisions already made, trying to preserve what still works while changing what doesn't. You're reading your own old code, or someone else's even worse, trying to figure out where to cut without breaking something else. That takes a lot longer. It always takes longer. And it compounds. That's the worst part. A medium-sized engineering team could lose upwards of $4.7 million a year to unnecessary rework, according to Dora Research. Let me read it to you one more time. "A medium-sized engineering team can lose upward of $4.7 million a year to unnecessary rework." That's just crazy.

• 2:29Speaker 00

  And that figures only, that figure only accounts for the wasted hours. It doesn't account for delayed features, missed market window, or the work that didn't happen because the team was busy going backwards trying to go forwards. The harder cost to measure, and what almost no one talks about, is what rework does to the people that are doing it. Nearly three quarters of software developers experience burnout at some point in their careers, according to data from Runz Engineering Productivity Research. That's significantly higher than the average burnout rate across all industries. And while there are many contributing factors, constant rework is consistently listed among the top triggers. It's not hard to understand why. There's a specific kind of exhaustion that comes from redoing work that you've already done.

• 3:14Speaker 00

  It's different from the tiredness that comes with a hard project. Hard projects feel like progress because you're still moving forward. Rework feels like running on a treadmill. You're working just as hard, but you don't seem to be going anywhere. Over time, that feeling kills your motivation. Developers who deal with frequent rewrites show higher rates of disengagement, and disengagement leads to lower code quality, which leads to more rework, as flagged in Haddock's 2024 Engineering Benchmark Research. It's a cycle that feeds itself, and most teams never connect the two ends of it. There's also a specific toll on senior leaders and senior developers. Stack Overflow's 2024 Developer Survey, I think they did over 65,000 respondents,

• 3:58Speaker 00

  flagged something worth paying attention to. For the first time, senior developers reported lower job satisfaction than the junior ones. A big reason cited was the volume of maintenance, remediation, and repeated work. The developers with the most context, the ones who understood the system the deepest, are spending their time redoing instead of building, and they're not enjoying it. That's not just a morale problem, that's a waste of your most expensive people on the team. The thing is, rework usually, it isn't usually random. It tends to come from a few predictable sources. Vague requirements signed off too early. When a team starts building requirements that haven't been properly clarified, they're making assumptions at every decision point.

• 4:42Speaker 00

  Those assumptions get baked into the code. And when someone eventually catches the gap, a stakeholder review, a usability test, a demo, the assumption has already been undone. It has, or I'm sorry, the assumption's already been done and has to be undone. That's how I should say it. The later in the process this happens, the more expensive it becomes to undo it. Scope Master's research consistently finds that poor communication, not genuinely changing business needs, is the root of most rework. Requirements that felt clear in a meeting weren't. Nobody pushed back. The build started anyway. Feedback arriving at the wrong stage is another issue. Design decisions are cheap to change on paper, but they're expensive to change once you built the product.

• 5:24Speaker 00

  And they're very expensive to change after everything's in production. When stakeholders give feedback late, which often happens, because they need to see something before they know what they want, the echo-wishy disease, I'll know when I see it. The rework happens the most costly possible point. Here's another one. Technical debt borrowed in a hurry. Shortcuts taking to hit a deadline don't disappear. They stay in whatever you're building. And eventually, someone has to pay the piper. Someone has to pay bad. Developers spend an average of 13.5 hours a week on technical debt alone, cited across multiple 2024 engineering productivity reports. That's a third of the working week. Every week going to pass decisions. That's terrible.

• 6:11Speaker 00

  One more cost that doesn't appear in any tracker. The people who leave the company because of it. When teams spend more time rebuilding and building, the developers who care the most, the ones who want to ship things that they're proud of, start to disengage first. They're the ones most frustrated by waste. According to Gartner's 2024 Workforce Productivity Report, each developer who leaves sets the team back four to eight weeks in delivery time. That's the timeline cost alone, before counting recruiting, onboarding, knowledge transfer, and months before the new hire is actually fully productive and able to work on their own. And teams that experience high turnover accumulate 37% more technical debt and spend

• 6:52Speaker 00

  22% more time debugging than stable teams, per LinearB's 2024 Engineering Productivity Report. So the rework cycle gets worse after a departure, not better, because the institutional knowledge that could have been prevented the next round of rework walked out of the door with the person who left the company. None of this is inevitable. Teams that catch requirement problems early, get feedback at a design stage instead of in a delivery stage, and they treat technical debt as a real line item in their planning, it shows dramatically lower rework rates. It makes it easier. The tooling to measure it, whether it's Git level code churn analysis, sprint tracking, structured retrospectives, these things already exist.

• 7:37Speaker 00

  The commitment to actually use those things is the harder part. Are you building out a technical debt sprint once per quarter? Are you allowing your teams to bandwidth that they need to do a little bit more research and discovery so they don't wind up in a pickle in delivery? Put it all together, and the picture is clearer than most project postmortems try to make it. Rework code takes 25% longer to write than original code. 30 to 50% of the total project effort on most teams is dedicated to rework. Developers burn out. It's heavily linked to rework. It affects nearly 75% of all developers at some point in their career. Each developer who leaves the company costs a team four to eight weeks of actual delivery time, and teams with high turnover rates accumulate 37% more technical debt, feeding

• 8:22Speaker 00

  more rework than ever before. Remember, the hours are just the start. The real cost is the compounding interest, and most of it happens silently, between the tickets, between the backlog items, in the places, in the cracks, nooks and crannies where no one's measuring. The first step to reducing this is deciding to actually track it. How much of last sprint was new work? How much was revisiting something we'd already built? Most teams don't know the answer to that question, and it's not a data problem. It's a choice about what we're paying attention to. I think that if we start paying attention to the things that matter and start paying attention to rework and recognize that hidden factory and rework are actual problems, that's going to help us to be able to better engage and better do the things that we need to do.

• 9:08Speaker 00

  All right, everybody, that's going to do it. I hope you enjoyed this episode. If you have a topic you want us to discuss, learn more at agiledad.com. We'd love to hear from you. And as always, we encourage you to stay healthy, stay well, and stay agile, my friends. Until next time, do take care. Bye now.