QFD Online

…moving into the House of Quality

A Spoonful of QFD Helps the Agile Go Down

November 21st, 2007 by John Livingston

Additionally, the use of successive “Houses of Quality” (HOQs) can help executives to manage the direction of an Agile development team from a high level vantage point, without having to devote endless hours to reviewing individual features. These executives are able to concentrate on a preliminary House of Quality that weights business/customer requirements and rates the importance of certain modules, software attributes, and/or feature sets against those business requirements. These HOQs are generally fairly small and only contain 10 to 20 business requirements and 30 to 50 feature sets. Thus, they are easily reviewed and maintained by an executive team. However, the resultant weighting of these feature sets is then able to drive the prioritization of hundreds of features on succeeding Houses of Quality.

Lastly, the use of Quality Function Deployment helps to eliminate the waste of constantly reevaluating features in the feature pool in order to determine their relative priority as new feature requests are added and as business priorities change. Although the weightings and ratings on the preliminary Houses of Quality for a software development project change frequently, the HOQ that rates actual features against feature sets is far less dynamic. This last House of Quality will change due to the addition of new feature requests and the removal of completed features, but the ratings on existing entries rarely change (if ever) and the importance weightings for the feature sets are all pre-determined by upstream HOQs. Thus, features need not be reviewed again and again in order to determine their relative priority. The can instead be rated just once, and then forgotten about until they bubble up in priority based on the changes made in “higher level” HOQs.

How Sweet It Is

Indeed, Quality Function Deployment can help to quell many of the fears executives face when discussing a move to an Agile development methodology. It helps them to know that there is a plan in place for development, and that their development teams are not going to aimlessly add features to their applications as they see fit. (In actuality, a QFD is a type of long-range plan that outlines development for months or even years to come. It simply has extremely low over-head associated with modifying that plan on a frequent basis.) Additionally, it helps these stake holders to manage their feature pools from a high-level vantage point, without devoting endless hours to reviewing and re-reviewing individual features.

The benefits of moving to an Agile development methodology combined with QFD prioritization go far beyond just pacifying fears and replacing old high-level management tools, however. The leaders who are brave enough to try such a change will soon discover that their products are more and more in tune with the voice of their customers. These executives will find that they have the ability to release software that meets their customers’ wants and needs while their customers still want and need it. Rather than pleading and/or arguing with development managers to slip critical features into a development plan after that plan has begun to be executed, these stake holders will find development teams who are anxious for feedback and course correction. In truth, the combination of Agile and QFD may be the best medicine an executive has ever taken for dealing with his or her software development headaches.

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