MNGT 876

The Role of Agile Software

Development in Business
Strategy
Does It Deliver Results?
Andrew Brinkman
Table of Contents
Introduction.................................................................................................................................................1
Waterfall Development...............................................................................................................................3
Agile Development......................................................................................................................................5
Agile Iterations........................................................................................................................................6
Agile Strategic Practices...........................................................................................................................8
Stories..................................................................................................................................................9
Timeboxing..........................................................................................................................................9
Velocity and Burndown Charts............................................................................................................9
Retrospectives...................................................................................................................................10
Agile Team Organization........................................................................................................................11
Criticisms of Agile Development............................................................................................................13
Agile Development and Strategic Trends..................................................................................................15
Agile Development Business Results.........................................................................................................16
Conclusion.................................................................................................................................................18
Works Cited...............................................................................................................................................21
Introduction
As any business student goes through his or her course of study, he or she becomes well-versed in the

product life cycle. The name “product” life cycle is something of a misnomer; the life cycle itself can

apply to products, markets, and even entire industries[ CITATION Les08 \l 1033 ]. This life cycle follows a

very specific path, starting with product introduction and growth. The growth period is then followed by

a shakeout stage, where the rate of growth declines and the weaker competitors are cleared from the

market. Finally, a product, market or industry will enter the maturity stage, which is then followed by a

decline. A visual representation of the product life cycle is presented below as Figure 1.

Figure 1: The Product Life Cycle

A firm whose products are highly technical or innovative in nature knows the strategic implications of

this familiar diagram, and the importance of properly positioning itself both within its industry and on a

product-by-product basis to maximize market share, revenues, and profits. A firm engaged in

Schumpeterian (innovative) competition of this manner can engage in four broad functional strategies

[ CITATION Les08 \l 1033 ]:

1 Brinkman
 1. First to market: Attempt to get your product to market before the competition can deliver a

potential substitute, creating a temporary monopoly

2. Second to market: A “fast-follower” approach, these firms enter in the growth stage of a

product or market’s development and attempt to learn from the innovations, successes, and

mistakes of a competitor

3. Cost minimization: Firms following this strategy enter the market later in the growth stage with

a goal of lowered development/R&D costs through economies of scale, joint product lines, and

process efficiencies

4. Market segmentation: Use basic technology to serve niches or pockets of demand

As a technology firm decides which of these strategies (or which mix of strategies) to follow, it must

consider the rapidly-changing nature of the competitive environment. Software in particular is unique in

that it can be released before it is a “finished product.” A core product can be developed and released

to customers relatively quickly, and new features and functionality can, in many cases, be added later

(for an additional charge, in some cases). Transportation costs and the marginal cost of production are

both zero in many cases. Therefore, in such cases it makes sense to not only deliver a product rapidly,

but to be able to continue to iteratively improve that product. In this case, a firm is not only able to

capture more monopoly profits in the introductory and early growth stages of the life cycle, but will be

able to continuously deploy features to help keep their product in the growth stage longer. Agile

software development was conceived to help accomplish this goal.

In this paper, I will present an overview of agile software development and how it relates to business

and functional strategy. I will first examine the way software has been traditionally developed, using a

process called “waterfall” development. As a contrast, I will then discuss agile development, focusing on

its organizational principles and strategic practices, making sure to examine criticisms of the process as

2 Brinkman
well as its strengths. Finally, I will attempt to show that following the functional strategy of agile

development can deliver superior performance and financial gains, and return on investment for a

technology firm.

Waterfall Development
The waterfall method of software development was first described by Dr. Winston W. Royce in 1970. It

is a sequential process that begins with requirements gathering, which is then followed by design of the

product, and (after many more phases) finishes with installation and maintenance. The phases, as Dr.

Royce presented them originally, appear below in Figure 2[CITATION Roy70 \l 1033 ].

Figure 2: Original Waterfall Method

Contemporary students typically learn the waterfall process in five phases. These phases are:

