Thinking back to some of my days in management years ago, if I had a do-over, I would create a better big visible chart for our technical debt. What we had was a list of code examples to not follow, some cleanup tags in the code, the occasional debt reduction story card, and sometimes a list of debt-full areas written on the whiteboard.
What else we needed was a consolidated list of our debt on a single Big Visible Chart (BVC). We'd write each technical debt on the BVC as we either encounter it the first time or when we knowingly introduce it. Then each time we encounter it thereafter we could put a dot next to it. A dot for each day it slows us down or for each day of impact it causes.
Most teams I've seen could benefit from quantifying technical debt in this way. You've got to make the impact visible. Otherwise it can be difficult to get the understanding of, or even support from, others in the business. It easy for those who don't interact regularly with the developers and who don't have a recent development background and experience with better practices to lack trust. Not only that, quantifying debt can help a team prioritize their debt reduction efforts and keep them on top of it.
A blog about product development, product management, team and program management, lean, agile, and software development. Occasional posts about bicycling, Christianity, or racism.
No comments:
Post a Comment