ISSUES AND CHALLENGES OF AGILE SOFTWARE DEVELOPMENT WITH

SCRUM
Juyun Cho, Colorado State University-Pueblo, [email protected]

ABSTRACT (ASDMs) including Scrum, eXtreme Programming

(XP), Crystal, and Adaptive Software Development
Agile software development methods have been (ASD), have been developed and evolved since
developed and evolved since early 1990s. Due to the 1990s to embrace, rather than reject, high rates of
short development life cycle through an iterative and change [24]. Such new approaches focus on iterative
incremental process, the agile methods have been and incremental development, customer
used widely in business sectors where requirements collaboration, and frequent delivery [18] through a
are relatively unstable. This paper explains the light and fast development life cycle. Although many
differences between traditional software development positive benefits of agile approaches including
methods and agile software development methods, shorter development cycle, higher customer
and introduces the characteristics of one of the satisfaction, lower bug rate, and quicker adaptation to
popular agile methods, Scrum. Finally, the paper changing business requirements have been reported
illustrates issues and challenges discovered through [3], there have been few empirical field studies on
an in-depth case study in a company which has issues and challenges of ASDMs. Therefore, the aim
employed Scrum for many projects. The insights of this research paper was to discover the issues and
presented in the paper can be used in organizations challenges of one particular agile method in practice,
that are in the process of agile software development Scrum, through an in-depth case study in a mid-sized,
using Scrum. web-based development projects for government.

Keywords: Scrum methodology, traditional software The remainder of this paper discusses the differences
development, agile software development, empirical between traditional methods and agile methods, and
process. then presents a brief history, framework, and
empirical process of the Scrum methodology. Finally,
INTRODUCTION the paper discusses issues and challenges of the
Scrum methodology discovered through an in-depth
Traditional Software Development Methods case study.
(TSDMs) including waterfall and spiral models,
utilize extensive planning, codified process, rigorous TRADITIONAL SOFTWARE DEVELOPMENT
reuse, heavy documentation and big design up front METHODS (TSDMs)
[2]. Due to these characteristics, TSDMs are often
called heavyweight development methods. The One of well-known traditional software development
TSDMs are still widely used in industry because of methods is the waterfall model. The waterfall model
their straightforward, methodical, and structured utilizes a structured progression between defined
nature [6], as well as their predictability, stability, phases: planning, analysis, design, implementation,
and high assurance [3]. and maintenance. The planning phase which occupies
typically about 15% of total Systems Development
Though many TSDMs have been developed since the Life Cycle (SDLC) is the fundamental process to
waterfall model to provide significant productivity identify the scope of the new system, understand why
improvements, none of them are free from major a system should be built, and how the project team
problems including blown budgets, missed schedules, will go about building it through technical,
and flawed products [3, 4], and they have failed to economical, and organizational feasibility analysis.
provide dramatic improvements in productivity, in The analysis phase, which occupies about 15% of
reliability, and in simplicity [4]. Due to constant SDLC, analyzes the current system, its problems, and
changes in the technology and business then identifies ways to design the new system
environments, it is a challenge for TSDMs to create a through requirements gathering. The design phase
complete set of requirements up front. (35%) decides how the system will operate in terms
of hardware, software, and network infrastructure.
As a remedy for the shortcomings of TSDMs, a The implementation phase (30%) is the actual
number of Agile Software Development Methods programming. The maintenance phase (5%) focuses

VOL IX, No. 2, 2008 188 Issues in Information Systems

 Issues and Challenges of Agile Software Development with Scrum

on go-live, training, installation, support plan, percentage of projects (16.2%) that used traditional
documentation, and debugging [5]. Figure 1 and methods were completed on-time and on-budget with
table 1 below show a typical waterfall lifecycle and all features and functions specified. However, 52.7%
deliverables respectively. As we can see in the figure of the projects were completed either over-budget,
and the table, each phase must be accomplished over the time estimate and/or offering less features
before the following phase can begin and each phase and functions; 31.1% of projects were canceled at
cannot go back to the previous phase like water in the some point during the development cycle [17] (see
waterfall cannot climb up once it reaches to lower Figure 2).
position.

