Jon Kern

If you have so much tech debt that you have to manage it, that's a sad state of affairs that you have inherited. I dislike seeing tasks on the dev board to clean up technical debt. That's a tough conversation to have with the stakeholders that you will not be delivering any value for this effort. The best thing to do is to fix tech debt as you naturally run into it due to implementing value-creating issues in the vicinity. And try not to get carried away. Of course, there has to be sufficient test coverage before you start slashing away at the tech debt. Also, let well enough alone. Don't go cleaning up code that is working just fine and has no need to be improved.

Dare I say that if you are doing XP with fidelity, you should not incur very much *accidental* technical debt (if any). And for sure it should not persist for any great length of time. Notice I called it "accidental" technical debt. There is *purposeful* technical debt. I once got a $100K software sale by figuring out a hack for our product (TogetherSoft ControlCenter) while on the plane ride home. The devs called me out for violating my own edicts. But by putting an issue on the top of the stack for the next release to "do it right" and remove my hack, the technical debt was paid off within weeks, and the devs were placated. Much like in financial situations, debt is only bad if it is not paid off and is compounded over time.

It's almost like you are promoting individuals and interactions over process and tools!

I like to say that one must Experience Agile to be able to truly learn what agility feels like. While reading books and taking courses can help, this is not sufficient. Follow me on how many times I use the word "work" in various incarnations. LOL. An underlying assumption is that we are gathering together to work and achieve some generally agreed upon and understood objective (e.g., a software product). As we begin to figure out how to work, we can ask ourselves if what we are doing is working. That is, are our ways of working actually working to create the work? Or do we need to adjust and try again? Yes, a bit silly. Yet not. Measuring our working against the work is kind of a built-in coach ;-)

As a young aerospace engineer, I learned about project management, Gantt and PERT charts, resource allocation, resource leveling, milestones, dependencies, finish-start, start-start, etc. It did not go well when I tried to make that work for software projects. UGH. Then I created my first lightweight methodology (before we called it agile.) You have to do real work upfront when the uncertainties are high to provide reasonably accurate estimates -- or meet deadlines. Thinking you can estimate and meet deadlines when things are still too ambiguous is a fool's errand. Instead, work first to uncover big unknowns and risks until you jointly (you and the customer) agree to an approach and timeline. And still, keep a short horizon.

I have a bit of trouble with the framing of "agile goals." It makes me wonder if I have ever done product development where I had agile goals. Maybe a better term is misalignment with "agile values or principles?" I assume this question is about product development and getting a feature request from a stakeholder. My go-to is always to recognize that such requests "come as they are." That is, sometimes users will express their request in very detailed terms -- including UI changes that they think would be a good way to implement this feature. I try to get answers to "What problem are you trying to solve?" The more you can understand the users' circumstances, the better you can craft a possible solution. (Or reject the request...)