Striking a Balance Between Product and Technical Debt in an Agile Environment
Agile and Scrum are fantastic tools at a development teams disposable to move quickly on a project. However, it is easy to get pulled into ideas like “MVP” and other scrum priorities such as releasing to production at the end of every sprint. In theory these are great concepts, but it’s easy for a development team to make short term decisions that result in technical debt. How many times have we all said, “I’ll fix it later,” and then later never comes?
How do we ensure that we are delivering a valuable, expedient product and addressing technical debt? A couple experiences come to mind.
In scenario one, we will address a “mature” software - one that is already deployed to market and is meeting market demand. As each new feature is developed, teams can find it harder and harder to build the right solution while limiting technical debt. One major reason for this challenge is often that there is a lack of testing in place. The team may find it faster to cut and paste functions resulting in multiple, nearly identical, lines of code that need to be changed to enable the new feature. This type of fragile software becomes more difficult with each release and frequently causes problems that either result in pushing the release so the problem can get fixed, or the problem goes to production impacting the user experience.
Scenario two involves new software. This is where “MVP” comes into play, and the development team is creating a v1.0 solution. If you are in a position of leadership, it is important that you give the team time to design properly. However, we all know that external pressure can compress design time. How can the team create a product quickly, get it to market, find time to learn from their decisions, and fix the ones that are going to cause limitations in the future?
A technique that I have used in the past that everyone can understand is something resembling a “feature tax.” The idea is that if the business or product owner wants feature X, then they also need to allow time for technical work (for example, debt time or research into new tools/solutions).15%-50% is a good estimate depending on the product, how much debt time has already been incurred, and what the tolerance is from the business and product leadership. Older systems tend to benefit more from an initially higher “tax” until they are modernized.
The concept of “reputation” is also important in the process, as every C level executive is concerned about their own influence and esteem, and these types of decisions make a difference in customer loyalty. As an example, if the sales team is hampered by a site on which they present demonstrations that goes down daily, or even once a week, time is taken away from sales activities. This both impacts internal credibility and the influence you have with customers. Additionally, trust may be lost by customers which can open the door to consideration of competitive solutions.
It is critical to mind the balance between product and technology. Falling behind in either can mean that you are unable to react quickly when market forces change, and this could open your software up to usability and security vulnerabilities, among other risks. Additionally, it’s easy to focus on software that our own teams write, while ignoring third party libraries. It’s just as important to stay current with external dependencies to avoid additional security concerns. There are also potential hindrances to IT being able to upgrade backend services or operating systems because the software leverages outdated components. The worst case scenario a development team can face is when their product or service is shared and multiple other solutions are impacted, forcing those teams to have to spend resources protecting against older, unreliable software.