Planning (15%)

Analysis (15%)

Design (35%)

Implementation (30%)

Maintenance (5%) Figure 2 Project resolution (Source: The Standish

Group [17])

To overcome these shortcomings, several

Figure 1 Waterfall model lifecycle practitioners developed agile software development
methods including Scrum, eXtreme Programming
(XP), Crystal, and Adaptive Software Development
Phases Deliverables (ASD). The next section explains the characteristics
Planning Phase Planning Specifications and principles of agile software development
Analysis Phase Analysis Specifications methods.

Design Phase Design Specifications AGILE SOFTWARE DEVELOPMENT

METHODS (ASDMs)
Implementation Phase Completed Product
Table 1 Waterfall model deliverables The manifesto for agile software development which
was created by seventeen practitioners in 2001
Over the past four decades, traditional waterfall-style (http://www.agilemanifesto.org), reveals which items
software development methods have been widely are considered valuable by ASDMs. As shown in
used for large-scale projects in the software industry Table 2, ASDMs concentrate more on 1) individuals
and in the government sector due to their and interactions than processes and tools, 2) working
predictability, stability, and high assurance. As software than comprehensive documentation, 3)
mentioned earlier, however, TSDMs have a number customer collaboration than contract negotiation, and
of key shortcomings, including slow adaptation to 4) responding to change than following a plan.
constantly changing business requirements, and a
tendency to be over budget and behind schedule with More Valuable Items Less Valuable Items
fewer features and functions than specified [2, 6, 16, Individuals and Processes and tools
19, 21]. Boehm and Phillip [22], and Jones [23] both interactions
reported that during their project development Working software Comprehesive
experience, requirements often changed by 25% or documentation
more. Williams and Cockburn [24] also mentioned Customer Contract negotiation
that one of problems of TSDMs is the inability to collaboration
respond to change that often determines the success Responding to change Following a plan
or failure of a software product.
Table 2 Manifesto for agile software development
One interesting research study conducted by the
Standish Group of 365 respondents and regarding The twelve principles behind the agile manifesto also
8,380 projects representing companies across major present the characteristics of ASDMs
industry segments, shows that only a small (http://www.agilemanifesto.org/principles.html). As

VOL IX, No. 2, 2008 189 Issues in Information Systems

Issues and Challenges of Agile Software Development with Scrum

shown in Table 3, ASDMs 1) satisfy the customer There are many different characteristics between
through early and continuous delivery of software, 2) ASDMs and TSDMs. Boehm [2], for example,
embrace changing requirements, even in late reports nine agile and heavyweight discriminators
development cycle, 3) deliver working software (See Table 4). He believes the primary objective of
frequently, 4) work daily with business people, 5) ASDMs is on rapid value whereas the primary
facilitate motivated people, provide them with good objective of TSDMs is on high assurance. He also
environment and support, and trust them, 6) assist believes that ASDMs should be used for small teams
face-to-face conversation within a development team, and projects. If the size of the team and projects are
7) use working software as a primary measure of large he suggests TSDMs.
progress, 8) promote sustainable development and
keep sponsors, developers, and users moving at a
Project Agile Heavyweight
constant pace, 9) pay attention to technical excellence
Characteristics discriminator Discriminator
and good design, 10) maintain simplicity, 11)
promote self-organizing teams, and 12) foster Primary Rapid Value High
inspections and adaptations. objective Assurance
# Principles Requirements Largely Knowable
1 Our highest priority is to satisfy the customer emergent, rapid early, largely
through early and continuous delivery of change, stable
valuable software. unknown
2 Welcome changing requiremts, even late in
development. Agile processes harness change Size Smaller teams Larger teams
for the customer’s competitive advantage. and projects and projects
3 Deliver working software frequently, from a
couple of weeks to a couple of months, with a Architecture Designed for Designed for
preference to the shorter timescale. current current and
4 Business people and devlopers must work requirements foreseeable
together daily throught the project. requirements
5 Build projects around motivated individuals.
Give them the environment and support they Planning and Internalized Documented
need, and trust them to get the job done. Control plans, plans,
qualitative quantitative
6 The most efficient and effective method of
control control
conveying informaiton to and within a
development team is face-to-face conversation.
Customers Dedicated, As needed
7 Working software is the primary measure of knowledgeable, customer
progress. collaborated, interactions,
8 Agile processes promote sustainable collocated focused on
development. The sponsors, developers, and onsite contract
users should be able to maintain a constant pace customers provisions
indefinitely.
9 Continuous attention to technical excellence and Developers Agile, Plan-oriented;
good design enhances agility. knowledgeable, adequate skills
10 Simplicity—the art of maximizing the amount collocated, and access to
of work not done—is essential. collaborative external
11 The best architectures, requirements and designs knowledge
emerge from self-organizing teams.
12 At regular intervals, the team reflects on how to Refactoring Inexpensive Expensive
become more effective, then tunes and adjusts
its behavior accordingly. Risks Unknown risks, Well
Table 3 Principles behind the agile manifesto Major Impact understood
risks, Minor
The ASDMs have the potential to provide higher impact
customer satisfaction, lower bug rates, shorter Table 4 Differences between ASDMs and TSDMs
development cycles, and quicker adaptation to (Source: Boehm [2])
rapidly changing business requirements [3, 10, 12].