1. Initiation: come to a basic understanding of the goals of the product, its functions, and its

intended users.

2. Elaboration: gather detailed requirements, conceive and document detailed use cases, deliver a

basic, non-functional design.

3 Brinkman
 3. Design: present a detailed software architecture including data, business logic, and user

interface layers, performance metrics, non-functional requirements such as speed and look/feel,

and test cases.

4. Construction: developers work to code the software product according to the specifications

agreed upon in the initial three phases. Software testing should also begin in this phase.

5. Transition: development on the product is completed. The product is then tested and delivered

to the customer.

There are supporting arguments for this approach. R&D costs cannot be recovered until a product

reaches the market. Since this is the case, many advocate that the design of a software product be as

complete and “correct” as possible before the actual construction (coding) of that product begins. For

example, a software “bug” or design flaw that is discovered in the initial design phases, as opposed to

the construction or transition phases, is significantly cheaper to correct in money, effort, and

time[ CITATION Ste96 \l 1033 ]. Additionally, a major emphasis is put on documentation. For example,

when I was an undergraduate student in the Raikes School of Computer Science and Management at the

University of Nebraska—Lincoln, an 80 to 120 page design and business case document was delivered to

the client at the end of every phase to demonstrate knowledge and understanding of business strategy

and technical requirements. This documentation is especially useful for “non-technical” members of the

client team; it enables such personnel to ensure their understanding of the product and that their

strategy and goals are being communicated effectively to the development team.

However, the criticisms of waterfall development far outweigh most supporting arguments. I would be

remiss if I did not point out that the “father” of waterfall, Dr. Royce, describes the process as illustrated

as “risky and invites failure” [CITATION Roy70 \l 1033 ]. A large failure of this process is that it fails to fit

in with today’s rapidly-moving competitive environment. A non-trivial product, such as a world

4 Brinkman
processor, could take years to completely develop from the start of the process to the end of the

process. However, if a firm has completed the “design” phase and is in the midst of construction, and a

competitor releases a product that replicates key functionality of that firm’s product, then the firm has

little real flexibility to respond. Each phase is “set in stone,” so to speak, before the development

project moves on to the next step. In some cases, the firm may have no choice but to either start the

project over from scratch, or to abandon the product altogether.

In addition to the problem of lack of competitive responsiveness, an additional difficulty with the

waterfall method is the fact that it can take a significant amount of time to deliver a software product to

market. As we saw in the introduction to this paper, two of the four functional technology strategies are

related to getting your software to market either first or early in the growth stage of the product life

cycle. If you have only one “release” of your product, you run the risk of trying to compete in an

oversaturated market, having high buyer switching costs, or of missing the “growth” stage altogether.

In response to these difficulties and problems with the traditional waterfall approach to software

development, many developers, managers, and strategists began to search for a different, better way to

deliver software products to the market in a timelier, more iterative fashion. The result of this effort is

known as agile software development.

Agile Development
Agile development’s goal is to deliver a software product that helps provide success for the organization,

not just for that particular project or product. This is accomplished by including business experts and

focusing development efforts and the core value that the product provides for your firm. The most

valuable and marketable features of the product are released first, and new versions are released

frequently. When the competitive environment changes, an agile development team can adjust its

strategy to match that change. In many cases, this can enable your organization to seek out

5 Brinkman
opportunities for disruptive (to your competitors) environmental changes, thus changing “the rules of

the game” [CITATION Jam07 \l 1033 ]. The creators of agile development were cognizant of the fact that

strategy is about “agility and responsiveness to customer needs, not merely long-term plans based on

competencies” [ CITATION Les08 \l 1033 ]. Thus, agile development can be seen as the embodiment of

some of the latest best practices and trends in strategic management.

Agile Iterations
The key to agile as a source of competitive advantage in the software industry is its iterative approach to

software development. An iteration is also known as a sprint; these two terms will be used

interchangeably throughout this paper. As you will recall, the waterfall method resulted in a single

