Hacker News new | ask | show | jobs
by valuearb 3238 days ago
It's akin to technical debt, maybe call it Agile Feature Debt.

You implement a feature, it's done, all obvious bugs are fixed. But now that you have finished it you've gained additional knowledge from actually using it. And you realize the way it was designed or implemented isn't optimal, in fact sometimes you realize the way it works is dead wrong, and makes the product less usable.

Too late. It matches the spec. It's been checked off. Time to move on to the next imperfectly designed feature and ignore what happens when it actually works.

In my case our product was designed with a UI that was overly complex, with far too many taps and views to navigate through to accomplish a specific task. And apparently the implementors were either incompetent or totally under the gun to make tight deadlines. Because it's performance is terrible, making the long trip through all those views slow and twice as onerous.

But it matched the spec, exactly.

1 comments

A significant part of the agile process is that meeting the spec isn't the goal, being accepted by the customer is. Your description sounds like there were no sprint reviews to get customer feedback, or it was ignored. So you're arguing that a significant problem with agile is that if you skip a fundamental piece, it results in bad outcomes?
Oh, we passed all sprint reviews.

In our case the "product owner" is marketing. The lower level marketing personnel I have contact with just match the work to the spec, and can't or won't authorize any work that doesn't exactly match spec. Eventually things are bubbled up to their boss, and communicated somehow and they are handed back a list of priorities.

For example, I recently on my own time implemented a caching mechanism for the most often used views in our product, it increased their loading performance and usability by massive amounts. It was very encapsulated and easy to test, I asked to check the change in for our last sprint, and was told no, it's out of scope.

I'm not saying these are examples of problems with Agile. I'm saying these are examples of problems with Agile as it is sometimes implemented.

A few problems with the customer feedback thing:

- the person assigned to you as voice of customer does not use the product - the person doesn't have time to engage with the dev team - the person doesn't care

Over the years I have seen exactly one product owner who could give useful feedback. All the others in the end had no idea what they were after.

Hence the growth in people caring about things like UX design, user testing and releasing early to get feedback.