Using QFD to Prioritize Features in an Agile Methodology

The issue of prioritizing the pool of features to be developed under an Agile methodology is indeed a vexing one….Unfortunately, prioritization in Agile environments is typically made by “best guesses”, rather than any form of data-driven decision making….Implementing Quality Function Deployment when moving to an Agile methodology can help to alleviate many of these executive concerns while building a better, more customer-focused product….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….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.

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.

About this entry