QFD Online

…moving into the House of Quality

A Spoonful of QFD Helps the Agile Go Down

November 21st, 2007 by John Livingston

Imagine for a moment that you are the president of a successful software development company. Your company is doing reasonably well from a sales perspective, but you have been dealing with some sizable challenges in terms of your development team hitting their scheduled release dates on time. (The past 2 releases have been late by more than six months a piece.) Then one day your development manager comes into your office droning on about the success of something called “Agile” development methodologies. He goes on to tell you that he knows how to eliminate the slippages that he and his team have experienced in relation to your two year development plan: simply do away with the two year development plan. Needless to say, the conversation would probably not go well. However, there is a sweetener that can assist executive management in swallowing the sometimes bitter pill of “Agile” development—and that sweetener bears the name “QFD“.

Swallowing the Bitter Pill

Despite the documented performance improvements that companies have experienced by adopting Agile methodologies, many corporate executives and stake holders have been slow to approve such a change due to their consternation about certain key principles in Agile development. One of the most challenging precepts for executives is the fact that under Agile methodologies (such as Scrum, XP, or Feature Driven Development) there are no two or five year development plans. Indeed, Agile methodologies gained their name from the idea of being able to quickly respond to ever-changing customer requirements. This means that Agile teams only plan out their development a few weeks or months in advance so that they can change course easily when needed.

This principle of iterative development helps Agile teams to respond to the voice of the customer before that voice starts singing a different tune. The proponents of these methodologies have had tremendous success in remaining on the leading edge of competitive functionality. However, many corporate executives, product managers, and other stake holders frequently fear that development will proceed without direction under Agile development and that critical features and functionality will be omitted due to lack of proper planning.

The issue of prioritizing the pool of features to be developed under an Agile methodology is indeed a vexing one. In truth, many Agile teams do wander aimlessly due to the sudden disappearance of a long range plan. These teams typically do a fantastic job of delivering working software every two weeks that has numerous new features. The new features are typically coded well and are very stable and maintainable. Unfortunately, these teams also find that in their rush to begin solving their customers problems correctly, they have ceased to solve the correct problems. The results are stable applications with long laundry lists of features, but that aren’t competitive in the market because they lack the right features.

This entry was posted on Wednesday, November 21st, 2007 at 6:30 pm and is filed under Voice of the Customer, Agile, Quality Function Deployment, QFD, Software. You can follow any responses to this entry through the RSS 2.0 feed. You can also leave a response.

2 responses about “A Spoonful of QFD Helps the Agile Go Down”

  1. Carl said:

    Hmmm, you’ve set up a paper adversary then thrashed it. Saying that agile teams respond to squeaky wheels, engineers preferences, and on and on is a paper adversary - where are you getting this stuff!? Do you have a study, or a collection of articles that serve as anecdotal evidence of this claim. Your claim also ignores the Agile tenant that a customer rep, or product manager, owns the prioritization process, not development.

  2. David said:

    I agree with Carl, this article is very ironic in that it asserts there is a lack of data used in agile projects but it makes this assertion without any data… This article is based on ignorance.

Leave a Reply