VOL IX, No. 2, 2008 190 Issues in Information Systems

 Issues and Challenges of Agile Software Development with Scrum

reviewers’ comments and suggestions should be

SCRUM METHODOLOGY reflected in the code (adaptation).

The Scrum software development process is an agile Framework of Scrum

process that can be used to manage and control
complex software and product development using The framework of Scrum consists of three
iterative and incremental practices [1] and is an components including roles, ceremonies, and artifacts
enhancement of iterative and incremental approach to [25]. There are three distinct roles in the Scrum
delivering objected-oriented software [13]. The process: the Product Owner, the Team and the
origin of term “Scrum” came from the popular sport ScrumMaster. The Product Owner is responsible for
Rugby, in which fifteen players on two teams getting initial and on-going funding for the project by
compete against each other. Takeuchi and Nonaka creating the project’s overall requirements, return on
[20] first used rugby strategies to describe hyper- investment (ROI) objectives, and release plan [25].
productive development processes in Japan. Three The Team is responsible for implementing the
strategies from rugby including a holistic team functionality described in the requirements. Teams
approach, constant interaction among team members, should be self-managing, self-organizing, and cross-
and unchanging core team members are adopted into functional to maximize team performance. All of the
Scrum management and control processes. team members are responsible for both the success
and the failure of sub-systems and of entire systems
The Scrum process was developed by Schwaber and [25]. The ScrumMaster (SM) is responsible for
Sutherland [15]. The former developed and ensuring that Scrum values, practices, and rules are
formalized the Scrum process for system enacted and enforced. The SM represents
development while he was at his company, Advanced management and the team to each other [15]. SM
Development methods (ADM), in the early 1990s. also tries to remove any impediments imposed on
The latter developed many of the initial thoughts and developers.
practices for Scrum when he was at Easel
Corporation as a vice president of Object Technology There are several ceremonies in the Scrum process
in 1994. By a joint effort of both Schwaber and including the Daily Scrum Meeting, the Daily Scrum
Sutherland, the Scrum process was first introduced to of Scrums Meeting, the Sprint Review Meeting and
public at the conference of Object-Oriented the Sprint Planning Meeting. The Daily Scrum
Programming, Systems, Languages and Applications Meeting (TDSM) is a 15-minute status meeting to talk
(OOPSLA) in 1996 [13]. about what has been accomplished since the last
meeting, what items will be done before the next
Empirical Process Control meeting, and what obstacles developers have.
TDSMs facilitate communications, identify and
The co-founder of the Scrum process, Schwaber remove impediments to development, highlight and
argues that the Scrum process employs an empirical promote quick decision-making, and improve
process control which has three legs underlying all of transparency (visibility) as explained in the previous
its implementations: transparency (visibility), section. The Daily Scrum of Scrums Meeting
inspection, and adaptation [14, 25]. Transparency or (TDSSM) is another short daily meeting and follows
visibility means that any aspects of the process that the same format as a regular TDSM. The main reason
affect the outcome must be visible and known to for having TDSSM is to synchronize the work
everybody involved in the process. Inspection between multiple Scrum teams. The Sprint Planning
requires that various aspects of the process be Meeting (TSPM) is a monthly meeting, where the
inspected frequently enough so that unacceptable Product Owner and Team get together to discuss
variances in the process can be detected. Adaptation what will be done for the next Sprint which lasts
requires that the inspector should adjust the process if usually for 30 days. In TSPM, team members break a
one or more aspects of the process are in an project into a set of small and manageable tasks so
unacceptable range. that all the tasks can be completed in one Sprint. The
Sprint Review Meeting (TSRM) is another monthly
A code review can be analyzed with the empirical meeting which is held at the end of the Sprint. TSRM
process control described above. Any code written by is usually a four-hour time-boxed meeting, where
developers should be visible to everybody team members present what was developed during
(transparency). The most experienced and the Sprint to the Product Owner and stakeholders.
knowledgeable developers can review the code
(inspection). If there is a room to improve the code,

