Delivering new requested features is satisfying and provides clear value. But even when it comes to features, there is such a thing as too much of a good thing. In a post at her website, scrum master Natalie Warnert discusses the cost of working when no one is keeping an eye on quality.
The scenario Warnert poses is simple—a team can deliver loads of new features quickly to make the business happy, but they are going to incur a ton of technical debt in doing it. This technical debt clogs the arteries of the product to such an extent that adding any further features becomes a delicate, life-threatening surgery. Thus, short-term gains are found immediately with customers who receive a bevy of new features, but the long-term gains are more ambiguous, as the future will be marred by technical restrictions.
Such ominous situations should not be allowed to develop. In response, Warnert offers this:
What we need to do is assess up front what the cost of delay is for not writing the code correctly the first time OR for doing another net new feature over paying down the debt we’re rapidly incurring.
Is the value (urgency, risk reduction, opportunity enablement, revenue generation or cost reduction) in doing this net new feature more or less than doing this technical debt[?] Sure, we should be doing this in our prioritization of backlogs in one way or another. BUT are we also asking that if we need to do this other thing later, how does that value (above criteria) compare with doing it then?
Sometimes you just have to do whatcha gotta do if the business really needs something, but the important thing regardless is to be mindful of the costs of delay and other opportunity costs involved in task prioritization. Likewise, addressing technical debt must be a non-optional part of the backlog. And as Warnert warns in conclusion, “It will always cost more to fix later.” You can view her post here: http://nataliewarnert.com/cost-of-delay-and-opportunity-cost-when-you-dont-build-quality-in/