Agile Zone is brought to you in partnership with:

Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at Johanna is a DZone MVB and is not an employee of DZone and has posted 128 posts at DZone. You can read more from them at their website. View Full User Profile

Do You Have Feature-itis?

  • submit to reddit

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.

  1. 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.)
  2. 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.
  3. 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.
  4. 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.

Published at DZone with permission of Johanna Rothman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Lisa Crispin replied on Wed, 2011/06/22 - 3:59pm

I never thought of classifying technical debt in that way, but automated tests are potentially a major component. If you don't have a quick enough feedback loop to know you broke something, you're going to slow down. Lack of tests is technical debt. Having automated tests that are difficult to maintain is also technical debt. This is why programmers have to be actively involved in automating tests at all levels, not only unit tests. A good programmer can automate a test (with a maintainable design) much faster than a tester whose primary job is NOT writing code. With programmers doing the automation, testers' time is free to collaborate with customers to get requirements and examples to turn into automated tests that guide development, and to do the all-important manual exploratory testing. When we have programmers and testers collaborate on writing and automating the regression tests, we can slash our technical debt.

I like your suggestions for pushing back on the PO. My team has found that we must make the cost of everything visible. If we quietly do quick hacks or manual database updates for the business, they don't understand there was still a cost with that. We use big visible charts as you suggest, and we explain the long-term cost of implementing a feature without spending enough time to design it well and support it with adequate tests.  Over the years, we've been able to educate the PO and other stakeholders. And sometimes, as you say, there is a compelling business reason to hack in the quick fix - but we have to come back and pay that debt later.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.