« Use Cases for beginners | Main | Use Case Completeness Tool - a Checklist »

19/04/2011

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Welcome to All About Requirements. I hope you are visiting because you, just like me, are absolutely passionate about business process analysis, use cases, and requirements in general. Thank you for visiting.
- John