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.