VOL IX, No. 2, 2008 191 Issues in Information Systems

Issues and Challenges of Agile Software Development with Scrum

In addition to the Scrum roles and ceremonies, the interviews were audio-taped, transcribed, and later
Scrum process provides three artifacts namely the coded. In the process of data analysis, grounded
Product Backlog, the Sprint Backlog, and the theory [7, 8] was used to derive constructs from the
Burndown Chart. The Product Backlog is a collection immediate raw data. Some of repeated issues and
of functional and non-functional requirements, which challenges are coded below.
are prioritized in order of importance to the business.
The items in the Product Backlog are created and
maintained by the Product Owner. The Sprint
Backlog is created by team members from the
Product Backlog in a way that the high priority items
in the Product Backlog are first selected and broken
into a set of smaller tasks. When the Product Backlog
items are divided into small tasks, team members
estimate the completion time for each task. Team
members try to make tasks as small as possible so
that every task can be accomplished within three
days. The Sprint Backlog consists of these small
tasks. The Burndown Chart is a graphical
presentation where work remaining is tracked on the
vertical axis and the time periods tracked on the
horizontal axis. The Burndown Chart should be
accessible by every member who participates in the
project.

Flow of Scrum

The Scrum process begins with a vision of the system

and a simple plan on ROI and release milestones. The
vision is described in business terms rather than Figure 3 Flow of Scrum (Source: Hodgetts [9])
technical terms. The vision may be unclear at first but
will become more precise as the project moves Documentation
forward. As mentioned earlier, the Product Owner is
responsible for getting initial funding, delivering the The Scrum method, like other agile software
vision while maximizing ROI, and creating the development methods, significantly reduces amount
Product Backlog. The prioritized items in the Product of documentation [13, 14, 15]. In fact, the agile
Backlog are divided into smaller tasks through the methods claim that the code itself should be a
Sprint Planning Meeting and placed in the Sprint document. That is why developers who are
Backlog. In the Sprint Planning Meeting, the Product accustomed to agile methods place more comments
Owner explains the content, purpose, meaning, and in the code. Several developers mentioned they
intentions of each item in the Product Backlog. Team placed more explanations for any tricky piece of code
members can ask questions if they do not understand and for any changes that they made. However, many
any items in the Product Backlog. All the tasks in the developers agree that without having any documents,
Sprint Backlog are done through the iteration of the it is very difficult to complete tasks for those
Sprint which consists of the Daily Scrum Meetings. developers who are working on parts of the system
Figure 3 illustrates the flow of the Scrum process. they never worked on before and also for new
developers who do not have much experience with
ISSUES AND CHALLENGES OF SCRUM the project. For both cases, developers who do not
understand the project ask a lot of questions, which
Several issues and challenges were discovered takes time away from developers who do understand
through an in-depth case study in a company that has the project. One developer mentioned that “When I
employed Scrum for many small- and medium-size first got here, of course, I was overwhelmed. It would
web-based projects. Data were collected through a have been nice to have some documents that explain
formal face-to-face interview with nine employees in why certain things were done in a particular way and
the company including a vice president of operations, what they were.” One more developer mentioned that
a director of operations, a project manager, a “Agile methods do not use specification documents. I
ScrumMaster, and five software engineers. All of the think that might be a weakness in agile methods. The

