Agile Development Paper

8/7/2019 Agile Development Paper

1/23

MNGT 876

The Role of Agile Software

Development in BusinessStrategyDoes It Deliver Results?

Andrew Brinkman

12/8/2010


2/23

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


3/23

1 Brinkman

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 (Digman, 2008). 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

(Digman, 2008):


4/23

2 Brinkman

1.First to market: Attempt to get your product to market before the competition can deliver apotential substitute, creating a temporary monopoly

2.Second to market: A fast-follower approach, these firms enter in the growth stage of aproduct or markets 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 witha 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 demandAs 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


5/23

3 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 (Royce, 1970).

Figure 2: Original WaterfallMethod

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 itsintended users.

2.Elaboration:gather detailed requirements, conceive and document detailed use cases, deliver abasic, non-functional design.


6/23

4 Brinkman

3.Design: present a detailed software architecture including data, business logic, and userinterface 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 specificationsagreed 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 deliveredto 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

(McConnell, 1996). 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 NebraskaLincoln, an 80 to 120 page design and business case document was delivered to the client

at the end of every phase to demonstrateknowledge 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 (Royce, 1970). A large failure of this process is that it fails to fit in with

todays rapidly-moving competitive environment. A non-trivial product, such as a world processor,


7/23

5 Brinkman

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 firms 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 developments 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


8/23

6 Brinkman

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

the game(Shore & Warden, 2007). 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 (Digman, 2008). 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 firms software product will be

releasable followingeach iteration. A comparison of the timelines of agile development and traditional

waterfall development is presented in Figure 3 below (Shore & Warden, 2007).

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


9/23

7 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 (Shore & Warden, 2007). 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 (Shore & Warden,

2007).

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 thesprint 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

(Mountain Goat Software, 2010).

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


10/23

8 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 (Mountain Goat Software, 2010).

Of course, if the teams 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 thesprint 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 (Mountain Goat Software, 2010).

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

(Salo & Abrahamsson, 2008). 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.


11/23

9 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

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 (Shore & Warden, 2007). 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 (Shore & Warden, 2007). 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 teams 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

Figure 4: Example of a Story Card


12/23

10 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 (Shore & Warden, 2007).

The teams 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

improves the estimation of the total amount of time that the project will take. Velocity thus helps

management quantify the teams (and every member of the teams) 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 (Mountain Goat Software, 2010).

Retrospectives

Since agile projects have iterations lasting anywhere from a few weeks to a month, its very important to

continually evaluate the agile teams progress and process. To facilitate this, agile implements the

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

Figure 5: Sample Burndown Chart


13/23

11 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 (Shore & Warden,

2007). 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 teams 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 (Shore &

Warden, 2007).

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 (Shore & Warden, 2007).

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 incorporateson-site customer roles into the team, as well as

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

Figure 6: Example of a Retrospective. "Bad" events fall on the left

side of the continuum, while "good" events are ranked on the

right.


14/23

12 Brinkman

are responsible for determining what stakeholders in the project find valuable (Shore & Warden, 2007).

These customer roles include:

yProduct owner. The product owner has only one job: to maintain and promote the productvision (Shore & Warden, 2007). 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 (Shore &

Warden, 2007). 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 (Mountain Goat Software, 2010).

y Subject matter experts. These members (also known as SMEs) provide domain knowledge forthe project (Shore & Warden, 2007). 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.

y Interaction designers. Since the user interface of a software project is the only part of theproduct 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 (Shore &

Warden, 2007).

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 (Shore & Warden, 2007).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


15/23

13 Brinkman

product that needs attention at any given point in time (Shore & Warden, 2007). This means that each

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

arises (Mountain Goat Software, 2010). This helps each programmer improve his or her technical skills,

and 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 thecoach 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 teams vision and results to others within the

firm (Shore & Warden, 2007). This role can also be filled by aScrumMaster (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 (Mountain Goat

Software, 2010).

Criticisms ofAgile 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


16/23

14 Brinkman

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

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

(Patti, 2010).

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

risk of mismatching your technologys 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 (Patti, 2010).

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 (IT Career

Coach, 2010). 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


17/23

15 Brinkman

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 (IT Career Coach, 2010).

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 (Patti, 2010). 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 (Patti, 2010). 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 (Patti, 2010).

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 (Digman, 2008). Agile development is very

compatible with this paradigm of strategic management. By design, agile developments 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


18/23

16 Brinkman

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

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

better decisions (Digman, 2008). 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) (Digman, 2008). 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

competitors temporary strategic advantage (Digman, 2008).

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


19/23

17 Brinkman

(21%), and increased productivity and software quality (12% and 10%, respectively) (VersionOne, 2008).

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%) (VersionOne, 2008). 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 (VersionOne, 2008).

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%) (VersionOne, 2008).

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

(VersionOne, 2008).

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


20/23

18 Brinkman

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

Shore, the author ofThe 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

(Davidson, 2007).

Shore gives a real-world example of how

agile development can deliver superior

return on investment (ROI) compared to

similar projects executed using traditional

waterfall methods. Project A was

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 (Davidson, 2007). 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 firms vision in

action (Digman, 2008). 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.

Project A Project B

Total Cost $4.3 million $4.712 million

Releases 2 5

Revenue $5.6 million $7.8 million

Total investment $2.76 million $1.64 million

Payback $1.288 million $3.088 million

NPV (10%) $194,000 $1,594 million

Internal rate of return 12.8% 36.3%Table 1: Waterfall vs. iterative project costs and returns.Adapted from

Davidson, 2007.


21/23

19 Brinkman

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and

helping others do it. Through this work we have come to value:

Individuals and interactions over processes and toolsWorking 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.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair CockburnWard Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron JeffriesJon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff SutherlandDave Thomas

Agile development represents a

paradigm shift in the way

software products are produced

and deployed. Traditionally,

software firms followed a

planned, phase-focused

approach called waterfall

development. However, it

became increasingly obvious

that in todays software

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 (Shore & Warden,

2007):

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

2.Team agreement. If team members dont want to use agile methods, there will be decreasedbuy-in and an increased risk of project failure.

3.Colocated teams. Agile development heavily relies on communication, both within the team ofprogrammers and with on-site customers.


22/23

20 Brinkman

4.On-site customers. Since customers determine which features and stories provide the mostvalue, their presence is essential.

5.The right team size. As was mentioned earlier, agile teams have scaling problems once teamshave 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.


23/23

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 WildSoftware 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.

IETSoftware, 58-64.

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

VersionOne. (2008, July). 3rd AnnualSurvey: 2008 "The State of Agile Development". Retrieved

December 1, 2010, from VersionOne:

http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf

Documents

Agile Development Paper