Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework. I don’t care about no technical debt. I don’t care that it’s going to make your work harder later. I only care about now. I’m short-sighted, focused on today, or this iteration, and that’s all I care about. Show me the features, baby, show me the features!”
Now, I bet that you have never heard a product owner or customer say those precise words. But you have heard words like them. If you have, you are suffering from feature-itis. And, you have some options.
- Make sure that all your estimates include the necessary architectural work required to do a good job. I don’t know why teams don’t do this as a matter of practice. (I suspect that teams do not have access to the architects they need.)
- Explain the cost of not looking at the architecture, or at least the local design as you proceed to the PO. Architecture debt is insidious, and builds quickly. Architecture debt is the most expensive debt to pay off, because the longer you go without paying the debt, the more expensive it is. Architecture debt has a high cost of change after the the decisions have been made. And the decisions have been made by many different people in many different ways because of Conway’s Law.
- Track velocity in a burnup chart. Burnups tell you how many features you have completed in a unit of time, which is the measurement you need to know. Because if you do have architectural and other technical debt, your velocity is going to start to decrease over time. It might not decrease dramatically the first iteration, but if you continue to have feature-itis, and don’t go back to address the debt in your product—especially the architectural debt—your velocity will decrease.
- You can placate the PO, swallow your pride and your professionalism, and just do what the PO asked for. Sometimes, this is the right answer.
If you have more options, please add them in your comments.
Feature-itis is a seductive disease, and is a common problem among newer POs. For the first time in their professional careers, they actually see features coming out of the technical teams. It’s a heady feeling. No wonder they fall prey to the dark side.
But with that feeling of excitement must come a feeling of responsibility. Not only is the PO responsible for the product features, the PO is responsible for the business value of the product, and knowing that the team is able to continue to extend the system. Without architecture, tests, all of the necessary engineering practices that good software requires, a technical team cannot deliver.
A question for my readers: Is automated testing debt a special form of architectural debt? The reason I’m wondering is that automated tests allow you to know if your changes break anything. They provide feedback to developers. Yes, they are helpful to testers for regression purposes, but they are most helpful to developers. So, I am wondering if the lack of automated tests are a special form of technical debt, and most specifically a form of architectural debt. I would like your opinion on that. Please chime in.