VOL IX, No. 2, 2008 192 Issues in Information Systems

 Issues and Challenges of Agile Software Development with Scrum

agile methods allow you to go much quicker as long

as whoever is specifying has a very good idea of Customer involvement in the software development
what clients want. If this is not the case, the agile process is very critical to the success of the project.
methods are just as slow as anything else because you The agile methods state that the customer should be
are going to have to get clarification.” part of the development process from analysis and
design to implementation and maintenance. However,
Another developer also raised the issue of the lack of the case study reveals that developers have
documentation. He stated “Right now, we have one difficulties working with customers on the projects.
guy who is the main guy. He knows all of the A project manager mentioned that “Customers are
systems and I think, personally, that might be a not involved in the decision making process until it is
mistake. Not because he is not good at it, but because all done.” He also stated that “We don’t get as much
it just makes one gigantic point of failure if he is hit customer involvement as we want. Our customers are
by a bus or if he leaves for another company.” It busy and they have other things to do than to talk to
would take several months for the company to programmers all day.” One developer complained
recover the knowledge that one main developer has. that “We request our customers to talk to us every
The idea behind reducing documents in the agile day and at least minimum once a week but they are
methods is to keep every team members equal by not very involved so we end up with talking with
sharing skills and knowledge on the systems. In that maybe twice per Sprint.” Another developer stated
way, if one person leaves, there is still a lot of shared that “Our customers did not give us specification
knowledge that has gone around among other team documents. We basically had an hour-long meeting
members, so it is not a big deal. However, in reality, to make a specification. So, it was vague when we
this is not feasible. started it. It was up to us to make specifics and
estimations. I think the biggest roadblock in our
Communication development process was in the customer
involvement. Though we did not have enough
It is well known that ineffective communication is customer involvement, our customers accepted most
the root of most failures in software products [11]. part of the system that we created and asked us for
The Scrum process recognizes the important role of minor changes. But I think it would be much better if
communications in the software development process we get together more often with our customers.”
and provides an excellent means of communication.
All interviewees agree that the Daily Scrum Meetings It seems that, most of the time, customers do not
improve communications between team members know what they really want in their future system and
within a team. However, each team in the company is it becomes a roadblock for customers to get involved
fairly separate and generally there is not much in the project development process. One developer
communication between teams. The lack of stated that “Customers think they have a clear idea
communication between teams could cause problems but they do not. For example, the customer wants to
such as duplicated work. This problem can be solved track people’s credit. To them, that’s clear and
or at least mitigated if the company holds the Daily precise. But to us, we need to know who the people
Scrum of Scrums Meeting because SMs from each are, what the credits are, when they expire, how long
Scrum team can make sure no work is being we track them, what rewards earned for many
duplicated. credits.” Due to unclear customer requirements,
developers have a hard time figuring out what exactly
Good within-team and between-team communication the customer wants to include in their system. One
can be accomplished through the framework of ScrumMaster mentioned “We need to get out a lot of
Scrum, but communication with the customer can be information from unclear statement, which takes
problematic. Several developers mentioned that “the more time, which causes us to get involved less
biggest area of communication issues that we have is because it takes too much time. But we don’t have
with the customer more than anything else because any other way to do it because we don’t have
they tend to not give us a lot of feedback.” Part of the information.”
reason that the customer does not provide feedback is
that, in most cases, they have other daily jobs to take Working Environment
care of in addition to the work with developers. This
is related to the customer involvement issue which is Most agile methods including Scrum recommend
explained in the next section. removing the cubicles and setting up collocated team
space because cubicles promote isolation and the
Customer Involvement Scrum process relies heavily on high-bandwidth,

