The document discusses agile software project management methodologies. It presents the main characteristics of agile approaches like Extreme Programming (XP), Scrum, Crystal, and Microsoft Solution Framework (MSF) for Agile Software Development. These methodologies focus on people over processes, collaboration over contracts, responding to change, and producing working software. The document compares methodology components and outlines the principles and practices of some popular agile methodologies.

1. Economy Informatics, 1-4/2005 27
Agile Software Project Management Methodologies
Prof. Constanţa-Nicoleta BODEA, PhD
Economic Informatics Department, Academy of Economic Studies, Bucharest
Successfully project planning, coordinating and controlling in order to deal effectively with
projects sponsors, customers, unexpected risks and changing scope are difficult tasks even for
the most experienced project managers. Different surveys indicated that about half of the
software projects were considered total failures and only a few of them were successful. The
tight deadlines, volatile requirements and emerging technologies are the main reasons for
this lake of performance. This agile project environment requires an agile project manage-
ment. The paper presents the main characteristics of the agile software project management
approaches such as: MSF for Agile Software Development, Extreme Programming, Scrum,
Crystal, Feature Driven Development, DSDM.
Keywords: software development, project management methodology, agile project manage-
ment, XP, MSF for Agile Software Development.
able and more efficient. We can consider a
1 Software project management meth-
odologies
Methodologies impose a disciplined process
methodology containing ten basic elements:
techniques, tools, deliverables, teams, roles,
upon software development with the aim of skills, activities standards, quality measures
making software development more predict- and project values [1].
Activities Milestones
Planning
Testing Team Values
Quality Processes Teams
Regression tests Project manager
Object model Analyst
MBWA
Project plan Use cases Designer
Use cases CRC cards Tester
Deliverable
Techniques Roles
Envy/Dev. JAD facilitation
Microsoft Project Java programming
UML/ C++ STP Modeling
MS Project
OMT Personality
Standards
Tools Skills
Fig. 1. Components of a project management methodology
A specific methodology is needed depending mized quality. A larger methodology (with
on the project size (number of people being more control elements) is needed when more
coordinated), the criticality of the systems people are involved. Communication load
being created and the priorities of the project. raises as the number of people involved in-
For any point in the size/criticality space, a creases. Since methodology is a matter of
scope of concerns to address is selected coordinating the people and managing the
(which project roles, activities, deliverables, communication, its size must also rise, as the
and standards to cover) and optimization cri- number of roles and deliverables types in-
teria are selected. Methodologies therefore crease [2].
differ by the size, criticality, scope and opti- Considering the project deliverables critical-

2. 28 Economy Informatics, 1-4/2005
ity the following four zones we can identify: problem than a large team. It does mean
• Loss of comfort means that with a system there may be an area of overlap, where a
failure, people will have to go and do more small team with a light methodology can
work by hand, or call each other and repair a solve the same problem as a larger team with
miscommunication. Examples might include a heavier methodology (figure 2).
purchase support systems and corporate in- 2. The Agile Approach
frastructure programs. The agile approach started in 1994 with some
• Loss of discretionary moneys zone if the trials of semi-formal agile methodologies,
loss of money or related valuables is merely such as RAD, DSDM, XP, Crystal, Scrum.
uncomfortable These methodologies are based on agile
• Loss of irreplaceable moneys zone if the methods. Agile methods are adaptive rather
loss of moneys or related valuables has effect than predictive. Engineering methods tend to
corresponding to going bankrupt. try to plan out a large part of the software
• Loss of life zone if people are likely to die process in great detail for a long span of
from a system malfunction. time, this works well until things change. So
For a project with higher criticality more their nature is to resist change. The agile
visible correctness (greater density) is re- methods, however, are waiting for change.
quired. Density means more precision in the Agile methods are people-oriented rather
artifacts, with tighter reviews and less toler- than process-oriented. The goal of engineer-
ance. ing methods is to define a process that will
work well whoever happens to be using it.
Agile methods assert that no process will
ever make up the skill of the development
team, so the role of a process is to support the
development team in their work.
The declaration of principles and values in
the agile approach is known as the Agile
Software Development Manifesto, launched
in 2001, after a two day workshop at Snow-
bird Utah (figure 3). A non-profit organiza-
tion the Agile Alliance was set up to promote
Fig. 2. Methodology weight and problem knowledge and discussion of all the agile
size methods.
"Weight is cost": a relatively small increase Applying these principles creates the founda-
in methodology size or specific density adds tion for managing IT projects in an agile ap-
a relatively large amount to the cost of the proach. The basic characteristics of this ap-
project. With fewer people, less methodology proach are the following:
is needed; with less methodology, the people • Assume simplicity. As the project evolves
work more efficiently. Working more effi- it should be assumed that the simplest solu-
ciently, they can successfully address a larger tion is the best solution. Overbuilding the
problem. When more people are put onto a system or any artifact of the project must be
project, they need a heavier methodology to avoided.
coordinate their work. The heavier method- • Embrace change. Since The stakeholder
ology lowers their productivity, so more peo- understanding of the requirements will
ple are needed on the project. Since method- change over time. Project stakeholders them-
ology size grows slower than project size, selves may change as the project makes pro-
eventually they get to a point where they can gress. Project stakeholders may change their
solve the problem and manage the coordina- point of view, which in turn will change the
tion activities. This does not mean that a goals and success criteria of the project man-
small team can necessarily solve a larger agement effort.

