This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

Agile and Software Project

Management Antipatterns:
Clarifying the Partnership
Gabriela Castro
NetLogistik, Mexico

Ana M. Moreno
Universidad Politécnica de Madrid, Spain

Lawrence Peters
Universidad Politécnica de Madrid, Spain
Iowa State University, U.S.A

Abstract— Agile methods have been recognized as providing tangible benefits, some of them directly
related to software project management (SPM). In this paper we address in detail the relationship between
Agile and SPM, discussing the extent to which the use of agile practices helps to reduce or avoid the
occurrence of different SPM antipatterns. Our results may be particularly useful tor organizations in the
daunting journey of becoming agile.

INTRODUCTION long time in the software engineering literature,

Project management is recognized as being the [3]. They have also been synthesized and
primary cause of software project failure. A study reported on in the form of SPM antipatterns
by IBM [1] found that 53% of project failures [4][5]. Antipatterns formally describe
were attributable to poor project management counterproductive approaches to problem
while 3% were due to technical challenges. solving [5]. They can be a bad practice, a wrong
Companies like Google have recognized the reaction to a combination of events, a failure to
relevance of software management and ensured control a project factor, etc. but in any case they
management success through careful vetting, represent problematic scenarios that, if
training people for management roles and unresolved, will eventually lead to additional
having managers evaluated by the people they project failures. The notion of anti-pattern is
manage [2]. closely related to that of a project risk, in the
sense that antipatterns are potential risks to a
Dysfunctional approaches to software project project. Table 1 shows an example of the classic
management (SPM) have been discussed for a Detailitis Plan SPM antipattern.

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software
Table 1. Detailitis Plan antipattern [4]
Anti-Pattern Detailitis Plan
Name
Also Known As Death by Planning
Re-Factored Rational Planning
Solution Name
Re-Factored Process
Solution Type
Anecdotal “We can’t get started until we have a
Evidence complete program plan”. “The plan is the
only thing that will ensure our success”.
“As long as we follow the plan and don’t
diverge from it, we will be successful”... “
Background … occurs when detailed plans for
software projects are taken too seriously.
Short description Excessive planning for software projects
leads to complex schedules that cause
downstream problems…
Symptoms And Symptoms: Inability to plan at a
Consequences pragmatic level; Focus on costs rather
than delivery; Spending more time
planning and replanning than on
delivering software.
Consequences: … Endless planning and
replanning causes further planning and
replanning; The objective shifts from
delivery of software to delivery of a set of
plans; Continual delays to software
delivery and eventual project failure.
Typical Causes Overzealous continual planning to
attempt to enforce absolute control of
development.
Forced customer compliance.
Forced executive management
compliance.
Solution A project plan should show primarily
deliverables at two levels: Products and
Components. The deliverable plans
should be updated weekly. Tracking is
done on the estimated level of
completeness. …
The project manager’s lack of knowledge has
been identified by Silva et al. as the most
common cause of SPM malpractices, followed by
sloth, pride and haste [6]. These authors have
also highlighted the impact of such malpractices
on the customer, team members and,
paradoxically on the project manager.
Additionally, they discuss the direct impact of
0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded
antipatterns on SPM activities like controlling,
motivating and staffing.
The application of agile methods has been
recognized as providing relevant benefits,
directly related to SPM. Murphy et al. state that
project managers have the highest
understanding of agile benefits as compared to
other team roles [7]. Among the benefits of agile,
some of the traditionally mentioned are time
control, continuous software process
improvement and refinement, team satisfaction,
cooperation and adaptability skills, or increased
team productivity [8].
In this paper we address the relationship
between Agile and SPM, discussing the extent to
which the use of agile practices helps to reduce
or avoid the occurrence of different SPM
antipatterns.
We worked with a consolidated list of existing
SPM agile practices. Similarly, we used a
consolidated list of existing SPM antipatterns.
We then conducted an in-depth analysis of the
impact of such agile practices on the
antipatterns. To confirm the applicability of
those results we validated them with a
representative set of agile researchers and
practitioners. We concluded that several agile
practices can effectively help to prevent the
effects of specific SPM antipatterns. Other agile
practices, even if they cannot help to prevent the
consequences of the antipattern, can help the
project manager to identify a misleading
situation so he/she can take the corresponding
corrective action. Unexpectedly, we found a few
exceptions where a particular agile practice
contributed to the negative effects of certain
antipatterns.
Our results are useful for organizations in the
daunting journey of becoming agile [9]:
information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

 They can encourage organizations to literature published over the last ten years that
