168
A Review of Agile Practices for Project
Management
Vira Liubchenko
System Software Department
Odessa National Polytechnic University
Odessa, Ukraine
1 Shevchenko av., Odessa, 65044
AbstractThe work is concerning the application of
agile software development practices in agile project
management. Firstly, we describe the agile project
management framework. After that, we analyze practices of
Scrum and Lean Development on aspects of management,
communication and decision-making support. Finally, we
propose the form of rational involvement of the practices
into agile project management framework.
Keywordsagile; project management; software
development; Scrum; Lean development
I. INTRODUCTION
The business environment is becoming more quickly,
changeable and unpredictable. In industry after industry,
customer demands continuous innovation, and the
plunging cost of experimentation are signaling a massive
switch from anticipatory to adaptive styles of
development. Companies trying to thrive in our turbulent
economy must alter both their processes and their
perspectives on change. We are talking about everything
changing scope, features, technology, architecture
within the span of a few months. Agility is the ability to
both create and respond to change to profit in a turbulent
business environment [1].
In an uncertain and chaotic world, success belongs to
companies that have the capacity to create change, and
maybe even chaos, for their competitors. Creating change
requires innovation. Complexity theory tells us that
innovation creating something new in ways that we
cannot fully expect, a new result occurs most readily at
the balance point between chaos and order, flexibility and
stability. Balancing at the edge of chaos between flexibility
and stability requires particular project management
methods and practices based on experiments [2].
Project management processes and performance
measures are different for exploration- and
experimentation-based approaches than they are for pro-
duction- and specification-based ones. Production-oriented
project management processes and practices emphasize
complete early planning and requirements specification
with minimal ongoing change. Exploration-based
processes emphasize nominal early planning, good
enough requirements and experimental design with
CSIT 2016, 06-10 September, 2016, Lviv, Ukraine
significant ongoing learning and change. Each approach
has its place, but the lifecycle framework for the latter has
a very different flavor from the former. The agile project
management (APM) framework consists of five stages:
Envision, Speculate, Explore, Adapt, and Close [3].
These stages resemble a scientific investigative
process more than a production management process. The
Envision phase results in a well-articulated business or
product vision enough to keep the next stages bounded.
In the Speculate phase, the team hypothesizes about the
specifications of the product, knowing that as the project
continues both technology and customer specifications
will evolve as new knowledge is gained. The Explore
phase then becomes a parallel and iterative operation in
which the preliminary specifications and design are
implemented. Components labeled "uncertain" are subject
to more experimentation than others, whose specifications
or design are more precise. In the Adapt phase, the results
of these experiments are subjected to technical, customer,
and business case review and adaptive actions are
incorporated into the next iteration.
As we can see, APM is the general framework that
does not recommend any practice for exploitation. Jim
Highsmith says that being Agile means being able to
Deliver quickly. Change quickly. Change often [4].
While Agile techniques vary in practices and emphasis,
they share common characteristics, including iterative
development and a focus on interaction, communication,
and the reduction of resource-intensive intermediate
artifacts. So that we can try to transfer the agile practices
from well-defined industrial Agile methods to the project
management domain.
The article aims to analyze and structure the agile
practices from software engineering domain to introduce
agility to the project management activities.
II. AGILE PRACTICES IN SOFTWARE ENGINEERING
In software engineering, Agile methods were a
reaction to traditional ways of developing software and
acknowledge the "need for an alternative to
documentation driven, heavyweight software development
processes" [5]. Practitioners came to understand that
method that would respond to change as quickly as it arose
 169

