Why software process innovations are not adopted

Abstract

0 7 4 0 7 4 5 9 / 0 1 / $ 1 0 . 0 0 © 2 0 0 1 I E E E W hat do these modern, buzzword software methods have in common: eXtreme Programming, Crystal, lean programming, scrum, feature-driven development, adaptive software development, “good enough” software, personal software process/team software process, Rational Unified Process, rapid development, code complete, ...? They all offer something in exchange for a change in work habits, and sometimes in exchange for a “culture” change, too. An important reason organizations do not adopt such methods—that is, do not use them in daily software development—is that what the methods offer is not as important (read “cost-effective”) as staying with the status quo. This has nothing to do with inertia or resistance to change. Put more strongly, what these methods offer is irrelevant. Put more diplomatically, what they offer is not strategic for the enterprise. All the buzzword methods offer to reduce cost or effort, duration or time to market, or defects, and most offer to reduce all of these. How can we object? Don’t we all agree that those reductions are desirable, even necessary, especially considering our profession’s sorry state? My perspective comes from two disparate directions: I have read nearly everything on adopting process innovations, and I have seen adoption succeed and fail in many software development organizations. What explains the difference between success and failure? The standard answers are about upper-management commitment and sponsorship, the ability or persuasiveness of change agents, the divisibility of the innovation, how disruptive the innovation is, and whether the change is planned and managed. All those are important, but I have seen something that is more powerful and more dominant: alignment with strategy. When the method is aligned with the organization’s strategy, the adoption is much more often successful.