With Web 3.0 on its way and IT facing an ever-increasing rate of business change, agile development can serve as a change agent to create sustaining value through applications that remain relevant over time. So why is it still so hard to get buy-in from non-IT stakeholders for these types of projects? How can we better communicate agile’s value in order to overcome the obstacles precluding its effective use?
How has the game changed?
Finite thinking. Finite thinking has not served us entirely well in software development. The road is littered with failed or late applications that didn’t quite measure up. (See Fig. 1.)
Finite Frame 1: We usually frame the software development cycle in terms of one iteration—a big-bang, waterfall release—with the purpose of reaching “go live” as quickly as possible.
Finite Frame 2: The “iron triangle” of time, cost, and quality. We must give up one or two goals to achieve a third one. Everything is heavily constrained; all resources are scarce, etc.
The payoffs of an infinite approach are dramatic aside from tighter alignment and greater satisfaction from our business partners:
Over long periods of time there would be dramatic cost savings. Consider an illustration: A $1 million application needs to be replaced about three times over a two-decade span. Typically, replacement cost doubles on each replacement. Incremental cost: $6 million for a total of $8 million. There is the potential to save more than 80 percent of the $6 million incremental cost. Multiply tens of times in each of our organizations and we are talking real money. This calculus ignores maintenance costs (100 percent of development costs, as an industry rule of thumb), but one can effectively argue these would not go up dramatically, and perhaps decrease slightly with infinite thinking.
It’s important to thoroughly understand the concepts and implications of choosing to invest or not to invest in agile software development. To build your business case, James Carse once said, “There are at least two kinds of games. One could be called finite, the other, infinite. A finite game is played for the purpose of winning; an infinite game for the purpose of continuing the play.”1 Although Carse didn’t have IT in mind with these words, their wisdom applies quite aptly to software development. (See Table 1.)
|Table 1: Finite Thinking vs. Infinite Thinking|
1 James P. Carse, Finite and Infinite Games, 1986.