release of a software product after a long, multi-phased development process. In contrast, agile

development performs every software development activity (business analysis, design, coding, testing,

and deployment) simultaneously. Ideally, a new version of the firm’s software product will be releasable

following each iteration. A comparison of the timelines of agile development and traditional waterfall

development is presented in Figure 3 below [CITATION Jam07 \l 1033 ].

Figure 3: Agile development iterations (top) vs. Waterfall lifecycle

6 Brinkman
As can be seen from these diagrams, a firm that uses agile development as a part of its functional

strategy has the opportunity to release a new version of its product each and every week. This enables

firms to focus their development efforts on features that provide the most value to the customer first,

and to provide marginal improvements on features and functionality as time goes on.

Most agile coaches recommend having iterations that last between one week and one month; in many

cases, two weeks becomes the norm. Inside this iteration, a full design-code-test-release cycle is

completed by the project team[CITATION Jam07 \l 1033 ]. Short iterations allow for the on-site

customers (see the “Agile Team Organization” section for a description of this role) to adjust the

strategic focus and direction of the project more frequently than on more traditional projects. This

flexibility decreases response time to new competitive intelligence, and allows the team to reprioritize

which new features will provide the most value on at least a semi-weekly basis. Iteration planning is

kept fairly short, and tends to be proportional to the total length of the iteration[CITATION Jam07 \l

1033 ].

There are several activities besides the basic coding of product features that must occur each sprint.

These activities are crucial, as they keep the team organized and focused on its goals over the course of

each individual iteration. The first activity each iteration is the sprint planning meeting. The purpose of

this meeting is for the product owner (whose role is described in the Agile Team Organization section of

this paper) and the team to determine which features are of the highest priority for that iteration. The

team estimates how many stories they can commit to, and then form the iteration backlog, which is a

collection of all features that must be implemented and tasks that must be performed during the

sprint[ CITATION Mou10 \l 1033 ].

On every day of the iteration, a daily standup meeting is attended by all team members. This includes

the coach and/or ScrumMaster (whose roles are defined Agile Team Organization section) and the

7 Brinkman
product owner, if possible. This meeting should take no more than ten minutes. The purpose of the

daily standup is for team members to share what they worked on the previous day, what they plan on

working on today, and to identify any impediments or blockers to their progress. The meeting serves to

synchronize the work of the team on a daily basis, and helps to ensure that the team is on schedule for

each sprint [ CITATION Mou10 \l 1033 ].

Of course, if the team’s goal is to release software at the end of each iteration, it must be able to

demonstrate that it has successfully delivered the high-value functionality identified by the team and

the product owner in the sprint planning meeting. This is accomplished in the sprint review meeting.

During this meeting, the team demonstrates additional value-added functionality that was developed

during the latest sprint. The team then receives feedback from the product owner and other internal

customers or stakeholders that have been invited to the meeting. This helps the team make desired

changes to new functionality. The feedback may also result in the revision or addition of items to the

product backlog, which is the central list of all functionality to be delivered over the entire course of

product development[ CITATION Mou10 \l 1033 ].

Agile Strategic Practices

There are two agile methodologies in wide use today. The first, Scrum, aims at “providing an agile

approach for managing software projects, while increasing the probability of successful development.”

The second, eXtreme Programming (XP) focuses on project-level activities of implementing

software[ CITATION Sal08 \l 1033 ]. This paper examines an integrated agile approach; that is, both

Scrum and XP together. At first, agile development may seem like scheduled chaos to most business

strategists. How can any successfully project deliver a product when planning, execution, and release

activities are happening simultaneously? There are several strategic practices in agile development in

addition to the meetings described above that help mitigate this potential for chaos. These practices

help make multiple semi-weekly product releases possible.

8 Brinkman
Stories
To deliver a product, each agile team must decide what

features will be included in that product. These features

are collected, written down, and become known as

stories. Typically, agile teams keep track of stories to be