bring to surface their SPM malpractices collected agile practices. The details are in [11].
and identify the agile practices that can We confirmed that all practices provided by [10]
address them. were included in the scientific sources (although
sometimes different names were used) and
 They can be used in trade-off analysis to
there were not any extra agile practices included
define action plans containing the agile
in the scientific literature that were not
practices to be adopted according to
considered in [10]. Table 2 contains all the
their potential effects on the most
practices discussed in [10] with one exception.
critical antipatterns, among other
We included Kanban under the general practice
variables.
of Agile portfolio planning, as, according to [10],
 This information can provide decision Kanban is a specific way to address this task, and
making support for senior management both generated similar results in relation to the
and teams in order to evaluate the SPM antipatterns.
potential benefits of transitioning to
The validity threats for this study relate to the
Agile.
risks suggested by Petersen et al. [12]. Regarding
search coverage we worked with the most well-
known scientific databases and defined the
AGILE PRACTICES search string with several keywords to obtain the
A quick internet search provides several lists of most accurate secondary papers within our
agile practices. One of the most well-known scope. We might have used the list of agile
catalogs is reported in [10]. It was gathered from practices suggested by [10], but we wanted to
organizations in the global software confirm such a list with the existing literature. To
development community. The agile practices avoid bias in the study selection, we defined
described in this report are classified into two detailed inclusion and exclusion criteria, and the
groups: agile techniques and engineering first two authors independently agreed on the
practices. In this work we will focus on the agile final selection of the secondary papers according
techniques, as the engineering practices to these criteria. Then, the search was
reported generally refer to technical activities complemented with snowball sampling. Finally,
(e.g. unit testing, refactoring) not directly linked to deal with the data extraction and classification
to management issues. threat, a data extraction form was filled by the
first author with the information about the
In order to confirm that the agile techniques in secondary papers, and analyzed and evaluated
[10] are also in accordance with the scientific by the second author to ensure that the selected
community we performed a tertiary study of data were meaningful for our study.

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

Table 2. Consolidated list of agile practices (ordered by their frequency of use in industry) [10]
Agile practice Description
Daily Stand-ups is one of the most common practices followed by agile teams. Is a meeting that takes
Daily standup
place every day, preferably face-to-face, to report updates on the daily work.
Sprint planning sessions held at the beginning of the sprint (iteration cycle), are intended to review
Sprint
and analyze possible changes and to define the sprint backlog, with the tasks to be completed in the
planning
sprint.
Retrospectives are the meetings held after the completion of an iteration to suggest process
Retrospectives
improvements for the following sprint.
Sprint review is a meeting where the team usually presents the sprint work to the product owner for
Sprint review
their feedback.
Short iterations typically seek to maintain a consistent sprint length. Its implementation behaves as a
Short
support for agile team accuracy while calculating the amount of work that they would be able to
iterations
perform.
Release Release planning is performed as an independent session for planning every release. Its purpose is to
planning estimate which features will be delivered in the established release deadlines.
Planning Planning poker is shaped by numbered cards in a Fibonacci series. It is used by the agile team as a tool
poker to estimate the value of each task that should be performed.
Available A product owner is responsible for managing the customer requirements, transforming them on
product backlog items and prioritizing it for then communicate them to the agile team.
owner
Single team is a practice in which theoretically, every team member is open to take up any work
Single team
irrespective of their skill set.
Frequent Frequent releases allow the team to see the state of the system and track if the deadlines are being
releases meet.
Common work Common working area supports frequent meetings, that lead to informal communication among
area stakeholders, which aids to the constant evolution of the requirements
Product Planning the roadmap of a product is part of the practices that help to have a general overview of what
roadmapping is expected from the product and how the system is being constructed based on the features.
Story mapping Story mapping is a technique to organize the product backlog by release and functionalities.
Agile portfolio An agile portfolio planning is a support to keep track of the activities that are in process. It shows the
planning status of each of the tasks that were planned for the sprint.
Agile UX seeks to integrate the user experience practices into the agile development cycle. Performing
Agile UX corporate design standards and getting feedback from clients to refine the requirements and
prototypes.

