Feature driven development failures

When developing software a popular agile approach is the feature driven development methodology. In short: create a prioritised feature list and plan development from that baselne. The approach is fine for many situations, especially for handling development cycles for a bunch of change requests or errors. However, the approach and especially the use of featurelists does have some disadvantages. First, I find it is a shame that the value of the product being developed is equal to the value of the users required features. Often users are keen on features that makes their life easier, makes the product nicer, or just pops up when asked. The outcome is that the feature lists often contain a lot of nice-to-have features such as 'the list must be divided into two horisontal panels', 'the colours must be customisable', etc. Second, nothing ensures that the features listed are supporting the desired business benefits. To address these risks for failure the desired business benefits should be outlined and the desired business process should be outlined. Finally, the featurelist must contain features ensuring the desired business benefits and these should be prioritised.

Comments

[Jesper Berg]

Hi John.
I have a hard time seeing why developing a product that suits the users needs can be described as "a failure"?

-- snip begin --
First, I find it is a shame that the value of the product being developed is equal to the value of the users required features
-- snip end --
I hope that the users of the product are the ones generating the revenue (or something else of value) for the customer who orders the produt in the first place? If not - the problem is to be found somewhere else than in the development approach.
As long as the "prioritized feature list" is being maintained by the person who is responsible for "getting the ends to meet" in regards of "what the users wants vs. what the owner of the final product wants" - eg. responsible for the business value, I can't see any other approach beating this.

[John Hansen]

Hi Jesper

Thank you for your comment.

I can definitely follow your point. First of all, I don't think the methodology in itself is a problem. In fact I think agile methods are bringing good value.

If we assume that the "prioritized feature list" is representing the features that bring most business value, the FDD approach is great, if the project team familiar with that method.

However, I think the "prioritized feature list" in some projects does not do that - mainly because the prioritized feature list is being made from just asking the end users "What would you like?" and the prioritized feature list is filled with features that the end user asked, just happens to find important.

It could be argued that the prioritized feature list should be better in FDD than in many other agile methods, because in FDD you actually have an approach where the feature list is derived from an overall model and other resources. But, it is not really a model driven methodology, it is a feature driven methodology and that can lead to disadvantages when the feature list
is not linked directly to (modelled) business value, which I sometime see. Model-based methodologies are less likely to face that disadvantage.

So, you are right that the problem is not in the development approach, but in the way is it used or interpreted.

My point in the post is to point on a disadvantage I see in feature driven development. I don't think agile methodologies are failures. In fact I think agile methods have helped bringing e.g. the use of
use case to a more agile approach.

Kind regards

John