completed for the current iteration on notecards taped

Figure 4: Example of a Story Card
to a whiteboard. Figure 4, to the left, shows an example

of a story card. Stories are not meant to be fully-fleshed-out requirements documents; they are mainly

used for task-tracking and scheduling purposes[CITATION Jam07 \l 1033 ]. Because of this, each story

should be “small” enough to complete in one or two days’ worth of work. Stories are customer-centric,

to keep the team focused on providing value to the customers. Typically, they are written in the form,

“As a [role], I would like [function or feature] so I can [benefit].

Timeboxing
Agile teams also practice timeboxing. This means that a certain amount of time is set aside for a

particular activity, whether it is research, individual coding tasks, or meeting agenda items. Once the

time limit has been reached for a certain activity, that activity is stopped immediately, regardless of

progress[CITATION Jam07 \l 1033 ]. This may seem counterintuitive, but timeboxing can helps prevent

“thrashing” when a team member has made as much progress as possible toward a certain task. It can

also aid in decision-making in meetings by preventing wasted discussion and debate. Timeboxing,

therefore, helps agile teams maintain focus on providing overall product value to the customer and

prevents “tunnel vision” toward an individual task or issue.

Velocity and Burndown Charts

How does a team know how many stories it can complete in an iteration? Perhaps more importantly,

how is the team’s progress, both during an iteration and over the course of the project overall,

communicated effectively to other stakeholders such as upper management? Agile teams accomplish

9 Brinkman
this by measuring their velocity. Velocity can be measured in a variety of ways, but a common method

is to assign each story to be completed in an iteration a number of “story points,” depending on

estimated technical complexity and general effort required. Agile teams generally try not to estimate

based on time requirements; as was mentioned previously, stories should be sized so that they can be

completed in a day or two of productive work. Story points can be scaled by consecutive integers

(1,2,3,4…), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…), or even by t-shirt sizes (S, M, L, XL, XXL) by

more whimsical teams[ CITATION Jam07 \l 1033 ].

The team’s velocity is measured in

terms of story points completed

after every iteration. This also

helps the team improve their

estimations of how much work can

realistically be accomplished

during each sprint, which in turn

Figure 5: Sample Burndown Chart
improves the estimation of the

total amount of time that the project will take. Velocity thus helps management quantify the team’s

(and every member of the team’s) productivity. Velocity is typically demonstrated by the generation of a

burndown chart. A burndown chart should be generated for each iteration and/or release. These

charts can be used to demonstrate the amount of work remaining in a sprint or release to project

stakeholders[ CITATION Mou10 \l 1033 ].

Retrospectives
Since agile projects have iterations lasting anywhere from a few weeks to a month, it’s very important to

continually evaluate the agile team’s progress and process. To facilitate this, agile implements the

concept of a retrospective. There are a myriad of different methods of conducting retrospectives.

10 Brinkman
 However, most generally follow a similar pattern.

Team members write down themes and events

of the iteration that fall into several categories.

For example, teams could group events by

categories such as: Enjoyable, Frustrating,

Puzzling, Same, More, and Less[CITATION

Jam07 \l 1033 ]. Another approach is to rank

events along a spectrum from Very Bad to Very

Good, as shown above in Figure 6. After the events of the iteration are mapped out, two or three

categories or items are selected by the team as action items on which to focus improvement efforts.

The selected action items become the team’s retrospective objectives. It is very important to assign

specific team members responsibility to ensure that action is taken on the retrospective objectives to

ensure that they do not “fall through the cracks” [CITATION Jam07 \l 1033 ].

Agile Team Organization

One of the most important principles of agile development is that of the self-organizing team. This

means that, while everyone has a certain role on the team, each team member plans his or her own

work. Of course, coordination is important across team members in certain cases, but that coordination

is kept as informal as possible. Agile teams are strongly encouraged to sit together in an open

workspace to facilitate open communication and collaboration[CITATION Jam07 \l 1033 ].