SOFTWARE PROJECT MANAGEMENT antipatterns, as the latter refer to malpractices of

ANTIPATTERNS
Our goal is to discuss the effect of agile practices
on SPM antipatterns, so this information can be
useful for organizations exploring the possibility
of transitioning to agile or already in this
transition. Therefore, we focus on general SPM
antipatterns and not specific agile SPM
organizations that already use agile practices. The
study of these agile antipatterns would also be
highly relevant, but it is not related to our scope.
In 2015, Silva et al. published an integrated list of
SPM antipatterns gathered through a tertiary
study of the literature [6]. This work analyzed
different lists of SPM antipatterns resulting in a
consolidated list of 22 SPM malpractices.

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

In order to check if there exists a more recent list
of SPM antipatterns we performed another
ternary study of scientific literature dealing with
SPM antipatterns published from 2015 till June
2019. The details can be found in [11]. We did not
find any secondary study with SPM antipatterns
published later than 2015. However, we found
information about SPM antipatterns in grey
literature (sources different from scientific
documents like books, journals or conference
papers), like [13][14]. We confirmed that the set
of antipatterns found in these sources is a subset
of the ones in [6]. However, these publications
are evidence of the interest of the community on
SPM antipatterns.
In sum, the 22 SPM antipatterns identified in [6]
represent the consolidated list of SPM
malpractices that we worked with. They are
described in Table 3.

Table 3. Consolidated list of SPM Antipatterns [6]

Anti-pattern Name Description
Absentee manager Manager who engages in avoidance behavior or is unavailable for long periods of time
One-dimensional management, where the same techniques are used on all subordinates
All you have is hammer
and in all situations
False assumption that a group of people selected by management will immediately gel
Appointed team
and become a team
Excessive planning leading to complex schedules with high level of detail, giving the false
Detailitis Plan
perception that the project is fully under control
Specifying stringent skill and knowledge requirements for a job when it is not strictly
Dry waterhole
necessary, resulting in a very limited pool of available talent
Fire drill Months of boredom followed by demands for immediate delivery
Glass case plan Lack of tracking and updating of initial plans, assuming the plan is enough
Inflexible plan Lack of flexible plans and processes
Irrational management can be viewed as a skewed set of actions where the manager’s
Irrational management
personal priorities, guide the software project in irrational directions.
Leader not manager Manager with a vision (leader) but no plan or management methodology
Micro-management Excessive management involvement in tasks beyond their responsibility
Isolating developers from end users, under the mistaken assumption that requirements
Mushroom
are stable and well-understood by both end users and the software team at project
management
inception
Myopic delivery Management insisting on original delivery date even when reducing staff or funding
Process disintegration Failing processes due to an underlying decline in overall cooperation and morale
Project Lack of proper software project monitoring and controlling
mismanagement
Proletariat hero False assumption that coercion is an efficient way to increase productivity
Rising upstart Superstars who cannot wait their time and want to skip learning phases
Road to nowhere Lack of planning
Assuming developers are interchangeable and that the number of people working on a
Size isn’t everything
problem is inversely proportional to development time
The brawl Project manager with no leadership or management experience
The domino effect Moving critical resources between projects, blurring project boundaries
Ultimate weapon Relying heavily on a superstar in the team

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

RELATIONSHIP BETWEEN AGILE PRACTICES this situation in 35% of the combinations. An