were necessary and that in a dynamic environment, bringing new people up to speed. By providing
"creativity, not full written rules, is the only way to comprehensive, up-to-date documentation, any stakeholder
manage complex software development problems" [6]. can learn about their respective interests in the system. The
practice dictates that documentation should be produced
Agile methods were gaining popularity in the industry, and kept up to date not only for code but also for
although they include a mix of accepted and controversial requirements and Release planning. The provided
software engineering practices. The three most important documentation helps guide the PM.
success factors for them are culture, people, and communi-
cation. Agile methods need cultural support; otherwise, SP6 assist the PM gauge requirements, functionality,
they will not succeed. Competent team members are risk and plan iterations. The practice provides a means
crucial. Agile methods usually use fewer more competent through which Customers, PMs, and Developers
people. Physically co-located teams support rapid collaborate to plan iterations. Iterative Controls help guide
communication. Close interaction with the customer and the PM on release planning decisions.
frequent customer feedback are critical success factors.
SP7 is a management philosophy placing emphasis on
Agile methods in software engineering have much in usability and correctness of the system rather than strict
common, such as what they value, but they also differ in feature growth. This ability affects what kind of features or
the practices they suggest. In this article, we will examine fixes are incorporated into the next release, and also
Scrum and Lean Development as representative of the changes the mentality with which the PM manages the
group of managerial methods. We address our attention to project.
the following project aspects: management support,
Table I generalizes the issue (Y stands for Yes, and N
communications support, and decision-making support.
for No).
A. Scrum TABLE I. ANALYZE OF SCRUM PRACTICES
Scrum is one of the more widely used Agile methods.
Ken Schwaber first described Scrum in 1996 as a process Type of Practices
that accepts that the development process is support SP1 SP2 SP3 SP4 SP5 SP6 SP7
unpredictable, formalizing the do what it takes Manage-
mentality, and has found success with numerous ment Y Y Y Y Y Y Y
independent software vendors [7]. support
Communication support
The core practices analyzed in the article are Small
Developer-
Teams (SP1), Frequent Builds (SP2), Low-Coupling Customer
Y No N/a N/a Y Y N/a
Packets (SP3), Constant Testing (SP4), Constant Developer-
Y Y N N Y Y N/a
Documentation (SP5), Iterative Controls (SP6), and Ability Developer
Developer-
to declare the project done at any time (SP7). PM
Y Y Y Y Y Y N/a

SP1 recommends the team size up to seven persons. It Decision-making support

means Project Manager (PM) has to manage and distribute Release
Y Y N N Y Y Y
work between teams and team leaders. Small Teams help planning
Design and
break down communications barriers, allowing easy, in- Develop- Y Y Y Y Y N N
formal communication between all parties in the teams ment
(Developers, PM, and Customer). Small Teams make all Project
Manage- Y Y N N Y Y Y
levels of decision-making easier by involving a smaller ment
number of individuals on lower level decisions.
B. Lean Development
SP2 recommends providing the construction of
executables that can be inspected, adjusted, tested, Lean Development (LD), started by Bob Charette,
documented, and built on, frequently on the regular base. draws on the success Lean Manufacturing found in the
Frequent Builds allows PM to see the state of the system at automotive industry in the 1980s. While other Agile
any given time to track progress. This practice enables methods look to change the development process, Charette
Developers to communicate the status of the system with believes that to be truly Agile you need to change how
other Developers and PM at any time, as well as helps PM companies work from the top down. Lean Developments
plan and monitor Releases and Development. 12 principles focus on management strategies [8], but three
of them are concerning the development support. Because
SP3 recommends partitioning of work and team of this reason we analyze 9 of 12 principles: satisfying the
assignments into clean, low coupling partitions, or packets. Customer is the highest priority (AP1), always provide the
Low Coupling Packets influences how PM distribute work, Best Value for the money (AP2), success depends on
reduce the need for technical communications between active Customer Participation (AP3), every LD project is a
Developers, and help guide Design decisions. Team Effort (AP4), Everything is Changeable (AP5), an
SP4 provides the PM with a system he/she can demo or 80 percent solution today instead of 100 percent solution
ship at any time and allows Developers to know the current tomorrow (AP6), Minimalism is Essential (AP7), Needs
state of the system at any point in time. Determine Technology (AP8), and product growth is
Feature Growth not size growth (AP9).
SP5 provides an up-to-date snapshot of the system and
AP1 postulates the PM needs to change his/her frame
its progress, the PM can use them for tracking or for
of mind to make Customer satisfaction the highest priority,

CSIT 2016, 06-10 September, 2016, Lviv, Ukraine

 170

as opposed to budget, politics, and other concerns. TABLE II. ANALYZE OF LEAN SOFTWARE DEVELOPMENT
PRINCIPLES
Ensuring Customer satisfaction entails enhanced
communication between the Developers and Customers. Principles
Prioritizing Customer satisfaction means that during Type of
Release planning, Design and Development, and Project support

AP1

AP2

AP3

AP4

AP5

AP6

AP7

AP8