As I mentioned, there are several roles that must be filled on each agile team. An important strategic

advantage of agile development is that it incorporates on-site customer roles into the team, as well as

programmer roles. On-site customer roles help define the software that the programmers build, and

are responsible for determining what stakeholders in the project find valuable [CITATION Jam07 \l

1033 ]. These customer roles include:

11 Brinkman
  Product owner. The product owner has only one job: to maintain and promote the product

vision[CITATION Jam07 \l 1033 ]. This job can involve documenting the vision, sharing it with

stakeholders, incorporating feedback, and setting priorities. This person must have a deep

understanding of the market in which the product will compete, and must also be able to make

difficult trade-off decisions about features included (and excluded) in the project[CITATION

Jam07 \l 1033 ]. The product owner is also responsible for ensuring that the product backlog

(complete list of desired product features) stays prioritized as more information is gathered

about the competitive environment and customer needs[ CITATION Mou10 \l 1033 ].

 Subject matter experts. These members (also known as SMEs) provide domain knowledge for

the project[CITATION Jam07 \l 1033 ]. For example, if a firm was making a new product to make

opening checking accounts easier, the SME would provide knowledge about exactly what

information is required by banks to open that account.

 Interaction designers. Since the user interface of a software project is the only part of the

product with which most customers will interact, these people focus on making sure potential

users find the software usable and intuitive through use of prototypes and mockups[CITATION

Jam07 \l 1033 ].

Of course, a firm cannot create a software product without technically-savvy developers. Agile requires

that all developers contribute to the code of which the product is composed, and thus labels them

programmers[CITATION Jam07 \l 1033 ]. Each programmer is responsible for design, coding, and testing

some portion of the code. While the team may include experts in functional areas such as database

design, security, or user interface design, each programmer is expected to work on any part of the

product that needs attention at any given point in time[CITATION Jam07 \l 1033 ]. This means that each

team member is expected to work outside of his or her preferred disciplines or strengths if the need so

arises[ CITATION Mou10 \l 1033 ]. This helps each programmer improve his or her technical skills, and

12 Brinkman
reduces potential dependencies and impediments should a team member with significant amounts of

domain-specific knowledge suddenly become unavailable.

Even though agile teams are self-organizing, they still need leaders to guide the team in agile practices,

and to function as a liaison to the rest of the organization. This role is usually filled by the coach or

project manager. In most cases, the coach also functions as a technical resource to the team (meaning

he provides working code to the product), while the project manager can teach agile practices to non-

technical members of the team as well as advocate the team’s vision and results to others within the

firm[CITATION Jam07 \l 1033 ]. This role can also be filled by a ScrumMaster (if the team is following

Scrum practices). The ScrumMaster is different from a traditional product manager in the sense that the

person in that role is not responsible for day-to-day task delegation and direction to the team. The

primary responsibilities of the ScrumMaster are “sheltering the team from outside distractions, allowing

team members to focus maniacally during the sprint on the goal they have settled”[ CITATION Mou10 \l

1033 ].

Criticisms of Agile Development

Like many paradigm shifts before it, agile development has been subject to its share of criticism as a

process for delivering working software on time and within budget. When planning this paper, I had a

chance to talk with Dr. Tom Seevers, Vice President and Chief Technology Officer for IBM's Global

Financial Services Sector, regarding his views on agile development. While discussing the potential

limitations of agile development, he brought up an interesting point regarding the integration of

technology architecture with business architecture. Dr. Seevers’ view is that the informal planning

process that is inherent in agile development can potentially limit the scope of what can be

accomplished. If not enough time is spent at the beginning of the project considering architectural

decisions (product structure, integration strategies, specific technologies used, etc.), there is a good

13 Brinkman
chance that much of the work that was done at the beginning of the project may have to be

redone[ CITATION Don10 \l 1033 ].

Dr. Seevers is also concerned that without enough formalized planning and documentation, you run the