AND SPM ANTIPATTERNS example of this is Sprint Planning/Rising
upstarts. Rising upstarts are people who
The effect of each agile practice on the imprudently try to promote their
antipatterns (in total 330 combinations, 15 agile professional skills. They try to stand out
practices over 22 antipatterns) is shown in Table because they are potentially able to
4. The most relevant issues are discussed below perform more activities than others. During
(the detailed rationale for each of the 330 cases, sprint planning sessions, the team estimates
is provided in [11]). and distributes the tasks to be performed so
Agile practices might have different effects on it can be easy to identify people with this
antipatterns which have been represented with profile, trying to overload themselves with
different icons in Table 4: activities to perform during the sprint.
 The agile practice does not directly help to
 Applying an agile practice can contribute to reduce the impact nor help to identify the
reducing the impact of a particular SPM risk associated with the antipattern ( ).
anti-pattern ( ). This means, either the Around 22% of the combinations fall into
negative effect of the antipattern can be this category. One example is Sprint Review
diminished when applying a particular agile with antipatterns like All you have is a
practice; or the application of the agile hammer, Appointed team or Detailitis Plan.
practice avoids that antipattern. This is the The objective of Sprint Review is to present
most common situation as it occurs in 42% the working software developed during the
of the combinations. One example is the sprint to the PO or customers, so it does not
Daily Meeting/Absentee manager pair. Daily have any direct relationship with the
meetings require the presence of all team monotonous behavior of the project
members including the project manager. manager, lack of practices for team
Problems may arise during these daily cohesion or possible detailed plans,
meetings requiring the need for actions respectively.
from the project manager, forcing her to  Implementing an agile practice might
make decisions. Other cases where this aggravate or contribute to the existence of a
practice has a positive effect include
particular antipattern ( ). This situation
Frequent releases/Fire Drill. Frequent
has been identified only with the Single
releases promote delivering working and
Team agile practice representing 1% of the
valuable software to the client constantly,
combinations. Single team allows that, at
avoiding idle times and the postponement
least in theory, each team member be able
of work to late in the project.
to take any role irrespective of his main skill
 Applying an agile practice may not help to
set. But, having a multidisciplinary team
negate an antipattern, but can help to
does not mean that team members could be
identify the symptoms of the malpractice so
moved to other projects or activities outside
the agile practitioners can be aware of the
the project, assuming that other team
potential risk and take corresponding
members will be able to perform their tasks
corrective actions ( ). Table 3 identifies (Domino Effect antipattern). Other harmful

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software
combinations of this agile practice have
been identified with the Myopic Delivery or
Dry Waterhole antipatterns, which will be
discussed later.
Table 4 was created through detailed analysis
and discussion among the authors according to
the definition of agile practices and antipatterns
provided in Table 2 and Table 3, respectively; and
the evidence gathered from our experience in
the software industry for more than 40 years in
software project management and consulting
with firms ranging from high technology startups
and business management to large multi-
national corporations. Additionally, we surveyed
a total of 30 agile practitioners through face to
face interviews to discuss the matching results.
The interviewed practitioners came from a wide
range of domains (banking, stock market,
transport, e-health and education). They are
geographically distributed in North America,
South America and Europe, have a mean number
of six years of experience in Agile, and more than
80% of them are certified as Scrum Masters. We
surveyed 30 professionals as this number is used
in empirical studies in software engineering to
have a representative sample [15].
Unstructured interviews were used to discuss
the matching. This matching was distributed in
advance to the participants and later the face to
face interviews were set for about one hour. In
the first, round, we interviewed ten participants
that contributed to consolidate the first version
0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded
of the matching mainly providing a better
rationale for specific combinations. Later this
matching was used for the interviews with the
rest of participants. Interviews discussed the
details of the Agile/SMP antipatterns mapping,
and the potential benefits of the results for the
industry.
Regarding the Agile/SPM relationship, personal
experience of each interviewee had a relevant
impact of the interpretation of each
combination. Even if a consensus was reached, it
was clear that although keeping its essence, each
agile practice can be implemented and adapted
in different ways by different organizations, or
even by different projects in the same
organization. Consequently, the matching
process might provide slightly different results
for different organizations. Regarding specific
combinations, interestingly, six participants,
explicitly recognized the negative effects of
Single team and Domino Effect inside their own
organizations.
Regarding the potential benefits, interviewees
highlighted the idea of the matching to put on
the table potential SPM issues and explicitly
discuss how Agile can contribute to address
them. More than half of the participants
explicitly highlighted the need for commitment
and support from the management in the
transitioning process and how these results
could contribute in that direction.
information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/MS.2020.3001030, IEEE Software

