Technical debt like money debt can insidiously accumulate. For many Product Owners, technical debt is tasteless, odorless, and colorless. Yet, if allowed to grow unchecked, it will gradually eat away at quality, maintainability, and future product scalability.
Technical debt is often a consequence of poor design decisions. Poor design decisions often occur in moments of “expediency”, just “get it working”. You might hear things like “it’s a hack” or a band aid, but it will get us by for now. What that means is, it’s functioning as a one-off piece of code outside of architecture standards. Which further means it will cost more effort to keep track and maintain one offs. This is a prime example of technical debt.
Another source of technical debt comes from incomplete testing. Product Owners constantly juggle constraints; budget, schedule, and scope. Sometimes, reducing scope at the last moment means testing is skipped on specific features and shutting those features off in code to make production deadlines. This is another prime source of technical debt.
Delaying remedial actions on technical debt carries long term consequences. It will become harder to refactor the band-aid code the longer it is left in place and used. That’s real debt, because you’re borrowing time from the product’s future to maintenance the debt which will have to be repaid with interest.
Like any other debt, there ought to be a clear understanding of why technical debt is incurred, and how and when to pay it back. Some instances of technical debt might be considered by the Product Owner for possible inclusion on the Product Backlog, if doing so allows that debt to be better managed in terms of product value. This provides the true picture of how much more must be invested before a product reaches a certain level of maturity.
Make sure you’re getting good technical debt transparency from your team. The team should be tracking it; ranked in terms of high cost to less cost. Collaborate which should be added to the backlog and what portion of sprint backlog should consist of technical debt stories. Paying back debt little by little is sound risk management.
Want to know more?
CRi is the partner many clients nationwide know and trust to help plan and execute successful agile transformations. Are you in the middle of an agile transition and could use some help? Are you considering an agile transition and need a place to start? We’d love to hear from you. Email us at gig@clientresourcesinc.com or click the green talk bubble in the bottom right of your screen and fill out the form. To learn more about commonly used agile terms and concepts, view our agile glossary.
Tom is the Practice Director for Agile Consulting Services at Client Resources Inc in Omaha, NE. He specializes in lean, agile, and scrum helping companies catapult their market position by building extremely high performance development organizations.