risk of mismatching your technology’s architecture with your business structure and architecture. This is

especially applicable for agile software projects that involve the delivery of software for internal and

infrastructural use. Agile development may not be as adept as needed to identify key integration points

early, since these points of integration may not be identified as high-value features by the internal

customers. Again, if these integration points are not identified or misidentified, the team runs the risk

of having significant amounts of rework to do[ CITATION Don10 \l 1033 ].

Another criticism of agile development is that, if managed improperly, it can lead to a practice known as

“cowboy coding.” Cowboy coding can be defined as “coding without first planning or thinking”

[CITATION Cow10 \l 1033 ]. Many developers and managers who are accustomed to more formal, less

iterative processes such as waterfall become concerned that the informality of planning associated with

agile development could lead to an absence of planning. Indeed, this is a danger. One of the keys of

agile development is adherence to its various processes and organizational principles. If the coach or

project manager allows the team to lose sight of the processes and methodologies it has agreed to lose,

he runs the risk of allowing the team to lose sight of the customers’ goals for the project, and thus the

value of the entire project itself. In this situation, you may end up with a finished product, but it may

not have the functionality desired by your customers. Other problems that can arise in this scenario are

underestimations of complexity or time required for a particular task/story, avoiding working with

internal customers such as domain experts, “hitting walls” or getting stuck when the project runs into a

difficult technical problem, lack of testing, and poor software quality[ CITATION Cow10 \l 1033 ].

14 Brinkman
Finally, critics note that agile development is best suited for smaller teams (typically three to eight

people), and in some cases coordination throughout the team can be difficult if the team grows much

larger than that. This can be complicated in such cases by the agile principle of the self-organizing team.

Once an agile team grows beyond eight to ten members, a greater degree of organization and

coordination may be required[ CITATION Don10 \l 1033 ]. It is also crucially important for these teams

to be collocated in the same physical location, which may not be possible in larger or more traditional

organizations[ CITATION Don10 \l 1033 ]. The team must also be in continuous interaction with internal

customers, especially if a project is extremely dependent on domain-specific knowledge. Again, in some

environments, this level of communication may not be possible. This could occur if customers travel

frequently or if a customer is a top executive or fills another role with significant non-project-related

time demands[ CITATION Don10 \l 1033 ].

Agile Development and Strategic Trends

One of the most important aspects of strategic management is the concept of continuous strategic

thinking. Companies are beginning to deemphasize highly formalized and structured planning processes

in favor of more flexible, qualitative, and informal processes[ CITATION Les08 \l 1033 ]. Agile

development is very compatible with this paradigm of strategic management. By design, agile

development’s management structure is informal and flexible, and feedback loops are kept short to

enable frequent retrospectives and strategy adjustment.

Another strategic practice that is currently en vogue, especially for information-based and information-

dependent firms, is increased speed and better timing. Agile development helps firms deliver software

products faster and more frequently than traditional waterfall methods, and allows for frequent

readjustment of strategy regarding what features are required and how those features are

implemented. The agile practice of timeboxing helps ensure that decisions are made with as little

15 Brinkman
needless debate as possible, which is important since “firms which make decisions faster tend to make

better decisions” [ CITATION Les08 \l 1033 ]. This agile approach is especially useful in high-velocity,

complicated situations where customer needs and the competitive environment may be changing

rapidly.

Agile development is also an example of one of many changes that are taking place in industry and

organizations, and particularly in the software development industry. Agile is an example of a structure

that promotes less hierarchy (self-organizing teams), newer processes (retrospectives, timeboxing,

velocity, etc.) and better responsiveness to customers (including customers in the team, releasing

software after each iteration) [ CITATION Les08 \l 1033 ]. The move away from a traditional, plan-based

process like waterfall and toward an informal, flexible process like agile is indicative of the overall trend

toward temporary competitive advantage, instead of sustainable competitive advantage. Agile

development supports the rapid moves and countermoves to help “change the rules of the game” and