AP9
Management, the interest of the Customer may have to be
Manage
put before that of the team. ment Y Y Y Y N Y Y N N
support
AP2 postulates the PM needs to manage the project
Communication support
with the goal to build and prioritize the system to provide
the best value for the money. Providing the best value for Dev-
Y No Y Y N N/a N/a N/a N/a
Custom
the money is a management philosophy, it affects on what
Dev-Dev N N N/a Y N/a N/a N N/a N/a
requirements are prioritized for what release.
Dev-PM N/a N/a N/a Y N N/a N/a N/a N/a
AP3 points that it becomes the PMs responsibility to
keep the Customer participating in the project. Active Decision-making support
Customer participation gives customers more incentive to Release Y Y Y N/a Y Y N N/a Y
work with the Developers. Active Customer participation planning
provides decision support for PMs and is also Design Y N N/a N Y Y N Y N
and
instrumental in prioritizing release features. Develop
ment
AP4 postulates the PM needs to include the entire team Project Y Y Y N/a N Y Y Y Y
in decision-making processes. The everything is a Team Manage
ment
Effort philosophy encourages communication between all
Principles of Lean Development are mostly oriented on
members of the team.
the management of product development flow so that they
AP5 points that having the ability to change everything provide the limited possibility for APM. Despite this
means that Release and Design decisions are not set in introducing some principles at particular phases is possible
stone, letting them be made more quickly and changed and can be fruitful. Especially we recommend practicing
later if necessary. AP1, AP4, and AP8 at the Envision phase; AP1, AP2,
AP6 highlights that instead of making everything AP3, AP4, AP7 and AP8 at the Speculate phase; all
perfect, the PM should focus on providing the best system principles except AP8 at the Explore phase; AP1, AP3,
he/she can at the moment. Having an 80% solution today AP4, AP5, AP8 and AP9 at the Adapt phase.
means that, from a Release, Design, and PM perspective, At the end of the article, let us highlight that agile
adding a new feature today is a better decision than engineering practices stayed behind our attention because
completing an old one. of their orientation to software development. Such
AP7 points the PM should focus on keeping team size, practices as pair programming, test-driven design or
code size, documentation, and budget as small as necessary refactoring hardly ever can be adopted for APM
for a successful project. Minimalism also helps a PM framework. However, the learning on the job practice
decide what artifacts to produce during development. could and should be used. It highlights we start with the
best ideas and design we have come up with, but we will
AP8 helps the PM and designers decide on an also assume that we will learn more as we go. So it worth
appropriate solution rather than a high-tech solution for to be used at Explore and Adapt phases.
high-techs sake.
Finally, by emphasizing AP9, releases and PMs tend REFERENCES
to push features more than other requirements. [1] J. Highsmith, Agile Software Development Ecosystems. Addison-
Wesley, 2002, 448 p.
Table II generalizes the issue (Y stands for Yes, and N
[2] C. P. Puri, Agile Management: Feature Driven Development. Global
for No). India Publications Pvt Ltd, 2009, 310 p.
[3] J. Highsmith, Agile Project Management. Creating Innovative
III. CONCLUSION Product. Addison-Wesley, 2004, 304 p.
Comparing Table I with Table II we should point that [4] J. Highsmith, K. Orr, A. Cockburn, Extreme programming, in E-
Business Application Delivery, pp. 4-17, February 2000.
Scrum practices are more reliable for APM than Lean
[5] Manifesto for Agile Software Development, 2001,
Development principles. It is caused by the fact that Scrum http://agilemanifesto.org/
is the managerial method for the development process, all [6] A. Cockburn, J. Highsmith, Agile software development: The business
its practices focused on organizing development process in of innovation, in IEEE Computer, pp. 120-122, September 2001.
such way to meet the changing requirements. Only SP1 [7] K. Schwaber, Controlled chaos: living on the edge, in Cutter IT
can be the restriction for APM. We should stress this issue Journal, March 1996, http://www.scrummanager.net/files/
were analyzed and resolved in software development Living_on_the_Edge.pdf.
practice, Scrum of Scrums tell us a project may consist of [8] M. Poppendieck, T. Poppendieck, Lean Software Development: An
multiple teams that could easily be distributed [9]. Agile Toolkit. Addison-Wesley Professional, 2003, 240 p.
Especially we recommend practicing SP5 at the Envision [9] Sutherland, J., Viktorov, A., Blount, J. and Puntikov, N. Distributed
phase; SP3, SP5 and SP6 at the Speculate phase; SP2, SP3, scrum: Agile project management with outsourced development
teams. Proceedings of the 40th Annual Hawaii International
SP4, SP5, SP6 and SP7 at the Explore phase; SP2, SP5 and Conference on System Sciences, HICSS 2007, pp. 274a-274a.
SP7 at the Adapt phase.

CSIT 2016, 06-10 September, 2016, Lviv, Ukraine