3. Economy Informatics, 1-4/2005 29
• Incremental change – the pressure to get it time. Or simply discard it when you no
right the first time can overwhelm the best longer need it in an incremental manner.
project manager. Instead of futilely trying to • Maximize stakeholder value. The project
develop an all encompassing project plan stakeholders are investing resources (time,
from the start, put a stake in the ground by money, facilities) to have a system deployed
developing a small portion of the system, or that meets their needs. Stakeholders expect
even a high–level model of a larger portion that their investment to be applied in the best
of the system, and evolves this portion over way.
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
: Individuals and interactions over Processes and Tools.
: Working software over Comprehensive documentation.
: Customer collaboration over Contract negotiation.
: Responding to change over Following a plan.
That is, while there is value in the items on the right, we value the items on the left more.”
Fig. 3. Agile Software Development Manifesto
• Manage with a purpose Identify a valid the project stakeholders. The goal is not to
purpose for creating the artifact and the audi- produce extraneous documentation, man-
ence for that artifact. This principle also ap- agement artifacts or models of these artifacts.
plies to a change to existing artifacts. 3. Some Agile Software Project Manage-
• Rapid feedback. The time between an ac- ment Methodologies
tion and the feedback on that action must be The agile approach focuses on: talent & skill
minimized. Work closely with the stake- (fewer better people), proximity (direct and
holders, to understand the requirements, to face-to-face communication), less paper,
analyze those requirements, and develop an more tacit / verbal communication, just-in-
actionable plan, which provides numerous time requirements and design, frequent De-
opportunities for feedback. livery (incremental development), reflection,
• Working software is the primary goal of quality in work. So, the people are very close
the project. The goal of any software project related to the agile methodologies (figure 4).
is to produce software that meets the needs of
Activities Milestones
Personality
Planning
Testing Team Values
Quality Processes Teams
People
Regression tests Project manager
Object model Analyst
MBWA
Project plan Designer
Use cases
Use cases CRC cards Tester
Deliverable
s Techniques Roles
Envy/Dev. JAD facilitation
Microsoft Project Java programming
UML/ C++ STP Modeling
MS Project
OMT
Standards
Tools Skills
Fig. 4. Components of an agile project management methodology

4. 30 Economy Informatics, 1-4/2005
3.1 Extreme Programming (XP) method- jects require different kinds of methodolo-
ology gies. The Crystals share a human orientation
The roots of XP lie in the Smalltalk commu- with XP, but this people-centeredness is done
nity, in the close collaboration of Kent Beck in a different way. Alistair considers that
and Ward Cunningham in the late 1980's. people find it hard to follow a disciplined
Both of them refined their practices on nu- process, thus rather than follow XP's high
merous projects during the early 90's, extend- discipline; Alistair explores the least disci-
ing their ideas of a software development ap- plined methodology that could still succeed,
proach that was both adaptive and people- consciously trading off productivity for ease
oriented. The crucial step from informal of execution. He thus considers that although
practice to a methodology occurred in the Crystal is less productive than XP, more
spring of 1996. Kent was asked to review the people will be able to follow it.
progress of the C3 payroll project for Chrys- Alistair also puts a lot of weight in end of it-
ler. The project was being carried out in eration reviews, thus encouraging the process
Smalltalk by a contracting company and was to be self-improving. His assertion is that it-
in trouble. Due to the low quality of the code erative development is there to find problems
base, Kent recommended throwing out the early, and then to enable people to correct
entire code base and starting from scratch. them. This places more emphasis on people
The project then restarted under his leader- monitoring their process and tuning it as they
ship. XP begins with four values: Communi- develop.
cation, Feedback, Simplicity, and Courage. It 3.3 Scrum
then builds up to a dozen practices which XP Scrum has been around for a while in object-
projects should follow. Many of these prac- oriented circles. It focuses on the fact that de-
tices are old, tried and tested techniques, yet fined and repeatable processes only work for
often forgotten by many, including most tackling defined and repeatable problems
planned processes. As well as resurrecting with defined and repeatable people in defined
these techniques, XP weaves them into a and repeatable environments.
synergistic whole where each one is rein- Scrum divides a project into iterations (which
forced by the others. It is a strong emphasis they call sprints) of 30 days. Before you be-
on testing. While all processes mention test- gin a sprint you define the functionality re-
ing, most do so with a pretty low emphasis. quired for that sprint and then leave the team
However XP puts testing at the foundation of to deliver it. The point is to stabilize the re-
development, with every programmer writing quirements during the sprint.
tests as they write their production code. The However management does not disengage
tests are integrated into a continuous integra- during the sprint. Every day the team holds a
tion and build process which yields a highly short (fifteen minute) meeting, called a
stable platform for future development. scrum, where the team runs through what it
On this platform XP builds an evolutionary will do in the next day. In particular they sur-
design process that relies on refactoring a face to the management blocks: impediments
simple base system with every iteration. All to progress that are getting in the way that
design is centered on the current iteration management needs to resolve. They also re-
with no design done for anticipated future port on what's been done so management
needs. The result is a design process that is gets a daily update of where the project is.
disciplined, yet startling, combining disci- Scrum literature focuses mainly on the itera-
pline with adaptivity in a way that arguably tive planning and tracking process. It's very
makes it the most well developed of all the close to the other agile in many respects and
adaptive methodologies. should work well with the coding practices
3.2 Crystal methodologies from XP.
Alistair developed this family of methodolo- 3.4 MSF for Agile Software Development
gies considering that different kinds of pro- MSF provides a customized and scalable set