destroy a competitor’s temporary strategic advantage[ CITATION Les08 \l 1033 ].

Agile Development Business Results

If any technology firm is considering implementing agile development as their development process,

management will want to know if this strategic approach delivers business results. Fortunately, a

number of studies have been conducted that attempt to measure the efficacy of agile development in

general and specific agile practices in particular. One such study was performed in 2008 by VersionOne,

which is a company that produces an agile management platform.

The survey attempted to capture the reasons for adopting agile development within teams, and specific

organizational concerns with its adoption. The most common reasons for a move to agile development

were accelerated time-to-market (22% of respondents), enhanced ability to manage changing priorities

(21%), and increased productivity and software quality (12% and 10%, respectively)[ CITATION Ver08 \l

16 Brinkman
1033 ]. These reasons for adopting agile development closely align with its strategic benefits that have

been presented throughout this paper. Organizational concerns regarding the adoption of agile

development included lack of up-front planning (46%), loss of management control (37%), lack of

documentation (36%), and inability to scale (22%)[ CITATION Ver08 \l 1033 ]. Again, these concerns

match the most common criticisms of the agile development process.

Next, the survey attempted to quantify the returns of agile development, as measured by the

percentage of successful agile projects (from an organizational perspective). 55% of survey respondents

stated that between 90% and 100% of projects using agile methods were considered successful. An

additional 21.2% stated that between 75% and 90% of agile projects were successes[ CITATION Ver08 \l

1033 ]. Common causes of failed projects included clashes with company philosophy or culture (23%),

lack of experience with agile methods (21%), and external pressure to follow traditional waterfall phases

and practices (11%)[ CITATION Ver08 \l 1033 ].

The survey also asked respondents to estimate specific improvements that were realized from the

implementation of agile development practices. 56% of respondents reported that agile development

increased productivity by at least 25%. 56% of respondents also stated that time-to-market was

accelerated by at least 25%. 55% of respondents said that the number of software defects (bugs) was

reduced by at least 25%. Finally, 30% of respondents reported at least 25% in cost savings. Agile

practices were also shown to deliver significant improvement in project visibility, productivity, software

quality, ability to manage changing priorities, and alignment between IT and business

strategy[ CITATION Ver08 \l 1033 ].

In addition to the mainly qualitative improvements that the VersionOne survey discovered, many firms

will want to know if there are quantitative improvements associated with the adoption of agile

development. That is, how can agile development directly contribute to a firm’s bottom line? James

17 Brinkman
 Shore, the author of The Art of Agile Development, has stated that agility can have a direct positive

contribution to bottom line profits, and will increase the value of a software project to its

stakeholders[ CITATION Mic071 \l 1033 ].

Shore gives a real-world example of how

Project A Project B
Total Cost $4.3 million $4.712 million
agile development can deliver superior
Releases 2 5
Revenue $5.6 million $7.8 million return on investment (ROI) compared to
Total investment $2.76 million $1.64 million
Payback $1.288 million $3.088 million similar projects executed using traditional
NPV (10%) $194,000 $1,594 million
Internal rate of return 12.8% 36.3% waterfall methods. Project A was
Table 1: Waterfall vs. iterative project costs and returns. Adapted
from Davidson, 2007. developed using more traditional waterfall

development processes, and Project B was

implemented using an iterative, agile approach. According to Shore, the only difference between the

projects was the way they were planned[ CITATION Mic071 \l 1033 ]. The two projects are compared in

Table 1 above. As you can see, the agile project had more releases, generated significantly more

revenue with lower total investment, and had a much higher payback, net present value, and internal

rate of return. Of course, this is only one example, but numerous other studies show that agile

development, when practiced according to its methodologies and with support from management and

other key stakeholders, can deliver superior business results.

Conclusion
The Agile Manifesto, which can be found on the next page, laid out the goals of agile development. As

can be seen, its signatories had a vision when they created the agile processes and methodologies that