Table 4. Relationship between agile practices and SPM antipatterns

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

Figure 1 quantifies the effect of each agile
practice on the antipatterns. Sprint planning
followed by Planning poker and Agile UX are the
agile practices that contribute to address the
highest number of antipatterns (15, 13 and 13,
respectively). Among them Fire Drill, Mushroom
Management or Myopic Delivery have special
negative implications on the customer and
therefore should be carefully considered [6].
Other antipatterns that these practices address
are Detailitis Plan, Process Disintegration or
Project Mismanagement which according to [6]
have an important effect on developers and the
project manager itself. Therefore, the previous
agile practices might be good candidates to be
incorporated early in an Agile transition process.
However, the specific impact, including possible
collateral harm, of each SPM malpractice in an
organization or even project, should be carefully
analyzed to evaluate the criticality of each
malpractice. This information, along with its
implementation cost should be part of the
decision making process about adopting an agile
practice. In this sense, it is worth mentioning
Agile UX, which addresses multiple antipatterns,
but according to [10], is the least used agile
practice. Its implementation is costly and has
important implications in the agile process itself
as well as the team.

18

16
Number of SPM antipatterns

14

12

10

Contribute to solve the antipattern Contribute to identify the antipattern

Not directly related to the antipattern Might contribute to the antipattern

Figure 1. Number of Antipatterns addressed by Agile Practice

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

Retrospectives is the agile practice that most impact on solving SPM risk scenarios does not
contributes to identifying SPM malpractices. It is mean that it will contribute less to the success of
aimed at reviewing the whole development the project. For example, Available product
process in searching problems and potential owner has low direct impact on SPM
improvements. Consequently, in the case of SPM malpractices. However it is essential from the
problems, retrospectives is the place where they requirements perspective and therefore, for
should come out. Additionally, Retrospectives project success.
help to reduce the impact of a few antipatterns,
Absentee Manager, All you Have is Hammer,
PRACTICAL IMPLICATIONS AND FINAL
Appointed Team and Process Disintegration. So, REMARKS
in general it has a positive effect over all SPM Project management malpractices need to be
malpractices. This practice can be implemented brought to surface, discussed and addressed.
with low cost and therefore is a good candidate Table 4 can be used to identify agile practices
to be incorporated in the first phases of an agile which can be useful to address most relevant
transition. In fact, it is one of the most used agile SPM problems. But each organization is
practices [10]. responsible of determining the negative effects
An unexpected result was the possible negative that particular SPM malpractices have on its
contribution of a specific agile practice, Single business value and consequently the risk
team. We have already mentioned the associated. The decision of whether to
combination Single team/Domino Effect. This incorporate an agile practice in a software
practice can also have other negative effects, for development process is a tradeoff between
example wrongly assuming that having a team different variables, among them, its ability to
where members can take different roles allows address the most harmful and frequent SPM
setting a fixed delivery date (Myopic Delivery) as malpractices and the cost of their
multidisciplinary teams will be able to recover implementation.
the work. Additionally, the idea that team We do not mean that one practice will solve a
members need to be able to perform any kind of particular anti-pattern. Most generally, the
technical activity, might raise the expectations of implementation of several practices working
the organization defining very strict altogether are needed for this purpose. Again
requirements and incrementing the effects of each organization, needs to monitor the process
the Dry waterhole antipattern, resulting in a very and take the corresponding corrective actions, if
limited pool of available talent. Even when the needed.
application of this agile practice has recognized
positive effects and it is an essential element of Finally, this paper discusses the link between
the agile philosophy, the case of these Agile and SPM malpractices, providing
combinations represents possible risky situations organizations a preliminary mapping between
that should be carefully considered. them, which might need to be adapted according
to each organization’s specifics. This information
In this study we are focusing on agile practices can provide decision support in an agile
and their potential effect on SPM malpractices, transition process. However, the adoption of
but the fact that one agile practice can have less agile practices will not free agile teams of SPM

