Managing Use Case-Driven Development in "2D"
"Even if you have the right people in the right jobs, unless you synchronize their efforts, and link them to the business priorities, you do not have an edge in execution. The money making doesn't happen…"
Ram Charan, What the CEO Wants You to Know ( Charan 2001)
There is today a problem which characterizes, or maybe I should say complicates, software development. It would be convenient if this problem were technical in nature: We as software engineers are good at tackling those. But, unfortunately, it is a problem that many software engineers fear: It is a people problem. It is the problem of how to get people aligned, seeing a common vision, thinking alike, and synchronizing their efforts. Like it or not, software development is increasingly becoming a team sport (Leffingwell and Widrig 2003).
And if software development is a team sport, the game is being played on a two-dimensional field[1]:
[1] There is a third dimension in which the game is played, but which we won't address here, and that is time. Given that few systems are built "big bang" in one release, companies must learn to manage product vision, requirements, and decisions through time ("Does anyone remember why we designed it this way?!"), across staff changes and company reorganizations, mergers, and acquisitions. In a very literal sense, the team and company that released version 1.0 of a product can be completely different from the one that releases version 5.0.
Vertically, companies must be able to move product vision at the senior management/marketing level, where business priorities are being set, downward to the team level, so that the product that is released is true to the original vision and business priorities.
Horizontally, companies must be able to synchronize multiple project teams, each representing separate components or even whole products, so that they work on the same use cases, in the same order of priority, and with the same vision. In short, distributed software development.
In these chapters, we will look at the pivotal role use cases play in addressing this problem of developing software as a team sport and introduce the use of Quality Function Deployment (QFD) as a tool for prioritizing, aligning, and synchronizing use case-driven development in these two dimensions.
QFD is a product-planning tool that is used to translate business drivers into the technical requirements and design aspects of a product. QFD's roots reach back to Japan's shipbuilding and automotive manufacturing industries in the late 1960s as part of a broader interest in improved quality control by pioneers such as Yoji Akao.[2]
[2] If you are interested in reading more about the history of QFD, see Akao (1997).
The interest in QFD in the West was stimulated by reports of the achievements made by Toyota through its application between 1977 and 1984, which included a reduction in product development costs, cycle time, and rework problemsand, most importantly, the delivery of products that customers wanted. Of those taking note of Toyota's success were the big three U.S. automakers. Their interest in QFD in the 1980s as part of a larger program to improve product quality helped spread interest in the U.S.
Today, though originally developed for manufacturing industries, QFD-like ideas are being used successfully throughout the world for all sorts of applications, including software development, the services industry, and process management, and is considered an essential part of the quality improvement toolkit.
As with the other disciplines in the other parts of this book, QFD is a topic for a book on its own. In fact, based on the number of available titles, it is a topic worth hundreds of books. But while the QFD process is standardized and documented for manufacturing, there is no standard for its application in software development,[3] much less use cases specifically.[4] So while yet another book on QFD is probably not neededand as Karl Wiegers has noted, few software development organizations seem willing to undertake the full rigor of QFD, anywaysome insights into the 20% that yields 80% of the benefit in conjunction with use case driven development is very much needed.
[3] Cohen (1995) provides a good starting place for a brief overview of its application to software. Haag et al. (1996) survey several software vendors' use of QFD in their system development life cycle. Details on actual application, however, are not given.
[4] Lamia (1995) looks at a variety of possibilities for incorporating QFD into OO design, including use cases.
Chapter 1, "An Introduction to QFD: Driving Vision Vertically Through the Project," introduces you to QFD in general and focuses on the vertical dimension of software development as a team sport. In it, you
Are introduced to the basic mechanics of QFD.
Learn the difference between business drivers, user requirements, and system requirements, and the use of QFD to link and prioritize them vertically in the company.
Get a lesson from QFD on the importance of prioritized business drivers and why simply identifying business drivers isn't enough.
Learn how to analyze use cases and quality requirements (nonfunctional requirements) in terms of how they correlate with one another, positively or negatively.
Learn how to run a QFD workshop; although an individual can certainly use QFD as a tool, its biggest value is as a tool for team product planning and vision alignment.
Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization," addresses the horizontal dimension of software development as a team sport (i.e., use case-driven distributed development across multiple component or product teams).
In this chapter, you will:
See QFD applied to two software development examples from the oil and gas industry, again reinforcing the theme of QFD as a team problem solving/decision-making tool.
Work through an example of QFD used as a mechanism for aligning decision making horizontally cross-company. This example will also illustrate a QFD process that begins with use cases and works backward to identify the business drivers (not a part of "standard" manufacturing-based QFD, but something you may need to do in real-life software development).
Learn the value added by QFD to the nonfunctional requirements of a suite of fully dressed use cases.
Learn three factors that make use case-driven distributed development difficult.
Discover how to use QFD to synchronize use case-driven distributed development and how to find an optimum duration for a development iteration with an optimum set of high-priority use cases that can be implemented in that time across distributed teams.
