Technical Debt for PMs
Technical debt describes the cumulative consequences of cutting corners in software development, but it escapes the attention of many project managers as they focus on scope and schedule. That’s a mistake because it impacts both. Here are questions to help you ascertain the real state of technical affairs.
As a software project manager or product owner, the term ”technical debt” may not ring a bell. Over the last several years managing Agile teams, I’ve come to realize that lurking technical debt introduces risk and represents unplanned work that impacts schedules and ultimately the long-term health of projects. I believe that project managers and product owners should make technical debt a priority and factor a “re-payment” program into project schedules as a regular part of planning.
Technical debt is a term coined by Ward Cunningham to describe the cumulative consequences of corners being cut throughout a software project’s design and development. The basic idea is that a development team, over time, cuts corners due to lack of skill, laziness or pressure, which then manifests itself as a large backlog of technical inefficiencies that needs “paying off” in the future. Technical debt encompasses issues related to the code base, development environment, platform and libraries, architecture and design, and test
Please log in or sign up below to read the rest of the article.