Hard Truths About Building Software: For Product Owners & Developers
By: Grant Gadomski
Tags: Product Owner, Scrum, Agile, Product Ownership, Software Quality

For Product Owners

Building software is expensive, time-consuming, and unpredictable. Therefore as a product owner, it’s natural to look for ways to cut costs. So why would you let the development team waste time on “technical debt”, “refactoring”, and other bogus-sounding words that don’t deliver the functionality your users crave? To an untrained Product Owner’s ears, those words sound like money burning in a furnace. But the time spent up-front on these quality-related activities will save you a substantial amount of money in the future.

Good Software Costs Money. Bad Software Costs More Money.

According to the Consortium for IT Software Quality: “The cost of poor quality software in the US in 2018 is approximately $2.84 trillion…” (pg 5). Furthermore, “For a particular system, software maintenance costs will typically form 75–80% of the Total Cost of Ownership (TCO)”(pg. 11).

In short, projects don’t die at release, and the shortcuts taken during development multiply your spending for years to come.

What’s worse, the costs of poor software are often hidden. According to the Iceberg Model of Poor Software Quality (pg. 10), not only do substandard development practices cause bugs, crashes, and defects, but they also cause substantial rework, maintenance, and security costs in the future.

The Cost of Poor Software Quality in the US: A 2018 Report — Consortium for IT Software Quality

Beyond the costs of development (initial & maintenance), consider the human costs of bad software. Good developers don’t like writing bad code, and they hate having to fix bad code. After years of fixing sloppy messes (or being forced to create them), many good developers will look for the door. Not only are developers expensive to replace, but the remaining talent need either the patience of saints, a lack of knowledge around best practices, or to not care about the software they create.

Sprints Do Not Mean Sprinting

I don’t like the name “Sprints”. Picture someone sprinting. Arms pumping, lungs gasping, face flushed, desperately trying to reach a short-term goal. Now picture someone “sprinting”to finish a feature. Late nights, copious amounts of coffee, bags of Fritos strewn about, and a complete disregard for friends, family, hobbies, and physical health. Is this how anyone wants to spend a 30+ year career?

The 8th Agile Principle states:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Sustainability isn’t just nice to have, it may actually improve the productivity of the company’s IT department, like so:

Less Turnover — As mentioned above, replacing developers is expensive, and the good ones are often the first to go, since they know their market value. Occasional late nights happen anywhere. But when a developer is forced to burn the midnight oil every time a sprint ends, they get frustrated, get angry, and look for a way out. Though some developers are happy to work 14-hour days, most aren’t. The stereotype of a basement-dwelling hacker doesn’t reflect most professional developers, who balance a love for their job with families, chores, and hobbies. Fewer Surprises — Although your team says they finished 5 features last sprint, and you approved each one, did they really finish those features? In a pressure-cooker environment of hard deadlines and harder requirements, shortcuts may be taken to “get something out the door”. Beyond good ol’ technical debt, these shortcuts can have surprising consequences. Bugs that only occur on leap years, APIs that enrage any team integrating with your product, and documentation shortcomings that leave any new developer floating directionless in a sea of code are all products of a rushed environment. When a team can go slow and deliver fewer features better, habits of quality become ingrained, and velocity will gradually increase again (as the team gradually improves). As a product owner, you’ll sleep easier knowing that this new velocity won’t cost you future migraines.

Projections are Just Projections

Let’s say I hold out one of those hand-held puzzles and ask you “How long will it take to solve this?”. You’ve solved a few of these kinds of puzzles before, and consider yourself a pretty good puzzle-solver, but you’ve never seen this exact one. So you give it a quick look-over, come up with an initial plan-of-attack, and say: “About 2 minutes”. I hand it over, the timer starts, and you get to work. 20 seconds in you feel like you’re going nowhere. The darn thing looks more tangled than when you started. You look closer, and see all these unexpected twists, turns, and knots. After some experimentation, you start making progress, but it’s slow-going. Two minutes passes, and the puzzle is nowhere near solved. I shout: “What the heck happened? You told me it would take you 2 minutes! You must not’ve tried hard enough…”. This is what development feels like (and it’s outcome) when Scope, Time, and Cost are all fixed, a.k.a. when long-term projections are taken as facts.

Forgoing concrete promises and firm Gantt charts is hard for Product Owners & check writers. When you’re footing the bill for software, it’s comforting to have someone look you in the eye and say “We will deliver this functionality on this date for this much”. But would you rather live with some instability & flexibility now, than discover the truth about project progress & cost months later?

Scrum helps teams move faster, but that’s not it’s main purpose. Instead, Scrum helps teams deliver the most amount of value possible. As opposed to the traditional project triangle where functionality is fixed, and money/time fluctuate, Scrum enforces strict timelines (sprints), and allows teams to customize what they deliver based on what provides the most perceived value.

Instead of bean-counting subjective & gut-based story points, I urge check-writers to consider a simple cost-value balance when assessing a project’s progress. Instead of matching reality to (often wrong) projections, ask yourself “Does the value of what’s been delivered outweigh the cost?”. Scrum promises working functionality every sprint, and the team will do everything in their power to provide that. Therefore a project’s progress can be represented by actual demos and releases to end-users. If you feel like the value provided by the project outweighs the cost and time-commitment of this project, then the project should continue. Emphasize continuous improvement both on a team & organizational level, pull levers to facilitate when needed, and trust the people you hired to deliver their best work.

For Developers

Pragmatism vs. Purism

Good developers see programming both as a craft and an artform. Clean, concise, well-written code is beautiful, and should be respected as such. But almost no developers are hired to write pretty code. Instead they’re hired to produce working software. A balance must exist between form and function.

Please note that I’m not endorsing pure hacking, or carelessly slinging code to send features out the door. 95% of developers would benefit their company long-term by slowing down and improving their code base’s quality.

But this purification must be balanced against innovation & business interests. The internet is an excellent example of a pragmatic system. Sure it’s messy, has rough edges, and it’s current design would make any self-respecting architect faint, but it’s become the most important innovation of the 20th century, and possibly of all time.

Cool & Complex Does Not Equal Valuable

No matter how badly you want to build a true AI-driven system with a sleek front-end design and fascinating backend challenges, if the user will gain more value from a simple static page, then you’re gonna have to build that simple page.

The Product Owner has ultimate jurisdiction over backlog prioritization. Sometimes the most interesting feature to develop is prioritized last. The development team can argue for said feature’s value, but final say rests with the Product Owner.

You Gotta Stand Your Ground

No matter how cordial the relationship is between Product Owner and Development Team, there will always be some push-and-pull between them.

The Owner is either reporting to someone who’s writing big checks, or writing the big checks themselves, and want more “bang for their buck”. Therefore they always want the team to promise more functionality.

But to quote the Scrum Guide: “ The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”

The Development Team must use a combination of past velocity, previous experience, and gut feelings to project what they’ll accomplish in the next sprint. What they say is final. The Product Owner must be respectful of the Development Team’s commitment, and the Development Team must have the courage to stand by their honest predictions. Letting the Product Owner decide or affect commitments leads to failed sprint goals, resentful developers, and unhappy checkwriters.

Rip the Band-Aid Off

Scrum is both loved & hated for it’s brutal honesty. For every ounce of value delivered and insight provided, there’s a pound of uncomfortable truths that all involved parties have to face. For a Scrum project to succeed, Product Owners must understand that quick & cheep will cost them dearly, and software development is a profoundly unpredictable venture. Conversely, Development Teams must understand that they’re paid to deliver value, and that they must be both vocal and honest in their projected capabilities, no matter how much the business balks at their estimates.