VOL IX, No. 2, 2008 193 Issues in Information Systems

Issues and Challenges of Agile Software Development with Scrum

face-to-face communication, and network [25]. The because we can talk to each other and everybody
open space is considered better than the cubicles and knows what everybody else is working on.
private offices in the Scrum process. Many
developers like the idea of open-space-working However, some developers talked about inefficient
environment. One developer mentioned “I feel like I Sprint Planning and Review Meetings. One developer
am little closer to other developers in open space. It’s argued that “Some of our Sprint Meetings are so
really nice to be able to look across the room and talk simple and it seems to be a waste of time spending a
to somebody else in the team and ask questions whole day just for planning and review. I think it
quickly. I don’t feel like I am shouting over the needs to be adjusted based on the complexity of the
cubicle wall to get to them.” Another developer project that we are working on.” Another developer
stated that “Open space is good because everyone is mentioned that “Our daily standup Scrum meetings
easily accessible. I like it because I think it fosters sometimes go on a little longer just because
communication. It’s very easy to say hey, I need everybody is talking about what they did last night. I
some help, information, or come, look at this. think there probably are some good advices on trying
Everyone is just kind of opening, and it seems to to keep your daily standup meetings consistent and
work very well.” short so that people are not distracted and they can go
back to work quickly as most people would rather
Though some developers enjoy the open-space- work productively than waste a time.” Another issue
working environment, other developers do not like is related to setting up the meeting time. Due to the
the open space and they mentioned downsides and flexible work schedule among developers, it is
some problems. One developer stated that “the open difficult to get together all at one time. One developer
areas are very nice to communication but it does hurt stated that “I think the hard things for us in Scrum is
when you try to concentrate because there are a lot of when to do it because some of us get in at 7:30 am
distractions. For example, when co-workers are and some of us at 9:30 am. So as a team, we just have
having a conversation with somebody or having a Scrum as soon as everyone gets in. That’s usually at
phone conversation, it’s very distracting.” Another ten or eleven. The problem is that those who get in
developer mentioned that “I am less productive early are interrupted from their work because they’ve
because a lot of noises are going all around. Without been working for two or three hours very well. They
having cubicle walls or private offices, the are in the group or zone so being interrupted and it’s
distractions are pretty high which is hard to work frustrating. We talked about doing it at the end of the
with.” A team lead stated that “You know the best day but that also has a problem because some people
working environment is an office. In your private come in at 6:30 am and leave at 3:30 pm, and some
office, you can do things your way, and focus on people come in at 9:30 am and leave at 6:30 pm. It
things without being distracted by other noises.” makes hard for our team to get together all at one
time.”
To cancel out the noises, most developers use
headphones. The director of operations stated that CONCLUSIONS
“Everybody has headphones and they can just put
those on and listen to something. That pretty much Agile software development methods were developed
drowns everything else out. However, several to provide more customer satisfaction, to shorten the
developers complain that “We, developers, are development life cycle, to reduce the bug rates, and
usually working while listening to music. We all have to accommodate changing business requirements
a nice headphones workout. Everything is going during the development process. This paper presents
under that. But if I need to focus on something, that’s characteristics of traditional software development
really difficult just because I have headphones on.” methods and agile software development methods,
and the differences between them. This paper also
Scrum Ceremonies introduces the roles, ceremonies, and artifacts of
Scrum, which is one of the most well-known agile
Scrum ceremonies including the Daily Scrum software development methods in the industry. This
Meeting, the Sprint Planning Meeting, and the Sprint paper also presents five issues and challenges
Review Meeting, seemed to help software engineers including documentation, communication, user
develop high-quality systems. Most developers involvement, working environment, and Scrum
testified that the Scrum ceremonies have been very ceremonies, discovered through an in-depth case
useful and very productive. Several developers study in a software company that makes small- and
mentioned that “the 15-minute standup Daily Scrum mid-size web-based applications. If the five issues
meeting has allowed us to be on the same page and challenges are addressed and resolved before the

VOL IX, No. 2, 2008 194 Issues in Information Systems

 Issues and Challenges of Agile Software Development with Scrum

project is launched, organizations will have fewer 14. Schwaber, K. (2007). What is Scrum? Retrieved
difficulties in producing high-quality software March 5, 2008, from
products using Scrum. http://www.scrumalliance.org/system/resource/fi
le/275/whatIsScrum.pdf.
---------------------------------------------------------------- 15. Schwaber, K., & Beedle, M. (2002). Agile
The author wants to thank Dr. Sherry Marx at Utah software development with Scrum, Upper Saddle
State University for her insightful advice on a River, NJ: Prentice Hall.
qualitative research method.
16. Schach, S. R. (2004). An introduction to object-
oriented systems analysis and design with UML
REFERENCES and the unified process. Boston: McGraw-Hill.
17. Standish Group (1994). The chaos report.
1. Advanced Development Methods, Inc. (2007). Retrieved March 6, 2008, from
Scrum, Retrieved March 19, 2008, from http://www.standishgroup.com/sample_research/
http://www.chaos.com. chaos_1994_1.php.
2. Boehm, B. (2002, January). Get ready for agile 18. Stazinger, J. W., Jackson, R. B., & Burd, S. D.
methods with care. IEEE Computer, 35(1), 64- (2005). Object-oriented analysis & design with
69. unified process. Boston: Thomson Course-
3. Boehm, B. & Turner, R. (2003, June) Using risk Technology.
to balance agile and plan-driven methods. IEEE 19. Summerville, I. (2004). Software Engineering.
Computer, 36(6), 57-66. Boston: Addison-Wesley.
4. Brooks, F. P. (1995). The mythical man-month. 20. Takeuchi, H., & Nonaka, I. (1986, January-
Reading, MA: Addison-Wesley. February). The new new product development
5. Dennis, A., Wixom, B. H., & Tegarden, D. game. Harvard Business Review, p137-146.
(2005). Systems analysis and design with UML 21. Watson, R. T., Kelly, G., Galliers, D., &
version 2.0. Hoboken, NJ: Wiley. Brancheau, C. (1997). Key issues in information
6. Fruhling, A. & Vreede, G. (2006). Field systems management: An international
experiences with extreme programming: perspective. Journal of Management Information
Developing an emergency response system. Systems, 13(4), 91-115.
Journal of Management Information Systems, 22. Boehm, B. & Papaccio, P. (1988).
22(4), 39-68. Understanding and controlling software costs.
7. Gall, D. M., Gall, P. J., & Borg, R. W. (2003). IEEE Transactions on Software Engineering,
Educational research: An introduction. Boston, 14(10), 1462-1477.
MA: Allyn and Bacon. 23. Jones, C. (1997). Applied software
8. Glesne, C. (2006). Becoming qualitative measurements: Assuring productivity and
researchers: An introduction. Boston, MA: quality. McGraw Hill.
Allyn and Bacon. 24. Williams, L. & Cockburn, A. (2003, June). Agile
9. Hodgetts, P. (2005). Product development with software development: It’s about feedback and
Scrum. Retrieved March 1, 2008, from change. IEEE Computer, 36(6), 39-43.
http://www.agilelogic.com. 25. Schwaber, K. (2004). Agile project management
10. Miller, K., & Larson, D. (2005, winter). Agile with Scrum. Redmond, WA: Microsoft Press.
software development: Human values and
culture. Technology and Society Magazine,
IEEE, 24(4), 36-42.
11. Parnas, D. (2006). Agile methods and GSD: The
wrong solution to an old but real problem.
Communication of the ACM, 49(10), 29.
12. Parrish, A., Smith, R., Hale, D., & Hale, J.
(2004). A field study of developer pairs:
Productivity impacts and implications. IEEE
Software, 21(5), 76-79.
13. Schwaber, K. (1996). SCRUM development
process. Proceedings of ACM SIGPLAN on
Objected-Oriented Programming, Systems,
Languages, & Applications (OOPSLA ’96), San
Jose, California.

VOL IX, No. 2, 2008 195 Issues in Information Systems