5. Economy Informatics, 1-4/2005 31
of software development guidelines for ap- • Source check-in policies
plication development improvement ([5]). • Role clusters and security groups
MSF incorporates both agile and formal ap- • Document templates (Excel and Word)
proaches, and then allows the user to select • Microsoft Project templates
the most suitable path. MSF's flexible • Reports
framework can be adapted to meet the needs • Project portal /SharePoint site template
of any project, regardless of size or complex- MSF uses methodology templates to define
ity. the process that individual projects follow.
The MSF philosophy holds that there is no There is no universal process that works for
single structure or process that optimally ap- all organizations, or even all projects within
plies to the requirements and environments an organization. To address this, MSF pro-
for all projects. MSF provides this guidance vides a flexible toolset that works with both
without imposing prescriptive detail and al- agile and formal processes. Microsoft's
lows the user to customize the content pro- Global Solution Integrator partners provide
vided. MSF components can be applied indi- their own product consumable methodology
vidually or collectively to improve success templates; or, you can create your own. Proc-
rates for the many types of projects. MSF ess extensibility allows customization of
guidance focuses on managing the "people work item types, check-in policies, custom
and process." Because the needs and prac- reports and project management templates.
tices of software development teams are con-
stantly evolving, the materials gathered into Conclusions
MSF are continually changing and expanding Getting projects faster is a universal desire of
to keep pace. Additionally, MSF interacts management. The reality of project manage-
with Microsoft Operations Framework ment is that we never really have the time to
(MOF) to provide a smooth transition to the create perfect plans, to analyze all the op-
operational environment, which is a require- tions. Agile approach provides some methods
ment for long-term project success. for project management to become more ef-
With MSF, process is not just documenta- fective. These methods need to be taken and
tion. It also manifests itself as actual tool be- customized to the unique business environ-
havior changes. When you chose the process ment of the project.
at project inception, you are also choosing
the workflow and work products, which then References
drive how the system behaves. Support for 1. Alistair C. A Methodology Per Project,
the software development life cycle process (arc@acm.org), Humans and Technology.
(SDLC) is built-in, which makes for seamless 2. Harrison, N., Coplien, J, "Patterns of pro-
workflow support. By integrating process ductive software organizations", Bell Labs
into the tools team members use on a daily Technical Journal, summer, 1996.
basis, MSF lowers the barrier to adopting 3. Jeffries, R., Beck, K., Extreme Program-
process and enables the automatic collection ming, http://armaties.com/extreme.html.
of cross-functional project metrics without 4. Fowler M, The New Methodology, Martin
the overhead associated with manual report- Fowler.com
ing. 5. Microsoft, Visual Studio 2005 Team Sys-
The following elements of MSF are custom- tem: Microsoft Solutions Framework, 2004,
izable: www.Microsoft.com .
• Process Guidance 6. http://crystalmethodologies.org/
• Iteration structure
• Entry criteria and exit criteria views
• Work item type definitions and rules (ac-
tivities and work products)
• Work item queries