Avoiding Technical Debt
Among the myriad of reasons why I like employing Scrum for software development, I think the main reason is the frameworks ability to remove what is often called Technical Debt (TD) or Design Debt. Ward Cunnigham was the one who coined the term and simply put, the concept is when improper code is created, the assumption is to make the code “complete” at a later date (i.e. refactoring) however these changes are shelved and never truly completed. The finance analogy would be using your high interest credit card and only paying the minimum monthly payment, consequently incurring debt rather than paying the full amount due thereby avoiding the debt.
All too often I see teams think they can overcome TD only to realize that they will never truly complete the tasks at hand along with those prior tasks that have now been entered into the current Sprint. The blame for TD could be developers (i.e. postponing testing, documentation, refactoring, code complexity, etc.) however it shouldn’t solely be on the shoulders of the developers but rather the business plays a part as well (i.e. varying requirements, lack of focus/domain expertise, etc.). Combine these and you have the perfect storm for a catastrophe but even taken singularly it’s a path towards failure.
Some may say being Agile will always sustain TD but I disagree. If you look at Scrum’s three pillars: transparency, inspection, and adaptation it’s clear that abiding by these principles will help ease or for that matter eliminate TD. How? If the Product Owner, Scrum Master and Developers are fully transparent during their Sprint meetings then when an issue arises during an inspection it can be addressed right then and there. This then leads to adaption so the adage of “Why do today what you can put off until tomorrow” need not apply. Procrastination is not a trait suited for enterprise level software development and if left unchecked can severely deteriorate the likelihood of a successful Sprint/project.
Beating the Scrum drum even harder, if used properly it’s such an elegant solution to the TD problem. As mentioned, all the members of the project team have visibility into one another so if by some reason a Sprint occurs and TD rears its ugly head, it will most certainly be shown in the Sprint Review and/or Retrospective phase. In essence, the Retrospective is the perfect opportunity to discuss TD (if applicable) as well as “what worked well and what didn’t” so that improvements can be implemented.
As is always the case, let’s play devil’s advocate and say that TD is a necessary evil when entering an emerging market because the ability to be first is paramount. Meaning: ship a v1 product at all costs (read: quick and dirty) and worry about fixing any defects, feature enhancements and other items in v2. While being first may help you garner attention and potential market share, if the application quality suffers then you’ll never have the chance to produce a v2 product and your competitor who understood the ramifications of TD will reign supreme. Not to mention if you're a consulting company who continually does not meet milestones and/or creates an inferior product, the contract with that customer may not be renewed.
All that being said, avoid TD like the plague as it will only add complications to your application in the form of missed deadlines, incorrect resource allocation and enormously high expenses to name just a few. Thankfully though with careful planning and due diligence you shouldn’t experience the TD nightmare and will be able to deliver on all of the goals set forth.