10

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

problems. Other problematic scenarios, related 2017

to the appearance of specific agile SPM [10] VersionOne, “12th Annual State of Agile
antipatterns might arise and would need to be Development Report,” in 12th Annual
considered consequently. State of Agile Development Survey, 2018.
[11] G. Castro Flores. Agile Practices as
ACKNOWLEDGEMENTS Solutions for Software Project
Special thanks to the practitioners that Management Anti-patterns. European
participated in the interviews. Master on Software Engineering. Master
Thesis. Universidad Politécnica de
REFERENCES Madrid, 2019. http://oa.upm.es/55665/
[1] J. Gulla. “Seven Reasons IT Projects Fail,” [12] K. Petersen, S. Vakkalanka, and L.
IBM Systems Magazine, February, 2012. Kuzniarz, “Guidelines for conducting
[2] D. Garvin. “How Google Sold Its Engineers systematic mapping studies in software
on Management,” Harvard Business engineering: An update,” Information and
Review, December, 2013 Software Technology, vol. 64, pp. 1–18,
[3] Brooks, F. The Mythical Man-Month: 2015.
Essays on Software Engineering. Reading, [13] https://sourcemaking.com/antipatterns/
MA: Addison-Wesley, 1979. death-by-planning (visited April 2020)
[4] W.J Brown, H.W. McCormick, S.W. [14] https://dzone.com/articles/5-common-
Thomas, S.W. AntiPatterns in Project antipatterns-software (visited April 2020)
Management. New York, NY: John Wiley [15] N. Juristo, A.M. Moreno. Basics of
& Sons, 2000. Software Engineering Experimentation.
[5] I. Stamelos "Software Project Springer-Verlag, 2nd Ed. 2011.
Managament Antipatterns", Journal of
Systems and Software, vol 83 (1), 2010.
Short Bio
[6] P. Silva, A. Moreno, and L. Peters,
“Software Project Management, Learning Gabriela Castro Flores is a Project Administrator
from Our Mistakes,” IEEE Software, vol. in netLogistik, with a MSc in Software
21, pp. 12–15, 2014. Engineering from Universidad Politécnica de
[7] B Murphy et al. "Have Agile Techniques
Madrid and a BSc in Computer Science from
been the Silver Bullet for Software
Instituto Politécnico Nacional, Mexico. She has
Development at Microsoft?"
International Symposium on Empirical experience on testing and software usability
Software Engineering and Measurement, applied on agile schemes. Contact her at
2013. gabriela.castro@netlogistik.com.
[8] K. Petersen, C. Wohlin. "A comparison of
issues and advantages in agile and Ana M. Moreno is full professor of Software
incremental development between state Engineering at the Universidad Politécnica de
of the art and an industrial case. Journal Madrid. She has wide-ranging research and
of Systems and Software, 82(9), pp. 1479– practical experience as an agile consultant.
1490, 2009. Contact her at ammoreno@fi.upm.es.
[9] R- Hoda, R. Noble. Becoming Agile: A
Grounded Theory of Agile. Internatioal
Conference on Software Engineering,

11

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/MS.2020.3001030, IEEE Software

Lawrence Peters is a part time lecturer at The

Universidad Politécnica de Madrid, Iowa State
University and software project management
consultant. He has a PhD in Engineering
Management, he is CSDP and has more than 40
years’ experience in software project
management as well as consulting in different
sectors. He can be contacted at
ljpeters42@gmail.com.

12

0740-7459 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more
Authorized licensed use limited to: University of Exeter. Downloaded information.
on June 22,2020 at 16:52:52 UTC from IEEE Xplore. Restrictions apply.