have been discussed in this paper. As we know, a strategy can be thought of as a firm’s “vision in

action”[ CITATION Les08 \l 1033 ]. Firms practicing agile development are inherently utilizing a business

strategy that has its roots in many of the latest best practices and trends in strategic management.

18 Brinkman
Agile development represents a
Manifesto for Agile Software Development
paradigm shift in the way
We are uncovering better ways of developing software by doing it and
software products are produced helping others do it. Through this work we have come to value:

and deployed. Traditionally,
software firms followed a
planned, phase-focused
approach called waterfall
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

development. However, it Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
became increasingly obvious Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
that in today’s software Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
industry, where the competitive

environment and product requirements may be rapidly changing, an inflexible approach like waterfall

was no longer appropriate. Agile development was envisioned as a strategic response to the rise of the

information age for firms wishing to deliver superior business results to their stakeholders.

Of course, a firm must have the right institutional mindset to incorporate agile development as a

business strategy. A firm must meet six prerequisites in order to use this strategy[ CITATION Jam07 \l

1033 ]:

1. Management support. Agile development is impossible to implement if management is

resistant to its implementation.

2. Team agreement. If team members don’t want to use agile methods, there will be decreased

“buy-in” and an increased risk of project failure.

3. Colocated teams. Agile development heavily relies on communication, both within the team of

programmers and with on-site customers.

19 Brinkman
 4. On-site customers. Since customers determine which features and stories provide the most

value, their presence is essential.

5. The right team size. As was mentioned earlier, agile teams have scaling problems once teams

have greater than eight members.

6. Use all of the agile practices. Agile is designed to incorporate as little overhead as possible;

ignoring a practice could remove value from the end product.

Software firms, or even firms attempting to develop infrastructural software for internal use, must

decide if the strategy of agile development and the vision behind that strategy meshes with its vision,

mission, and culture. Firms that are extensively hierarchical and slow to respond to change may have

difficulty implementing agile development, and may be best served by keeping their existing methods of

software development. But for firms that are informal and exist in a highly competitive technological,

competitive, or industry environment, this is not the case. Agile development represents a means for

firms to introduce disruptive technologies and to create temporary market monopolies and temporary

competitive advantage. When implemented properly, agile development has been proven to deliver

superior qualitative and quantitative business results.

20 Brinkman
Works Cited
Davidson, M. (2007, December 12). Agile development can increase project ROI. Retrieved December 5,
2010, from Software Quality News:
http://searchsoftwarequality.techtarget.com/news/1285731/Agile-development-can-increase-
project-ROI

Digman, L. (2008). Strategic Managment: Competing in the Global Information Age. Mason: Cengage
Learning.

IT Career Coach. (2010, February 26). Cowboy Coder Or Agile Programmer? Retrieved December 2, 2010,
from IT Career Coach: http://www.it-career-coach.net/2010/02/26/cowboy-coder-or-agile-
programmer/

Lee, G., & Xia, W. (2010). Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data
on Software Development Agility. MIS Quarterly, 87-114.

McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Redmond: Microsoft Press.

Mountain Goat Software. (2010). Introduction to Scrum - An Agile Process. Retrieved December 3, 2010,
from Mountain Goat Software: http://www.mountaingoatsoftware.com/topics/scrum

Patti, D. (2010, March 16). Before You Make the Leap to Agile - Ten Weaknesses of Agile. Retrieved
December 4, 2010, from Cedar Point Consulting:
http://www.cedarpointconsulting.com/deliver/articles/before-making-the-leap-to-agile

Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings, IEEE
WESCON, 1-9.

Salo, O., & Abrahamsson, P. (2008). Agile methods in European embedded software development
organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum.
IET Software, 58-64.

Shore, J., & Warden, S. (2007). The Art of Agile Development. Sebastopol: O'Reilly.

VersionOne. (2008, July). 3rd Annual Survey: 2008 "The State of Agile Development". Retrieved
December 1, 2010, from VersionOne:
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf