Challenges of Traditional and Agile Software Processes

Jacqueline Marı́n Sánchez

Abstract— Software processes have evolved significantly since defenders, is ruled by 12 principles explained in the “Agile
software engineers started to follow a disciplined flow of Manifesto” [8]. In this environment individuals and interac-
activities to gain quality and productivity in development. tions are valued over processes and tools, working software
Several process models, methodologies, methods and/or soft-
ware development practices have been proposed, adopted or over comprehensive documentation, customer collaboration
rejected that differ at the ceremony level. For many years, there over contract negotiation and responding to change over
have been conflicts over whether to follow a totally traditional following a plan.
approach (“classical”) or to become more agile. Each approach Agile methods and practices aim to simplify the software
has its strengths and weaknesses, and each has followers and
process by avoiding “bureaucracy” and advocate short time
critics. However, the ongoing diversity of software projects and
the advancement of technology has led to debates about what cycles, close involvement of the client and an adaptive rather
kinds of software process approaches are more context-effective. than predictive strategy [9]. Many researches defend that
This paper surveys existing traditional and agile processes and agile methods provide a better way to address people’s needs,
discusses their challenges. accelerate software development and improve quality and
customer satisfaction. These and other reasons make the
I. INTRODUCTION
industry to advocate for the agile philosophy. However, agile
The question of how software development should be methods can fail when they are applied in the wrong con-
organized has been debated by the software engineering com- text [10] and are also rarely used in their “pure” form [11].
munity for decades. Improving the ways in which software The history of software development shows that the choice
products are developed is a challenge that must be addressed of a process is not a simple deterministic exercise, but
carefully [1] due to the complexity of the software [2]. depends on the situational characteristics of individual de-
The software development industry recognizes the need to velopment environments [7]. Therefore, it is necessary to
define and manage processes in order to gain quality and consider the application domain, as well as organizational,
productivity, as well as to apply practices that allow them to project and team characteristics, among others [12].
make the best use of the available resources [3]. This research seeks to gain a better understanding of
Software development has adopted different forms during how software development has evolved and the challenges
its evolution. It has followed highly formalized or structured involved in following a traditional or agile software process
approaches (high ceremony) with a close management super- depending on the context. The results of this study can help
vision, and also by other more unstructured approaches (low organizations, projects and software teams get a better idea
ceremony). Many proposals for processes, models, methods, of which software processes fit their needs.
tools, techniques and concrete practices have been proposed
to this end. However, evidence suggests that “there is no II. BACKGROUND
unique approach to software development” [4].
Traditional processes follow methods based on the quality According to Cugola and Ghezzi [13], the interest to-
of the artifacts, on the predictability of their processes and wards processes arises at the beginning of the 70s. Software
on architectural designs that can adapt the change before it engineers realized that desired qualities such as reliability,
has an adverse impact on the system [5]. The first proposal efficiency, evolution capacity, ease of use, etc., could only be
that followed this philosophy was the waterfall model created achieved by following a disciplined flow of activities. How-
by Winston Royce in 1970 [6]. Waterfall model established ever, only at the end of the 1980s software processes were
an era in which software development is recognized as recognized as a subject that deserves attention. Thereafter,
a complex activity, centered on people, which has many efforts were made to understand its fundamentals, develop
difficulties if it is not properly organized [7]. useful models, identify methods, provide tool support and
Soon problems arose: long development time, involvement help manage its progress.
of the client only at the beginning of the project, costly According to Kroll and Kruchten [14] a process “de-
changes, difficulties for innovation and excessive documenta- scribes who is doing what, how, and when”. Feiler and
tion that these rigorous processes implied. As a consequence, Humphrey [15] emphasize that a process is a set of partially
around 1990 a community that defends change from a ordered steps intended for achieving a goal that can be
radically different perspective has emerged. This new way associated with the production or improvement of software
of addressing software development, called “agile” by its products, or the provision of services.
 In [2], Fuggetta states in a comprehensive way, that “a as well as when the project is large, critical and complex.
software process can be defined as the coherent set of In general, it can be said that traditional processes are char-
policies, organizational structures, technologies, procedures, acterized by: predictive approach, integral planning, process
and artifacts that are needed to conceive, develop, deploy, orientation, exhaustive documentation, continuous learning
and maintain a software product”. From his perspective, during development and directed to large projects [5], [11],
Pressman [16] emphasizes that it is necessary to see the [16], [17], [23], [24].
software process as a guide for the activities, actions and Among traditional processes there are the so-called “life-
tasks that are required to obtain high quality software. In cycle process models” such as waterfall model [6], iterative
a more general way, Münch et. al. [17] argue that “a enhancement model [27], spiral model [28], evolutionary
software process is a goal-oriented activity in the context prototyping model [29], etc. A software life cycle defines
of engineering-style software development”, where “software the skeleton and philosophy according to which the software
process” not only applies to software development, but also process must be carried out [2]. However, they generally
to planning, coding, testing and maintaining software. explain in a high level of abstraction “what” to do and not
Paraphrasing Osterweil [18], software processes must be “how” to do it [17].
treated in the same way we treat software. These must These processes include similar activities for software
be carefully designed and constructed in addition to being development, but each one places different emphasis on
tested, executed, maintained and reused. Seeing software them. Some examples are:
development as a process has significantly helped to identify
the different dimensions of development and the elements • Waterfall model [6] prescribes a systematic and sequen-
necessary to propose effective methods and practices for each tial approach to software development that begins with
context [2]. the specification of requirements and follows through
analysis, design, coding, testing and operations. Each
III. A N OVERVIEW OF S OFTWARE P ROCESS phase consists of a defined set of activities and deliver-
A PPROACHES ables that must be completed before the next phase can
Since the beginning, software processes have been used to begin. Even so, the strict sequence allows for controlled
collect and organize knowledge about software development iterations. The use of waterfall requires familiarity with
and, since then, a large number of approaches compete for the domain, methods, techniques, tools, as well as
“the users’ favor” [11]. According the literature [5], [11], having stable requirements and a good understanding
[19], [20], [21], [22], [23], there are in practice two trends of them. This model is often referred to, but it is rarely
that guide software development, one following a “rigid plan- applied in its strict form [17].
driven approach” and the other a set of “slim agile methods”. • Iterative enhancement model [27] proposes to imple-
Processes that follow a more rigid approach are known as ment part of the complete system first, and then, add
traditional [16], plan-driven [5], classic [11], structured [24], functionality in a series of iterations. Each iteration
rich [19], and heavyweight [25], among others. For this is completed following a waterfall model, that is, the
research, the term traditional will be used. This approach requirements for the respective iteration are analyzed,
aims to address the entire life cycle of the software project. designed, implemented and so on. The result of each
On the other hand, the agile methods or more precisely “agile iteration is integrated with the system developed so far.
software development methods or processes” [26], intend Developing software iteratively when the requirements
to simplify the software process to the minimum to avoid are not completely clear or are still unstable, allows
“bureaucracy”. developers to deliver the most important functionalities,
and thus, clients can decide their priorities by setting the
Each of the approaches, agile or traditional, emerged at a
requirements for the next iteration.
critical moment in the history of software development with
• Spiral model [28] represents a risk-based approach
well-defined purposes and contexts.
where risk assessment determines the next phase of
A. Traditional processes the project. Spiral model combines aspects of waterfall,
Traditional processes intended to bring some order to the iterative enhancement and prototyping model. It allows
so-called “chaos of software development” [16], providing choosing the best approach for each iteration in order to
structure to the work and a roadmap for software teams. address the identified risks. A prerequisite to apply the
The traditional development assumes that all the desired spiral process is specialized knowledge on risk manage-
requirements and properties of the final product can be ment and assessment, so a poor risk assessment can lead
known and specified with precision before beginning the to the selection of wrong alternatives or development
construction of the final product [23]. This philosophy also approaches [17].
supports the need for a detailed plan from the beginning to The Unified Process (UP) [30] was proposed in an attempt
the end of the project, where a deviation from this plan is a to take advantage of the best features of life cycle processes
sign of bad work in the early stages of the project [19]. and to include some agile development principles. UP is
Boehm and Turner [5] state that traditional development a generic process framework designed as a structure for
is desirable when requirements are stable and predictable, the methods and tools of the Unified Modeling Language
(UML). This consists of four phases, Inception, Elabora- work for software life cycle processes from the collec-
tion, Construction, and Transition, and is use-case driven, tion of the first ideas and concepts to decommissioning
architecture-centric, iterative and incremental. obsolete systems. It organizes the activities carried out
The name Unified Process is used to describe the generic during the life cycle in seven groups of processes. Each
process that includes the elements common to most of of the 44 processes in these groups describes a purpose
its refinements [31]. The most widely known and docu- and shows a list of expected results, as well as the
mented refinement of UP is the Rational Unified Process activities and tasks required. This standard has been
(RUP) [32]; others are Open Unified Process (OpenUP) [33], explicitly designed to be used as a process reference
Agile Unified Process (AUP) [34], and Enterprise Unified model within ISO/IEC 15504 (SPICE) [42].
Process (EUP) [35], among others. RUP provides a flex- Numerous studies such as [43], [44], [45] suggest that
ible and iterative life cycle that must be adapted to the higher process maturity brings higher product quality, the
exact characteristics of the project and a set of techniques, ability to meet deadlines and other successful indica-
templates, job descriptions and tools to guide the work. In tors of organizational performance. However other publi-
addition to UP characteristics, RUP includes three supporting cations [13], [46], [47] refer to cases in which they did
disciplines: Configuration and change management, Project not result in a better organization, but greater bureaucracy,
management and Environment. RUP sacrifices some speed more time than expected and greater effort. In the opinion
and flexibility in the development process so that changes in of Münch et al. [17], people often tend to reject processes
the system can be explained, agreed and formally specified perceived as boring or unnecessarily complicated, especially
before implementation [20]. if they demand work that does not seem to directly benefit
According to Larman [36], UP or RUP (hereinafter RUP) the worker per se. According to Pressman [16], despite
may or may not be considered agile. Although its creators the number of mechanisms that exist to determine process
and other defenders say that RUP is an agile software maturity, the quality, opportunity and long-term viability of
process [26], [37], many authors consider it a heavy and a product are the best indicators of the effectiveness of the
bureaucratic process due to the dependence on initial plans applied process.
or extensive documentation to generate [11], [19], [23].
For the purposes of this research, it will be treated as a
B. Agile Philosophy
traditional process taking into account its orientation towards
the process. The Agile philosophy emerges as a reaction to the tra-
In the 80s, the software industry increasingly began to ditional processes [25], as well as to cope with the new
worry about software quality [13]. However, reports about dynamics of the market and the client’s changing needs [22].
the successful software projects completion [38] were not According to Highsmith [48], the interest for agile methods
very encouraging. All this favored the adoption of models or ecosystems (as he prefers to call them) appeared at
and quality standards under the premise that the quality of the the beginning of the 2000, although their roots go back
process guarantees product quality [3]. International quality more than a decade before. In this time some projects were
standards usually used to certify organizations started being successful using the first versions of some agile methods such
perceived as an indirect means for guaranteeing that projects as Scrum [49], Dynamic Software Development Method-
would deliver quality products. Some of these models and ology (DSDM) [50] and Adaptive Software Development
standards for the improvement and evaluation of processes (ASD) [51].
are ISO 9001, Capability Maturity Model Integration for According to Abrahamson et al. [52], “agile denotes the
Development (CMMI) and ISO/IEC 12207. quality of being agile; readiness for motion; nimbleness, ac-
• ISO 9001:2015 [39] specifies the requirements to cre- tivity, dexterity in motion”. However, they argue that there is
ate a quality management system in any organization, no consensus as to what is exactly agile and what it means in
regardless of its type, size or the products and services different contexts [1], [53]. In the opinion of Kruchten [10],
it provides. ISO 9001 is sometimes criticized as being agility is “the ability of an organization to react to changes
a general approach to product quality that is not specif- in its environment faster than the rate of these changes”,
ically focused on software development [7]. beyond the application of a set of practices (Scrum, XP, etc)
• CMMI [40] is a collection of good practices to help or properties (The Agile Manifesto). Dingsøyr et al., show
organizations dedicated to the development of software in [54] a set of opinions about what is meant by “agile”
products and services, in their processes evaluation according to various authors.
and improvement. CMMI includes 22 different process The development of agile software is generally incremen-
areas that cover five different process maturity levels. tal, cooperative, straightforward, and adaptive [52]. Accord-
Addressing and trying to improve performance in all ing to Highsmith and Cockburn [55] the novelty of agile
these process areas requires a significant organizational methods is not the practices that they use, but the recognition
effort and involves many people over a long period of of people as the main drivers of project success, together with
time. This characteristic makes CMMI generally more a focus on effectiveness and maneuverability. This vision of
attractive for large software organizations. the agile world is described through a set of values and the
• ISO/IEC 12207:2008 [41] establishes a common frame- principles in The Agile Manifesto [8].
 Several publications [25], [48], [56], [57] refer to the term support and maintenance as well as traditional software
“agile” as a general way of calling methods such as Scrum, processes. The fundamental idea of DSDM is that in-
Extreme Programming (XP) [58], Lean Software Develop- stead of setting the amount of functionality in a product
ment (Lean) [59], Crystal [60], Feature Driven Development and then adjusting the time and resources to achieve
(FDD) [61], DSDM, ASD, Kanban [62] and others. Although that functionality, it is preferred to set the time and
the individual practices are varied, they can be classified into resources, and adjust then the amount of functionality
six general categories [48]: accordingly.
• Visioning For a better understanding of these methods, [64] shows
• Project initiation a summary table of the practices and the corresponding
• Short, iterative, feature-driven, timeboxed development agile values of six of the agile methods mentioned above.
cycles Similarly, in [65], the agile software development practices
• Constant feedback and the agile principles they support are shown. Also, in [52]
• Customer involvement each method is evaluated according to software life cycle
• Technical excellence coverage, project management support, type of guidance,
All methods address the six key practice areas, but some situation appropriateness and the level of empirical support.
focus more on collaborative practices and project manage-
Agile development status
ment (ASD, Scrum and DSDM), while others like XP focus
on software development practices. Some of the most wide According to results of the study “Status Quo Agile
used in industry are described below. 2016/17” [66], in which more than 1000 people participated
• Scrum [49] is a process framework used for managing
with a representation of more than 30 countries (mostly
product development and other knowledge work in a European), 85% of the users of Agile methods surveyed
volatile environment. It is an empirical approach based agree that the most used method is Scrum and then follow
on transparency, inspection and adaptation. Scrum is Kanban, Lean and DevOps [67]. More than 50% of the
structured in a way that allows for choosing techniques, participants started using Scrum in 2014 or later, and 70%
methods and practices for software development specific declare that they started using Kanban in the last 3 years.
for the context of the team or project. It includes The “11th Annual State of Agile Report” [68] with
frequent management activities with the aim of con- representation from all continents (mostly North America),
sistently identifying any deficiency or impediment in confirms that the adoption of Agile continues to grow. The
the development process, as well as in the practices 94% of the respondents claimed that their organizations
that are used. Scrum is more appropriate in case where practice agile, although they also say that more than half
multifunctional teams work in a product development of the teams in their organizations still do not practice agile.
configuration where there is a non-trivial amount of Scrum and Scrum/XP Hybrid are the agile methodologies
work that can be divided into a set of iterations of 2 most commonly used by organizations, while the use of XP
to 4 weeks [63]. as an independent methodology decreases, even though the
• XP [58] is the most specific of the agile methods
practices associated with XP are still frequent. The report
regarding appropriate engineering practices for software states that 71% of organizations surveyed have current or
development. According to Highsmith [48], “in XP you planned DevOps initiatives.
only do what you need to create value for the customer”. Both surveys agree that the main reasons to work with ag-
XP intends to enable the development of successful ile methods are: shorten time to market, improve the quality,
software despite vague or constantly changing software reduce project risk, better change management, higher team
requirements. Some of the main features of XP are productivity and better visibility of the project.
short iterations with small releases and rapid feedback, The results of [66] lead the authors to conclude that
close customer participation, constant communication the success rate of agile methods is still higher than that
and coordination, continuous refactoring, continuous of traditional project management. According to the data
integration and testing, collective code ownership and of [66], [68] the improvements due to the implementation
pair programming. Due to its specificity, its use is not of agile methods are greater than the effort involved in the
recommended in some situations1 such as the develop- implementation itself. Even so, there are challenges to agile
ment of critical systems for security where the change scaling such as the disagreement of the organizational culture
should be handled very carefully, to give an example. with agile values and the lack of skills or experience with
• The first version of the DSDM method [50] was de-
the methods [68].
veloped in 1994 and is considered the first truly agile IV. C HALLENGES OF TRADITIONAL AND AGILE
software method. Its creators and defenders call it APPROACHES
method or framework, that is the reason why the term
process was not used in this case. DSDM covers all There is no unique process or particular approach that
aspects of software development from project startup to offers a set of principles or practices equally suitable for any
purpose or be flexible enough to be applicable in any type
1 http://wiki.c2.com/?WhenIsXpNotAppropriate of project [4]. According to Feiler and Humphrey [15], the
basic requirement of an appropriate software process is that imprecise contract may create false expectations and may
it must fit the needs of the project. Clarke and O’Connor [7] build low confidence relationships. In any case, the worst
state that the needs of a project are based on the context scenario happens when managers prioritize complying with
of the situation in which it should work and therefore, the the contract over reaching good project results.
software process depends on the context. Diebold and Zehler [19] establish that client’s participation
Research such as [5], [7], [10], establish a series of factors only at the beginning of the project usually provides limited
that characterize the software development context and that feedback for later development stages and also problems for
may significantly affect the adoption of a software process dealing with changes.
at the level of the organization, project or development A study by Petersen and Wohlin [23] about challenges of
team. Some of these factors that should be taken into the waterfall model, indicates that the main reason for failure
account are: governance type, business domain, maturity of in this approach is that the actual needs of the clients are not
the organization, level of innovation, culture, size of the achieved until the end of the project. Besides, the distance
system, personnel, team distribution, architectural effort, rate with the client causes misunderstandings that may result
of change, and criticality, among others. in modified or forgotten requirements and consequently
Both, traditional and agile software development, have unnecessary work and rework.
their strengths and limitations depending on the context, Test coverage is sometimes reduced due to multiple rea-
and applying them far from their “sweet spot” is always a sons. In general testing is addressed late in the project
challenge. and, if there are any delays, it is compromised [5], [19],
[23]. Moreover, the later testing is performed, the higher the
A. Contexts for traditional approaches amount of errors found [16]. Rework is then needed and it
Strengths of discipline may be hard to correct some of these errors [5], [23].
Diebold and Zehler [19] state that counting on an initial Another common criticism to traditional processes comes
plan such as that required in traditional software development from the excessive documentation they require and that most
is essential for evaluating tenders and negotiating contracts of the times is not used [5], [23], [69].
before starting the project. In this way software development Scientific literature [5], [16], [23] suggests that traditional
supported on concrete and standardized processes favors processes are hard to adapt to small projects. Also, small
project transparency, improves management and increases the and changing applications cannot afford the investment in
chances of success. Other reasearch [5], [11], [22] also men- architectural design demanded by traditional processes [5].
tion that traditional processes provide better predictability, Excessively bureaucratic cultures and methods can block
repeatability, and optimization opportunities. software development [5]. According to Diebold and
According to [69], traditional approaches stress the deter- Zehler [19], several criticisms about traditional approaches,
minant role that design and architecture play in the case of and specially that about inflexibility, made apparent the need
large-scale software and systems. Also, this approach is the for alternatives in software processes.
most appropriate when most requirements of the final product Research about difficulties posed by traditional processes
can be specified from the beginning and it is not needed is vast and deep, mainly leaded by agile philosophy and
to involve final users during the project [19], [21]. Projects other approaches defenders. However, in Gregory et al.’s
with high criticality are another context where traditional opinion [70], reports about the application of agility usually
development is the best approach, since requirements should describe success histories of solved problems and hardly ever
be specified and analyzed up front [5], [21]. persistent difficulties, deterioration situations or even com-
Several research works [5], [19], [21] agree that tradi- plete failure. This is why this research just mentions some
tional software development allows personnel to be moved general difficulties of traditional approaches and focuses on
between different projects without much training. Similarly, strengths and weaknesses of agility.
Špundak [21] suggests that certain characteristics of the B. Contexts for agile methods
development team make this approach the most appropriate:
development teams with little experience, when team mem- Advantages of agility
bers are likely to change along the project, or when managers Agile software development is considered more flexible
are not in constant contact with the team. He also says that and adaptable in contexts where client’s needs change fre-
large organizations are better suited for these processes since quently [5], [22], [23], [48], as well as for small collocated
they generally put a higher stress on control. teams [37], [71]. According to Highsmith [48], the more
volatile the requirements are and the more experimental
Difficulties of traditional processes technology is, the higher success possibilities agile methods
Counting on a contract offers a series of advantages provide.
but, according to Boehm and Turner [5], this interface Numerous researchers [37], [71], [72], [73], [74] agree
between developers and clients poses the highest tension that the main advantages of agility relate with the benefits
when applying traditional methods. They say that a reaching derived from frequent communication and feedback, e.g.,
a precise contract delays the beginning of the project and better learning, knowledge transfer, among others. Begel and
makes difficult to adapt to changes. On the other hand, an Nagappan [74] emphasize that agile methods promote higher
morale among team members. People feel more comfortable, on comparable skills, development will not be effective.
motivated and confident working in agile environments [22], Similarly, the lack of experience may generate big delays
[37], [71], [74]. when new practices are implemented [22].
Clients feel more satisfied when agile methods are ap-
• Scalability
plied because they provide the opportunity of receiving
Scalability is understood as the breadth of activities for
early feedback and they can soon answer to changes [37],
which the process definition is designed. This might include
[71]. Similarly, developers value constant collaboration with
the ranges in number of people, size of product, time
clients these methods promote [23], [37], [71], [74]. There
duration, product life cycle, or development environment for
also exist the perception that software products exhibit higher
which the process is fit and precise [15].
quality and teams are more productive [37], [71], [74].
Research such as [5], [37], [71], [74] found that it is a
Yet other works highlight other advantages such as project
challenge to scale agile methods. A study conducted by [22]
transparency and less time wasted in irrelevant tasks [71],
revealed that scalability is a rather significant limitation and
[74].
it is still an open issue to be addressed by researchers.
Difficulties of agile software methods According to [19], [22], agility provides limited support
Despite all the advantages that agile methods provide, for distributed environments, large projects (either long in
the process of adopting the approach or transforming an time, very expensive or highly risky) and large teams.
organization toward agility is a challenge [10]. According Their application in these contexts can bring difficulties in
to [22], changes not only affect the development process communication and/or development delays, just to mention
itself, but also they need to take into account a whole series some. According to [5], confidence in tacit knowledge is
of other factors: communication means, client participation, another limit to scale agility.
requirements, change management, management style, peo- • Specific domains
ple and current processes. Several scientific works [5], [22], [71], [72], [74], [77],
Table I summarizes some of the difficulties of agile [78] agree that agile methods have serious limitations in
methods reported in the literature. safety-critical domains (e.g., military or health care where
• Customer involvement the software needs to be of the highest quality possible)
According to Boehm and Turner [5], the success of agile and legacy systems mainly because of simple design and
development depends on having customers representatives the lack of documentation. Also, testing is a bottleneck in
who are collaborative, representative, authorized, committed agile projects for safety-critical systems since they must be
and knowledgeable (CRACK). This is apparent in the experi- frequent and exhaustive [71]. On the other hand, Boehm
ence on the Chrysler Comprehensive Compensation project2 and Turner [78] state that using agile methods for legacy
(C3), that is accepted as the first evidence of the use of XP’s systems, either for maintenance or for a new development,
practices [57]. brings problems relating refactoring.
Referring this issue, Stephens and Rosenberg [79] agree • Architecture focus and technical debt
that C3 is a success case of XP. However, after several Another limitation of agile methods extensively mentioned
pauses and delays, the project was canceled [75]. Some in the literature [5], [10], [71], [74] is the lack of attention
of the problems that lead to project failure were changing received by design and architecture. These issues bring as a
the client on site without an opportune transfer [75], and consequence a grow in technical debt.
bad communication between the client on site and other According to Kruchten et al. [76], technical, quality and
stakeholders [20], among others. maintainability debts are not only caused by pressure on
Another similar case is presented in [75] where the de- schedules as other researchers argue, but carelessness, lack
velopment of a software product line called DocGen faced of education, poor processes, nonsystematic verification of
several challenges due to the involvement of many different quality, or basic incompetence. Other factors that contribute
representatives of the client party. There is certain consensus to technical debt in agile projects are: developing and de-
that client on site is one of the most stressful issue for the livering very rapidly, with no time for proper design or to
application of agile methods [5], [23], [37], [73]. reflect on the longer term, and lack of rigor or systematic
• Professional demands testing.
According to scientific literature [5], [22], [37], [68], • Discarded practices
[73], [74], [76], agile methods are very demanding when A study by Petersen [71] suggests that the lack of
considering professional skills in order to be successful. professional skills for agile development results in aban-
Creating an effective agile team is a challenging task [22]. doning certain agile practices as time passes. The most
Teams require highly trained managers, high qualifications frequently abandoned practices are: pair programming, test-
in all team members, and a steep learning curve. Dybå and driven development, and continuous integration. Others work
Dingsøyr [37] also argue that, if team members do not count reporting similar results [37], [71], [74] indicate that pair
2 http://wiki.c2.com/?ChryslerComprehensiveCompensation; Octubre 11, programming is perceived as an exhausting task whenever
2017 partners do no count on the same qualification.
 TABLE I
R EPORTED DIFFICULTIES OF AGILE METHODS

ID Difficulty Reference
AD1 Customer does not keep CRACK [5], [20], [23], [37], [73], [75]
AD2 Professional skill-specific demands [5], [22], [37], [68], [73], [74], [76]
AD3 Agile development does not scale well [5], [19], [22], [23], [37], [68], [71], [74], [77]
AD5 Lack of suitability for specific product domains [5], [22], [71], [72], [74], [77], [78]
AD6 Architecture does not get enough focus [5], [10], [71], [74]
AD7 Some practices are discarded after a period of time [22], [37], [71], [74]
AD8 Increased testing effort [22], [23], [71], [73]
AD9 Risks in knowledge and project management [5], [22], [37], [71], [73], [74], [77]
AD10 Increment of technical debt [76]

• Testing effort In [47], Glass reflects on the causes that made a company
A case study conducted by [71] concluded that in several, try to implement CMMI for three years without being able
sometimes in small projects, independent tests are performed to surpass level 1. The company develops web applications
only partially or they are omitted completely. This makes from scratch, to respond to the specific needs of diverse
that the burden of testing falls in the latest system version, clients. This scenario suggests an agile development and
demanding a huge effort [22], [71], [73]. A determinant not a traditional approach such as that implied by CMMI.
factor that influences test reduction is the close relation The author concludes that they made a big mistake trying to
between designers and testers, where designers sometimes apply a process -CMMI in this case- in a context far from
press testers so that they focus only in certain parts of the its application “sweet spot”.
system. “The close relation between testers and designers Similar situations are described in [10], where Kruchten
affects independent testing negatively” [71]. Another prob- explains the failure of projects involving legacy software,
lem relating testing is that agility requires a big effort for safety-critical systems, low requirements change, and nobody
performing continuous testing because creating an integrated playing the role of client to interact with, among others.
testing environment is difficult for different platforms and According to [10], [26], [56], the contextual factors that
system dependencies [23], [71]. more frequently make agile projects to fail are: size, large
• Knowledge and project management systems with a lack of architectural focus, software develop-
Boehm and Turner [5] highlight the risk of completely ment not driven by customer demand, lack of support from
relying on the tacit knowledge assumed by agile methods, surrounding stakeholders, novice team, very high constraints
mainly in large teams, and the situations when people of some quality attributes (safety-critical system, real-time
abandon the team. Dybå and Dingsøyr [37] alert that in agile constraints). Similarly, a study conducted by [81] about agile
teams, members are not so interchangeable as needed and methods adoption for large-scale development concluded
this issue has direct consequences on project management. that one of the most determinant challenges is the cultural
Provided that the organizational environment impacts signif- transformation of the organization, mainly at the middle
icantly in the implementation of agile project management, management level.
the organization should be prepared to accept changes this V. C ONCLUSIONS
approach requires or otherwise they would face serious
This study provides an overview of the evolution of the
difficulties [5]. According to [22], managerial abilities are
software development approaches. It provides some defini-
crucial for the success of agile philosophy. The team leader
tions that are sometimes vague in literature such as what a
is responsible for constantly reducing risks, recording team
software process actually is. A summary is provided about
progress, and soon reacting to any difficulty. On the other
weaknesses of traditional approaches that have led to the
hand, teams should be able to self-organize instead of being
proposal of agile methodologies. Strengths and weaknesses
centrally managed [22], [71], [73], [74], [77].
of traditional and agile processes are surveyed, allowing us
C. Outside of the sweet spot to understand the challenges faced when applying one or the
Failure is a natural part of the application of any pro- other approach outside the sweet spot.
cess [80], and understanding what went wrong is a powerful According to Adolph and Kruchten [82], “failure is the
learning experience that allows us to know what went well dark family secret in our industry”. Therefore, there is poor
too [70]. One of the main causes of failure in software published evidence about persistent difficulties or failure
development is the application of processes in contexts that situations in practice that would allow us to learn from errors.
are, at least in some dimensions, far from the contexts for There is no unique way to develop software. The best
which they were created [10], [47]. way depends on specific factors relating the context of
the organization, the project and the development team. [23] Kai Petersen and Claes Wohlin. The effect of moving from a plan-
Therefore, a large number of researchers [5], [11], [12], driven to an incremental software development approach with agile
practices. Empirical Software Engineering, 15(6):654–693, 2010.
[20], [21], [72] advocate for a balance between discipline [24] Hans-Christian Estler, Martin Nordio, Carlo A Furia, Bertrand Meyer,
and agility in order to take advantage of the best of both and Johannes Schneider. Agile vs. structured distributed soft-
worlds. ware development: A case study. Empirical Software Engineering,
19(5):1197–1224, 2014.
[25] Kevin Aguanno. Managing agile projects. Multi-Media Publications
R EFERENCES Inc., Lakefield, Ontario, Canada, 2005.
[1] Marco Kuhrmann, Jürgen Münch, Ita Richardson, Andreas Rausch, [26] Philippe Kruchten. Voyage in the agile memeplex. Queue, 5(5):1,
and He Zhang (eds.). Managing Software Process Evolution: Tradi- 2007.
tional, Agile and Beyond–How to Handle Process Change. Springer, [27] Victor R Basil and Albert J Turner. Iterative enhancement: A practical
2016. technique for software development. IEEE Transactions on Software
[2] Alfonso Fuggetta. Software process: A roadmap. In Proceedings of Engineering, (4):390–396, 1975.
the Conference on The Future of Software Engineering, ICSE ’00, [28] Barry W. Boehm. A spiral model of software development and
pages 25–34, New York, NY, USA, 2000. ACM. enhancement. Computer, 21(5):61–72, 1988.
[3] Watts S. Humphrey, Terry R. Snyder, and Ronald R. Willis. Software [29] Christiane Floyd. A systematic look at prototyping. In Approaches to
process improvement at hughes aircraft. IEEE software, 8(4):11–23, prototyping, pages 1–18. Springer, 1984.
1991. [30] Ivar Jacobson, Grady Booch, James Rumbaugh, James Rumbaugh, and
[4] F Brooks and HJ Kugler. No silver bullet. April, 1987. Grady Booch. The unified software development process, volume 1.
[5] Barry Boehm and Richard Turner. Balancing Agility and Discipline: Addison-wesley Reading, 1999.
A Guide for the Perplexed. Addison-Wesley Professional, 2003. [31] Kendall Scott. The unified process explained. Addison-Wesley
[6] Winston W Royce. Managing the development of large software Longman Publishing Co., Inc., 2002.
systems. In Proceedings of the 9th international conference on [32] Philippe Kruchten. The rational unified process: an introduction.
Software Engineering, pages 328–338. IEEE Computer Society Press, Addison-Wesley Professional, 2004.
1970. [33] Bjorn Gustafsson. Openup–the best of two worlds. Methods & Tools,
[7] Paul Clarke and Rory V O’Connor. The situational factors that affect 16(1):21–32, 2008.
the software development process: Towards a comprehensive reference [34] Scott Ambler. Agile modeling: effective practices for extreme pro-
framework. Information and Software Technology, 54(5):433–447, gramming and the unified process. John Wiley & Sons, 2002.
2012. [35] Scott Ambler, John Nalbone, and Michael Vizdos. Enterprise unified
[8] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, process, the: extending the rational unified process. Prentice Hall
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Press, 2005.
Andrew Hunt, Ron Jeffries, et al. Manifesto for agile software [36] Craig Larman. Agile and iterative development: a manager’s guide.
development, 2001. Addison-Wesley Professional, 2004.
[9] Sanjiv Augustine. Managing agile projects. Prentice Hall PTR, 2005. [37] Tore Dybå and Torgeir Dingsøyr. Empirical studies of agile software
[10] Philippe Kruchten. Contextualizing agile software development. Jour- development: A systematic review. Information and software technol-
nal of Software: Evolution and Process, 25(4):351–361, 2013. ogy, 50(9):833–859, 2008.
[11] Georgios Theocharis, Marco Kuhrmann, Jürgen Münch, and Philipp [38] Standish Group et al. The chaos report. Capturado em: http://www.
Diebold. Is water-scrum-fall reality? on the use of agile and traditional standishgroup. com, 1995.
development practices. In International Conference on Product- [39] ISO/TC 176/SC 2 Quality systems. Iso 9001:2015 quality management
Focused Software Process Improvement, pages 149–166. Springer, systems – requirements). Technical report, International Organization
2015. for Standardization, 2015.
[12] Leo R Vijayasarathy and Charles W Butler. Choice of software [40] CMMI Product Team. Cmmi for development (cmmi-dev). Tech-
development methodologies: Do organizational, project, and team nical report, Version 1.3, Technical Report, CMU/SEI-2010-TR-033,
characteristics matter? IEEE Software, 33(5):86–94, 2016. Software Engineering Institute, 2010.
[13] Gianpaolo Cugola and Carlo Ghezzi. Software processes: a retrospec- [41] ISO/IEC JTC 1/SC 7 Software and systems engineering. Iso/iec
tive and a path to the future. Software Process: Improvement and 12207:2008 systems and software engineering – software life cycle
Practice, 4(3):101–123, 1998. processes. Technical report, International Organization for Standard-
[14] Per Kroll and Philippe Kruchten. The rational unified process made ization, 2008.
easy: a practitioner’s guide to the RUP. Addison-Wesley Professional, [42] Han Van Loon. Process Assessment and ISO/IEC 15504: a reference
2003. book, volume 775. Springer Science & Business Media, 2004.
[15] Peter H Feiler and Watts S Humphrey. Software process development [43] Dennis Goldenson and James D Herbsleb. After the appraisal: A
and enactment: Concepts and definitions. In Software Process, 1993. systematic survey of process improvement, its benefits, and factors
Continuous Software Process Improvement, Second International Con- that influence success. Technical Report CMU/SEI-95-TR-009, CMU,
ference on the, pages 28–40. IEEE, 1993. 1995.
[16] R.S. Pressman. Software Engineering: A Practitioner’s Approach. [44] B Clark. Quantifying the effects on effort of software process maturity.
McGraw-Hill higher education. McGraw-Hill Education, 2010. IEEE Software Journal, 17(6):65–70, 2000.
[17] Jürgen Münch, Ove Armbrust, Martin Kowalczyk, and Martin Sotó. [45] Donald E Harter, Mayuram S Krishnan, and Sandra A Slaughter.
Software process definition and management. Springer Science & Effects of process maturity on quality, cycle time, and effort in
Business Media, 2012. software product development. Management Science, 46(4):451–466,
[18] Leon Osterweil. Software processes are software too. In Proceedings 2000.
of the 9th international conference on Software Engineering, pages [46] Mark C Paulk. Surviving the quagmire of process models, integrated
2–13. IEEE Computer Society Press, 1987. models, and standards. In ASQ World Conference on Quality and
[19] Philipp Diebold and Thomas Zehler. The Right Degree of Agility Improvement Proceedings, volume 58, page 429. American Society
in Rich Processes, pages 15–37. Springer International Publishing, for Quality, 2004.
Cham, 2016. [47] Robert L Glass. Some heresy regarding software engineering. IEEE
[20] Vishnu Vinekar, Craig W. Slinkman, and Sridhar P. Nerur. Can Software, 21(4):104–103, 2004.
agile and traditional systems development approaches coexist? an [48] Jim Highsmith. What is agile software development? CROSSTALK
ambidextrous view. IS Management, 23(3):31–42, 2006. The Journal of Defense Software Engineering, 15(10):4–9, 2002.
[21] Mario Špundak. Mixed agile/traditional project management [49] Ken Schwaber. Agile project management with Scrum. Microsoft
methodology–reality or illusion? Procedia-Social and Behavioral press, 2004.
Sciences, 119:939–948, 2014. [50] Jennifer Stapleton. DSDM, dynamic systems development method: the
[22] Adam Solinski and Kai Petersen. Prioritizing agile benefits and method in practice. Cambridge University Press, 1997.
limitations in relation to practice usage. Software quality journal, [51] Jim Highsmith. Adaptive software development: a collaborative
24(2):447–482, 2016. approach to managing complex systems. Addison-Wesley, 2013.
[52] Pekka Abrahamsson, Juhani Warsta, Mikko T Siponen, and Jussi [78] Barry Boehm and Richard Turner. Management challenges to im-
Ronkainen. New directions on agile methods: a comparative anal- plementing agile processes in traditional development organizations.
ysis. In Software Engineering, 2003. Proceedings. 25th International IEEE software, 22(5):30–39, 2005.
Conference on, pages 244–254. Ieee, 2003. [79] Matt Stephens and Doug Rosenberg. Where Did XP Come From?
[53] Pekka Abrahamsson, Kieran Conboy, and Xiaofeng Wang. ‘lots done, (Chrysler Knows It Ain’t Easy.), pages 31–56. Apress, Berkeley, CA,
more to do’: the current state of agile systems development research, 2003.
2009. [80] Pekka Abrahamsson, Muhammad Ali Babar, and Philippe Kruchten.
[54] Torgeir Dingsøyr, Sridhar Nerur, VenuGopal Balijepally, and Agility and architecture: Can they coexist? IEEE Software, 27(2),
Nils Brede Moe. A decade of agile methodologies: Towards explaining 2010.
agile software development, 2012. [81] Kim Dikert, Maria Paasivaara, and Casper Lassenius. Challenges
[55] Jim Highsmith and Alistair Cockburn. Agile software development: and success factors for large-scale agile transformations: A systematic
The business of innovation. Computer, 34(9):120–127, 2001. literature review. Journal of Systems and Software, 119:87–108, 2016.
[56] Rashina Hoda, Philippe Kruchten, James Noble, and Stuart Marshall. [82] Steve Adolph and Philippe Kruchten. Summary for scrutinizing agile
Agility in context. ACM Sigplan Notices, 45(10):74–88, 2010. practices or shoot-out at process corral! In Companion of the 30th
international conference on Software engineering, pages 1031–1032.
[57] Alan Moran. Managing Agile. Springer, 2016.
ACM, 2008.
[58] Kent Beck. Extreme programming explained: embrace change.
addison-wesley professional, 2000.
[59] Poppendieck Mary and Poppendieck Tom. Lean software develop-
ment: an agile toolkit, 2003.
[60] Alistair Cockburn. Crystal clear: a human-powered methodology for
small teams. Pearson Education, 2004.
[61] Steve R Palmer and Mac Felsing. A practical guide to feature-driven
development. Pearson Education, 2001.
[62] David J Anderson and Andy Carmichael. Essential Kanban Con-
densed. Blue Hole Press, 2016.
[63] Mike Cohn. Succeeding with agile: software development using Scrum.
Pearson Education, 2010.
[64] Asif Qumer Gill, Brian Henderson-Sellers, and Mahmood Niazi.
Scaling for agility: A reference model for hybrid traditional-agile
software development methodologies. Information Systems Frontiers,
pages 1–27, 2016.
[65] Laurie Williams. Agile software development methodologies and
practices. Advances in Computers, 80:1–44, 2010.
[66] Ayelt et al. Komus. Study report: Status quo agile 2016/2017.
Technical report, Hochschule Koblenz University of Applied Sciences,
http://www.status-quo-agile.de/, 2017.
[67] Michael Httermann. DevOps for developers. Apress, 2012.
[68] VersionOne. 11th annual state of agile report. Technical report, Tech-
nical report, VersionOne, http://stateofagile.versionone.com/, 2016.
[69] Kai Petersen, Claes Wohlin, and Dejan Baca. The waterfall model in
large-scale development. In PROFES, pages 386–400. Springer, 2009.
[70] Peggy Gregory, Leonor Barroca, Katie Taylor, Dina Salah, and Helen
Sharp. Agile challenges in practice: a thematic analysis. In Inter-
national Conference on Agile Software Development, pages 64–80.
Springer, 2015.
[71] Kai Petersen and Claes Wohlin. A comparison of issues and advan-
tages in agile and incremental development between state of the art
and an industrial case. Journal of systems and software, 82(9):1479–
1490, 2009.
[72] Marco Kuhrmann, Philipp Diebold, Jürgen Münch, Paolo Tell, Vahid
Garousi, Michael Felderer, Kitija Trektere, Fergal McCaffery, Oliver
Linssen, Eckhart Hanser, and Christian R. Prause. Hybrid software
and system development in practice: Waterfall, scrum, and beyond.
In Proceedings of the 2017 International Conference on Software and
System Process, ICSSP 2017, pages 30–39, New York, NY, USA,
2017. ACM.
[73] Minna Pikkarainen, Jukka Haikara, Outi Salo, Pekka Abrahamsson,
and Jari Still. The impact of agile practices on communication in
software development. Empirical Software Engineering, 13(3):303–
337, 2008.
[74] Andrew Begel and Nachiappan Nagappan. Usage and perceptions of
agile software development in an industrial context: An exploratory
study. In Empirical Software Engineering and Measurement, 2007.
ESEM 2007. First International Symposium on, pages 255–264. IEEE,
2007.
[75] Arie Van Deursen. Customer involvement in extreme programming.
ACM SIGSOFT Software Engineering Notes, 26(6):70, 2001.
[76] Philippe Kruchten, Robert L Nord, and Ipek Ozkaya. Technical debt:
From metaphor to theory and practice. Ieee software, 29(6):18–21,
2012.
[77] Leo R Vijayasarathy and Dan Turk. Agile software development:
A survey of early adopters. Journal of Information Technology
Management, 19(2):1–8, 2008.