The document discusses agile project management methods in the context of managing information technology projects, emphasizing the industry's need for timely and high-quality software delivery. It explores the shortcomings of traditional heavyweight project management methodologies, advocating for more adaptable and lightweight approaches to meet evolving requirements. The text also highlights the importance of understanding various methodologies and their appropriateness for specific project environments to enhance project success.

1. In: The Story of Managing Projects: A Global, Cross–Disciplinary Collection of Perspectives,
Dr. E. G. Carayannis and Dr. Y. H. Kwak, editors,
Greenwood Press / Quorum Books, 2002
AGILE PROJECT
MANAGEMENT
METHODS
Our nations prosperity depends of
software. The nation’s software
industry depends on the timely
delivery of high quality products to
eager customers. This industry is
slipping further behind in quality and
timely delivery every year. The gap
continues to grow. One question this
book attempts to answer – what approaches to managing information
technology projects can be applied to this problem and others
encountered by organizations dependent on software for their economic
success?
You cannot win in today's marketplace using yesterday's processes.
— Dr. H. James Harrington
Glen B. Alleman
Niwot, Colorado 80503
glen.alleman@niwotridge.com

2. In: The Story of Managing Projects: A Global, Cross–Disciplinary Collection of Perspectives,
Dr. E. G. Carayannis and Dr. Y. H. Kwak, editors,
Greenwood Press / Quorum Books, 2002
Table of Contents 1
Table of Contents
AGILE PROJECT MANAGEMENT METHODS FOR IT PROJECTS................................... 1
Weight Versus Agility................................................................................................................ 2
Some Sobering Facts about IT Projects......................................................................................... 3
The Taxonomy of Methods ..................................................................................................... 4
What Type of Methodology ............................................................................................ 6
Agile Is Not The Same Of Lightweight................................................................................. 7
A Brief History of IT Project Methods.................................................................................. 7
Project Management Framework..................................................................................................... 8
Activities within Framework.................................................................................................... 9
The Methodology Zoo............................................................................................................10
Management Dimensions of Project Management ...........................................................11
The Agile Software Delivery Process.............................................................................................12
Common Problems with All Software Projects .................................................................12
The Problem of Change..........................................................................................................13
Ready For Agility?....................................................................................................................13
The Forces Driving Agility..............................................................................................................14
Practical Agile Project Management..............................................................................................14
Common Threads of These Methods..................................................................................15
Is Agile Yet Another Software Methodology Taxonomy?...............................................16
Project Management Drivers .................................................................................................17
Framework for Agile PM Methods.......................................................................................18
Nine Best Practices ..................................................................................................................19
Management Engagement......................................................................................................20
Applying the Nine Best Practices..........................................................................................21
Agile Project Management Summary............................................................................................24
Values of Agile Project Management ...................................................................................24
Applying Agile Principles in Practice....................................................................................25
Bibliography.......................................................................................................................................28

3. 2 Agile PM Methods
Table of Figures
Figure 1 – Factors Affecting Successful And Unsuccessful Projects................................................ 4
Figure 2 – Business Centric Software Process....................................................................................... 5
Figure 3 – Generic Project Management Activities.............................................................................. 7
Figure 4 – Interrelation Between Project Management Activities ..................................................... 9
Figure 5 – A IT Project Management Framework..............................................................................10
Figure 6 – Management Responsibilities Applied to a General Process ........................................11
Figure 7 – National Software Quality Experiment Results ...............................................................13
Figure 8 – Common Aspects Of All Methods ....................................................................................15
Figure 9 – Software Systems Taxonomy...............................................................................................16
Figure 10 – Tensions On The Software Development Project Manager.......................................18
Figure 11 – Nine Best Practice Principles.............................................................................................20
Figure 12 – Nine Best Practices of a Success Software Project........................................................24

4. Lean PM Methods 1
C h a p t e r X .
AGILE PROJECT MANAGEMENT
METHODS FOR IT PROJECTS
The difference between failure and success is the difference between doing
something almost right and doing something right.
— Benjamin Franklin
Agile project management methodologies used to develop, deploy, or acquire
information technology systems have begun to enter the vocabulary of modern
organizations. Much in the same way lightweight and agile manufacturing or business
management processes have over the past few years. This chapter is about applying
Agile methods to an environment that may be more familiar with high ceremony
project management methods – methods that might be considered heavy weight in
terms of today’s agile vocabulary.
High ceremony projects include projects based on formal or semi–formal project
management methods, ones like Prince2 [1]
, PMI’s PMBOK [2]
, or processes based
on the Software Engineering Institute’s Capability Maturity Model [3]
. These
methods are traditionally associated with organizations which operate in software
engineering centric business domains. These domains view software activities as an
engineering process, rather than a creative process.
Organizations that have mature processes usually define their activities in a formal
manner, apply these methods with some form of rigor, and monitor the processes
and results carefully. These practices have usually been built up over time and come
about through past experiences – either good or bad. They usually represent a
formal structure of the underlying business process.
1 Projects IN Controlled Environments (PRINCE) is a structured project management method used in the
UK.
2 Project Management Body of Knowledge (PMBOK) is an ANSI Standard PMI–99–001–2000 describing the
various attributes of a project management method.
3 Capability Maturity Model is a collection of model frameworks for assessing the maturity of a specific practice.
Key Practice Areas are used to define the various levels of maturity. CMM now consists of: Software, People,
Software Acquisition, Systems Engineering, and Integrated Product Development. This models are supported
by a software process assessment standard ISO/IEC 15504.

5. 2 Agile PM Methods
It is common to talk about Agile methods for modern project management
processes in the context of a set of lightweight activities used to manage the aspects
of software development or acquisition. These are requirements, design, coding,
and testing processes based on a minimal set of activities needed to reach the end
goal – a working software system.
Although some of these agile methods address the management aspects of software
projects – people, processes, and technology – they are primarily focused on
coding, testing, and software artifact delivery. [4]
Applying the concept of agility to the management of software project is a natural
step in the evolution of software development. One important question to be asked
is how can these minimalist approaches be applied to project management problems?
n What project management process simplifications are appropriate in a
specific problem domain?
n Are all light weight and agile project management processes applicable
to all problem domains?
These questions and others will be addressed in this chapter.
Weight Versus Agility
In the information technology project management literature, lightweight is often
defined as not heavyweight, which of course is a tautology. As time went on the term
lightweight was superceded in the popular press by Agile. Lightweight and Agile are not
actually interchangeable words.
Lightweight describes the weightiness of the process and its artifacts. The amount of
potentially non–value added artifacts produced by a specific process. This weightiness
can be attributed to the undesirable consequences of the process – artifacts that
don’t provide benefit to the outcome. This weightiness can also be attributed to the
mis–application of a specific process. Agility describes the behavior of the
participants and their ability to move or adjust.
Much like an overweight boat or airplane, the undesirable weight needs to be
removed in order to increase the efficiency of the vehicle. This is a standard best
practice in many engineering disciplines. One problem with this analogy though is
that those who suggest that a specific process of being over weight must first answer
the question:
4 Some proponents of these lightweight methods contend delivery of software is the only goal. Although this is
an obvious outcome of the programming and integration process, there are many other deliverable artifacts
associated with large scale software projects.

6. Lean PM Methods 3
… if a project management method were properly applied, in the proper
domain, to the proper set of problems, with properly trained participants,
would it be considered overweight and produce undesirable
consequences?
The usual answer is no, of course not. If everyone were doing their job properly in the
proper engineering, regulatory, and contractual environment, then the results would
be accepted by all the participants – this is the definition of a tautology.
So the problem of project management methodology selection is compounded by
the behaviors of the method as well as the behaviors of the participants in the
method. In addition, the appropriateness of the process for a specific problem domain
is also an issue.
Some Sobering Facts about IT Projects
Numerous reports have analyzed why software projects fail. Here’s a summary of
the findings, ranked by importance from high to low, summarized from
[Connolly 96], [Royce 98], [Standish 95], and [Defense 94]:
Before we get too far along in the discussion of Agile processes, it would be good to
recap what the data in Figure 1 means. The majority of the items associated with
both the success and failure of projects are related to the management of the
software process. This includes stakeholder participation, clear requirements from
the stakeholders, stabilizing these requirements, managing the fulfillment of these
requirements, tracking these requirements, and verifying that the requirements have
been fulfilled in some way. One of the tenants of Agile process is that the
requirements will become clear as the project evolves. That changes in these
requirements can be absorbed by the development team, since they are continually
redacting the resulting anyway.
This is the challenge in discussing Agile processes — are these process appropriate
for the general population of software development projects and products, or are
they suited for specialized environments in which the requirements can be
discovered during the development process?

7. 4 Agile PM Methods
Successful Projects Challenged Projects
User Involvement High Lack of user input
Executive sponsorship and support Incomplete requirements
Clear statement of the requirements Changing requirements
Proper planning Lack of executive sponsorship
Realistic stakeholder expectations Technology incompetence
Small project milestones Lack of resources
Competent staff Unrealistic expectations
Stakeholder ownership Unclear objectives
Clear vision and objectives Unrealistic time frames
Focused staff Low New technologies
Figure 1 – Factors Affecting Successful And Unsuccessful Projects
The Taxonomy of Methods
The definition of a software process is embodied in how a software
organization does business, that is, how management and engineering
practices are implemented to support software development and its
maintenance. This view of software process assumes that an organization
has a set of building blocks that defines the general way it does business
and that some subset of those building blocks is implemented for each
software project.
Software Technology Support Center, Hill Air Force Base, Ogden Utah
This business–centric definition of the software process assumes there are two
basic development categories – project centric and product centric. They are both
based on the delivery of some form of value for the stakeholder. However, there
are different forces at work in each category. Understanding the difference between
them is an important factor in choosing a methodology for the delivery of this
value [Nakajima 89].
Project Centric Process Product Centric Process

8. Lean PM Methods 5
Describe and organize the work Specify and create a product
Manage the work of the team in
the delivery of the project
components
Manage the work of the team in
the delivery of the product and
all it’s associated components.
Project Delivery focused Product Lifecycle focused
DELIVERABLE VALUE
Figure 2 – Business Centric Software Process
With these differences in mind, there are sub–tasks that further define project
activities:
n Requirements elicitation – architectural and design artifacts need to be
gathered, reviewed and approved.
n Design – artifacts that describe what software is to be produced as well
as associated documentation, maintenance, installation, and upgrade
processes.
n Programming – computer programs that are developed, delivered, and
maintained.
n Testing – artifacts attesting to the correctness of the code and its
compliance with the requirements.
No matter what a project management method is called, what the method claims to
contribute, and especially no matter what special powers are attributed to the
project management methodology, there are a small number of essential attributes
that any project management method must posses in order to deliver value to the
stakeholders [Blum 94].
n An application domain – in which the problem exists. The generalization
of a project management process must take into account the business
domain. Applying a specific methodology to the wrong domain can
have the same effect as applying the wrong methodology to the right
domain. Both result in some type of failure for the project.
n A conceptual model – that references a formalism in the domain of
interest. These models are descriptive in nature and provide guidelines
for making decisions about the problems encountered in the
application domain.
n A formal model of some kind – establishes the rules for the acceptance
and correctness of the methodology. These models are prescriptive in
nature and describe the steps, actions, outcomes, and relationships
between each of them.

9. 6 Agile PM Methods
n An implementation domain – which provides the means of solving the
problems encountered in the application domain using a conceptual
or formal model of a method.
All this formality is meant to bring light on the fact that any discussion of project
management methodology is complex and fraught with confusing and sometimes
contradicting terms, concepts and claims.
What Type of Methodology
A software project management methodology lives within a greater context of a
business process improvement process. The concepts of generic project
management are usually lost in this modern age of the Internet and Agile process. If
we look back to the origins of successful high technology organizations, one
primary source is The Management of Innovative Technological Organizations [Ramo 80].
The books author, Simon Ramo, is the R in TRW. The processes in this book are
the antithesis of Agile, but the principles are timeless. [5]
n Initiate through some official recognition that a project has been
formed.
n Plan by creating and maintaining a scheme to accomplish the work at
hand.
n Execute through people and resources.
n Control through a means that assures the project objectives are being
met.
n Close the project through some formal acceptance process.
5 These simple concepts are repeated in nearly every textbook on project or business management. The source
fro this list is probably lost. My best source is My Years with General Motors, Alfred P. Sloan Jr., Double Day,
1963. This approach to project methodologies is far from Agile.

10. Lean PM Methods 7
Figure 3 describes how these steps are related to each other. Any process, Agile or
heavyweight, must provide these steps in some form.
Initiating
Planning
Controlling Executing
Closing
Figure 3 – Generic Project Management Activities
Agile Is Not The Same As Lightweight
The term Agile does not directly describe the weightiness of a method or its
artifacts, but rather describes the ability of the method to deal with the external and
internal forces it encounters in the business environment. The methods ability to
deal with these forces in an agile manner. This issue will be developed further but
for now the reader should remember to differentiate between the weight of a
method and its artifacts and the agility of a method to deal with the forces its
encounters during its application.
A Brief History of IT Project Methods
In the 1980’s the development of large business software applications was factory
centric. Large volumes of code were generated by equally large volumes of
programmers. The consequences of this horde approach have been well documented
in [Brooks 95], [Brooks 87]. As early as 1956 the concept of software process entered
the lexicon [Bennington 56]. The discussion of software process improvement has
a long history, with varied results even to this day.
In the last several years, the landscape has changed dramatically on both the
supplier and consumer side of the software development business. Time to market

11. 8 Agile PM Methods
pressures, rapidly changing requirements, the Internet, and new and powerful
programming languages have placed new forces on the traditional software
development organization.
One source of modern process improvement started with Royce’s waterfall model,
[Royce 70]. From this, an interactive enhancement improved on the original waterfall
process [Basili 75]. The mid–1980’s produced several new processes including the
spiral model of Boehm, which evolved from a risk management point of view
[Agresti 86]. Process programming emerged from formal modeling techniques in the
late 80’s [Osterweil 87], [Osterweil 97]. Software process improvements continue to
occupy an important place in research as well as the commercial market place
[Humphrey 99].
The concept of agility has been discussed in detail for the hardware development
domain [Goldman 95]. Similar research and discussion has not taken place in the
same manner in the software domain. This leaves a gap in the academic approach
to the subject. To date this gap has been filled by anecdotal accounts of Agile
processes being applied a variety of development domains, but extensive survey has
not been conducted in any formal manner, nor has a scientific analysis of the agile
process domain been produced.
Project Management Framework
According to [SEI 96] a methodology must posses certain attributes in order to
meet the requirements is being called a methodology. Figure 5 describes the
engineering and development attributes of a methodology as well as the constraints
placed on those attributes. An alternative to [SEI 99] is the Software Engineering
Body of Knowledge [SWEBOK] that contains yet another set of attributes for
development methods to be used by any professional software engineer. For the
moment we’ll focus on the SEI’s description of the software project attributes.
Figure 4 describes how these attributes could be related in an agile project
management method. [Cockburn 99]

12. Lean PM Methods 9
Milestones
Activities Teams
Management
Processes
Management
Methods
Roles
People
Skills
Work
Environment
Tools
Techniques
Products
Quality
Standards
Development
Environment
Figure 4 – Interrelation Between Project Management Activities
Activities within Framework
Another view of this project management framework is the activities that must be
performed in order to satisfy the deliverables of the project. That is delivery
products or projects within the constraints of the project – time, budget, quality,
and features. Figure 5 is a summary of some of these activities.
Performing these activities in an Agile manner becomes a critical success factor for
the project.

13. 10 Agile PM Methods
Figure 5 – A IT Project Management Framework
The Methodology Zoo
There are numerous project management methodologies in use today. Any list of
methods and methodologies must be considered a snapshot of what’s in practice
and in the literature today.
Each of these methods, and the list grows daily, provides some form of process or
steps shown in Figure 3. Such a list is not meant to be of any real use, only to show
Engineering Attributes Development Attributes Development Constraints
Requirements
Describes the stability,
completeness, clarity, validity,
feasibility, precedent, and scale
of the system requirements.
Development Processes
Including formality, suitability,
process control, familiarity,
and product control.
Resources
Including schedule, staff,
budget, and facilities.
Design
Describes the functionality,
difficulty, interfaces,
performance, testability,
physical constraints, and non–
functional aspects of the
system.
Development System
Including capacity, suitability,
usability, familiarity, reliability,
system support, deliverability.
Contract(s)
Including type of contract,
restrictions stated in the
contract, and dependencies
defined by the contract.
Code and Testing
Describes the programming
artifacts and their testability.
Management Processes
Including planning, project
organization, management
experience, and program
management.
Interfaces
Including the customer,
associate contractors and
subcontractors, corporate
management relationships,
vendors, and the all–powerful
political influences.
Integration and Test
Describes the environment,
product, and system behaviors
aspects of the product when it
is in use.
Management Methods
Including monitoring,
personnel management,
quality assurance, and
configuration management.
Specialties
Describes the various abilities
of the system, including
maintainability, reliability,
safety, security, usability, and
other non–functional
specifications.
Work Environment
Including quality attitudes,
cooperation, communication,
and morale.

14. Lean PM Methods 11
that the latest set of Agile methods have a long, rich, and possibly sorted history
[Corry 96], [Fowler 99], [Bowen 99], [Blum 94], [WIKI 00], [Tausworthe 77],
[Tausworthe 79], [Sutherland 00], [Cockburn 00], [Ciapessoni 99], [Boehm 85].
In addition to this list of traditional methods, there is a growing list of process and
organizational patterns that describe the software related activities of a development
group that are outside the actual programming process [Coplien 95]. These patterns
are recorded in the PLoP books [Coplien 95a], [Vlissides 95], [Martin 97], [Harrison
98].
Management Dimensions of Project Management
One of the primary gaps in a Agile process is the creation of traceability artifacts
from the development method to the management practices found in modern
business. Some Agile processes have very little to say about the management
function, others have formal interactions with management. Figure 6 describes
these management practices in the context of a methodology.
Management
Responsibility
Management Action in Pursuit of this Responsibility
Integration The coordination of the elements of the project.
Scope
Ensuring that all requirements are included, as well as only those
requirements are included. No more no less.
Time Ensuring timely completion of the project.
Cost Ensuring that the project completes within budget.
Quality Ensuring the project satisfies the needs for which it was initiated.
Personnel Ensuring the effective use of people.
Communication
Ensuring that the project information is properly conveyed to
management, staff, and the stakeholders.
Risk Identifying and managing risk.
Procurement
Acquiring goods and services from external sources in support of
the project.
Figure 6 – Management Responsibilities Applied to a General Process

15. 12 Agile PM Methods
The Agile Software Delivery Process
Agile processes have entered the market as a remake of Lightweight Software
Development processes. Agile processes emphasis both the rapid and flexible
adaptation to changes in the process, the product, and the development
environment [Aoyama 98], [Aoyama 98A]. This is a very general definition and
therefore not very useful without some specific context — which will be developed
below.
Before establishing this context, Agile processes include three major attributes, they
are:
n Incremental and Evolutionary – allowing adaptation to both internal and
external events.
n Modular and Lean – allowing components of the process to come and
go depending on specific needs if the participants and stakeholders.
n Time Based – built on iterative and concurrent work cycles.
Common Problems with All Software Projects
The National Software Quality Experiment has been conducted each year since
1992 with the following observations that occur from session to session over the
years: [6]
Common Problem Consequences
Software product source code
components are not traced to
requirements.
Software product is not under the control and the
verification procedures are imprecise. Changes cannot be
managed in a controlled manner.
6 In 1992 the DOD Software Technology Strategy set the objective to reduce software problem rates by a
factor of ten by the year 2000. The National Software Quality Experiment is being conducted to benchmark
the state of software product quality and to measure progress towards the national objective.
The National Software Quality Experiment is a mechanism for obtaining core samples of software product
quality. A micro–level national database of product quality is being populated by a continuous stream of
samples from industry, government, and military services. This national database provides the means to
benchmark and measure progress towards the national software quality objective and contains data from
1992 through 1998.
The centerpiece of the experiment is the Software Inspection Lab where data collection procedures, product
checklists, and participant behaviors are packaged for operational project use. The uniform application of the
experiment and the collection of consistent measurements are guaranteed through rigorous training of each
participant. Thousands of participants from dozens of organizations are populating the experiment database
with thousands of defects of all types along with pertinent information needed to pinpoint their root causes.

16. Lean PM Methods 13
Software engineering
practices are not applied in a
systematic manner.
Defect rates are unacceptable
Product designs and source
are managed in an ad hoc
manner
The understandability, maintainability, and adaptability of
the product is negatively impacted.
The construction processes
for the product are not clearly
defined.
Common patterns of the processes are not exploited.
Rapidly changing code base
has become the norm
The code base services the only the short term benefits
and mortgages the future where traceable baseline
requirements, specifications, and design artifacts are the
foundations of success.
Figure 7 – National Software Quality Experiment Results
The Problem of Change
Change takes place throughout the business world, at all levels within an
organization or market place. Change by itself is not a problem. The world is always
changing. It always has been changing. It always will be changing. Businesses and
the processes they use have always had to adapt to a changing world. Often the
changes occurring in the past have been incremental. When a radical change took
place in the past, the next change event was slow in coming. While there has always
been uncertainty in business, it has usually not been significant or sustained for long
periods of time.
The real problem in today’s world is that change is no longer incremental or linear.
Radical nonlinear changes are occurring more frequently. The pace of change is
increasing. Major and sustained uncertainty is now commonplace.
Ready For Agility?
All organizations face the problems that an Agile method can address, but not all
companies are ready for the radical ideas needed to become an agile organization.
Agility is still an emerging topic and is at a stage where it is not possible to buy an
off–the–shelf solution that has been show to behave in the same manner as heavier

17. 14 Agile PM Methods
weight processes. [7]
Elements of agility can certainly be found in many processes,
but as the saying goes – one swallow does not a make summer. [8]
The introduction of an Agile process should only be undertaken by organizations
that are not risk adverse. Organizations who need answers and concepts that are fully
developed out that result in a solution that can implemented with little risk should
stay clear of the Agile Processes. The irony here is – there is no such process that
can deliver a fully developed plan that results in a fully developed project or
product. Let alone one that can be deployed without risk
The Forces Driving Agility
Software acquisition and deployment is generally driven by a need to solve a
specific problem, to do things better, to modify or improve a business or technical
process. The software development process community has two schools of thought
regarding the outcome of these efforts:
n Things are getting better
n Things are getting worse
This conflicting set of opinions adds more confusion to an already confusing
question of — are we actually improving the outcome of the software development process?
A few years ago, methodologies and processes were the domain of academics. The
methodology zoo has grown and at the same time become focused on the
commercial aspects of selling these methodologies to anxious managers, developers
and customers. This selling of methods has overtaken the rational application of these
methods of specific problem domains.
Practical Agile Project Management
The deployment of an Agile project management methodology into an existing
organization faces several obstacles:
n The legacy project management processes must be displaced in some
way to make room for the new process.
7 This of course is not the contention of XP, SCRUM, ASD, and other lightweight, and now agile processes.
But these processes have yet to enter the stage where analytical evidence has been gathered to support the
contention they produce superior results when compared to their less–lightweight cousins. This is a
continuing debate and will not be resolved here.
8 This English proverb can be traced to a Greek proverb. In the ancient world birds were associated with the
household gods and their presence was looked upon as fortuitous. Any harm done to them would bode evil
for the household.

18. Lean PM Methods 15
n The gaps in the legacy process must be filled with the new process
while maintaining the integrity provided by the legacy process.
Common Threads of These Methods
In an attempt to simplify the many attributes of the methods a list of common
threads could be built, using Figure 5 as a framework.
Thread Compliance
Requirements Gathering
Some method of gathering requirements is needed. This
ranges from User Stories, Use Cases, state diagrams,
requirements languages and other formal methods
Software Development or
Procurement
Software must be developed (or procured) that meets the
requirements. These methods each have some technique
to construct the code in a methodological manner.
Testing
Component and System testing are performed in some
structured manner.
Personnel Management
The management of personnel is provided in some
methods, but not all.
Project Management
No all methods have technique for managing the project
in a traditional manner. The non–traditional approaches
may be interesting but are of little comfort to
management unfamiliar with the metrics of Agile
processes.
Figure 8 – Common Aspects Of All Methods
Software development has been described as a series of discrete activities:
(a) analyze the problem and write down the requirements; (b) design the
code; (c) write the code; (d) debug the results. This view of software
production is not only outdated, it was fraught with problems.

19. 16 Agile PM Methods
Is Agile Yet Another Software Methodology Taxonomy?
Before selecting a software development method, some understanding of what type
of software is going to be developed may be appropriate [Jones 00].
Software Type Attributes
Management
Information Systems
Software that enterprises use to support their own business and
administrative operations. The traditional payroll, sales support,
and financial systems are examples
Outsourced systems
Software projects that are built for a client organization. This
could include contracted software development or commercial
systems tailored to meet the needs of the organization.
Systems software
Software that controls a physical device such as a computer or a
telephone switch. Embedded systems are part of this group,
which includes nearly every modern device that is microprocessor
controlled.
Commercial software
Software applications that are marketed to hundreds or even
millions of clients. Word processors, spreadsheets, ERP
applications, and Java applets are examples.
Military software
Software produced for the uniformed services. This includes
commercial applications such as payroll and logistics as well as
weapon system software.
End User Software
Small applications written for personal use. This could include
spreadsheet programs, database programming, or even actual
programming language applications.
Web Application and
e–Projects
Small, medium, and large scale projects with legacy system
integration, transaction processing, multimedia delivery, and web
browser based user interfaces
Figure 9 – Software Systems Taxonomy

20. Lean PM Methods 17
Today, software creation is viewed as a series of discrete steps, plus a
continuous process that guides the software creation process and the
relationships between the discrete and the continuous activities is the
domain of a software development methodology.
[9]
Project Management Drivers
The popular discussion of methodologies focuses on requirements, design, coding,
and testing. The management of a development project is focused on controlling
the scope, deliverables, and expectations of the various participants and
stakeholders. There are primary business drivers for the stakeholders as well as the
participants in the system development. The project manager for a software project
or product is pulled in many directions by the participants and stakeholders.
Figure 10, shows some of the tensions placed on the project manager.
9 This quote was abstracted from the web page introduction to “A Gentle Introduction to Software
Engineering,” March 31, 1999, Software Technology Support Center, Hill Air Force Base, Ogden Utah. This site
focuses on software development processes for government and military applications. It is far removed from
the current Agile discussions that are being applied to e–commerce applications. However, many of the topics
hosted at this site have direct bearing on the current subject, since software engineering is a profession, any
analysis or research is the field is useful.

21. 18 Agile PM Methods
Boss
Ambitious Goals
No Over Runs
No Surprises
Finance
Low Budget
Fast Schedule
No Surprises
Users
Lots of functions
User friendly
Fast
Robust
No Surprises
Subordinates
Fast career path
Preference for creative work
Defer documentation
No Surprises
Maintainers / Support
Staff
No Bugs
Well Documented
No SurprisesProject
Manager
Figure 10 – Tensions On The Software Development Project Manager
How these influences impact the process needs some more development. The
point here is there are many attributes of an IT project that don’t involve the
development of software. The success factors for the project must ALL be
addressed.
Framework for Agile PM Methods
A framework for deploying agile project management processes provides a
descriptive guideline rather than a proscriptive set of rules. This framework
approach provides the user a broader set of recommendations than is found in any
particular named methodology.
This framework is based on two foundations:
n The Software Program Managers Network Nine Best Practices –
which provides guidelines for project managers using practical
suggestions for daily application
n Scott Ambler’s Agile Modeling framework – which provides a broad
framework for creating agile processes applied to software projects.
[Ambler 01]

22. Lean PM Methods 19
Nine Best Practices
The Nine Best Practices constitute a management control system that provides a
disciplined set of processes for containing and directing the complexity of a
software development project.
Figure 11 describes the relationship between these Nine Best Practices and their
outcomes.
The Best Practices can be classified into the following major categories:
n Identify and correct defects and potential problems as early as
possible
n Plan and estimate all project activities and deliverables
n Minimize rework caused by uncontrolled change
n Make effective use of the resources
The reader’s first reaction to these statements may be aren’t you restating the
obvious?. The nine best practices are in fact obvious. The problem comes when it
is time to deploy them into the project environment and attempt to reap the
rewards.
These principles are practiced by all good project managers, whether they are
building complex software systems or pouring concrete for the foundation of a
building. They are obvious, they are intuitive, and they are simple. So why is it so
hard to put them into practice?
The source of these best practices is the Software Program Managers Network,
www.spmn.com. What is presented here is a restatement of the concepts, tailored
for the InSiight project and the culture of Sii. The materials provided by the SPMN
and other resources are available on the web. A brief overview of the best practices
concept is provided in “Industrial–Strength Management Strategies,” Norm Brown,
IEEE Software, July 1996, pp. 94–102.

23. 20 Agile PM Methods
Agreement on
Interfaces
Risk
Management
Formal
Inspections
Metrics Based
Schedule and
Management
Configuration
Management
Project-wide
Visibility of
Progress vs.
Plan
People-Aware
Management
Accountability
Binary Quality
Gates at the
Inch Pebble
Level
Defect Tracking
Against Quality
Targets
Identify and
Correct Defects
Planning and
Tracking
Minimize rework
caused by
uncontrolled
changes
Effective use of
personnel
resources
Figure 11 – Nine Best Practice Principles
Management Engagement
In order for the Nine Best Practices to be effective management must be engaged
in specific ways. This engagement involves:
n Commitment – to the practices and the consequences of the practices.
This commitment usually comes in the form of a formal endorsement of
the process and the deliverables from the process. By officially
sanctioning the Best Practices approach top management, the
stakeholders, and all the participants agree in public that they are
committed to make them work.

24. Lean PM Methods 21
n Action – to implement the best practices. Having a commitment is
easy, making good on the commitment is the hard part. A call to action
approach can be used to deploy the Best Practices. The action needed
to deploy the Best Practices will be managed just like any other
project, with a detailed project plan, well-defined outcomes, and
measurable deliverables.
n Funding – for the changes that will result from the practices. In order
to accrue the benefits of the Best Practices, money must be spent.
The actual funding details are not currently known. The total amount
will be small compared to the total investment for the complex
software project. The return on this investment will be very large – a
major contribution to the successful completion of the product.
n Follow-up – for the behaviors that result from the practices. Using the
Best Practice of Project–Wide Visibility of Progress Versus Plan the
deployment of the Best Practices will become a visible project. A
project schedule will be posted, progress to plan meetings held, and
progress reports published.
n Measurement – of the outcomes of the practices. With measurement,
management can not take place. This is a Best Practice item that will
be used for deploying the Best Practices.
Applying the Nine Best Practices
The Nine Best Practices constitute a management control system that provides a
disciplined set of processes for containing and directing the complexity of a
software development project.
The Best Practices can be classified into the following major categories:
n Identify and correct defects and potential problems as early as
possible.
n Plan and estimate all project activities and deliverables.
n Minimize rework caused by uncontrolled change.
n Make effective use of the resources
The reader’s first reaction to these statements may be “aren’t you restating the
obvious?” The Nine Best Practices are in fact obvious. The problem comes when it
is time to deploy them into the project environment and attempt to reap the
rewards.

25. 22 Agile PM Methods
These principles are practiced by all good project managers, whether they are
building complex software systems or pouring concrete for the foundation of a
building. They are obvious, they are intuitive, and they are simple. So why is it so
hard to put them into practice?
Best Practice Call to Action
Formal Risk Management
All software development has risk. It is an
unavoidable consequence of the design
process. The cost of resolving these risks is
usually low if addressed early in the project
lifecycle. As the project matures, the cost of
mitigating the risk increases rapidly. Nearly
every developer and project manager has
some experience with this effect, but many
pay lip service to.
Recognizing and acknowledging that risks
are present in the project is the first step.
In the past, this was not part of the normal
project management process. By
publicizing the risks, along with the
mitigation plan, everyone can participate in
the solution process.
Effectively managing project risks involves
acceptance and decriminalization of the risks
and the processes used to discover the risks.
In order to address this issue management
must make the commitment to address risk
as part of the normal development process.
Without this commitment, identifying and
addressing risks will become a no win
process to be avoided at all costs.
By making risk management part of the
everyday project process, the participants
can grow to trust management and vice
versa. Only by decriminalizing the
discovery and reporting of risks can this
trust be built.
Agreement on Interfaces
The system interfaces must be designed at
some level before software analysis and
coding. This assumes that the interfaces are
identified and their basic functionality is
stated. The user interfaces and the external
system interfaces must be clearly defined
before the system architecture can be
partitioned. Without this definition process,
the locality of the system' functions cannot
be defined.
The first approach to interface
identification will use the UML notation
for class collaboration. Starting at the
highest level of the system, the meta–class
(or macro–class) components will be
defined and connected. It is through those
connections that the interface components
will be identified.
Formal Inspections
Use small teams of prepared reviewers with
assigned roles. These teams will be
responsible for delivery working software
that meets the quality criteria.
The primary issue here is to define the
quality criteria for the deliverables.

26. Lean PM Methods 23
Best Practice Call to Action
Metrics Based Scheduling and
Management
Plan short duration tasks with measurable
outcomes.
Review key milestones to determine that
progress to plan is being made not only on
the long level tasks, but also the high–level
integration points.
By planning at the inch pebble level,
measurable deliverables can be used to
build trends and replace the lack of
empirical data from previous projects.
There are additional benefits for the
development team, since this lays the
groundwork for the continuous build and
smoke test processes that will be needed in
the later stages of the project.
Binary Quality Gates at the Inch–Pebble
Level
Ensure that development tracking is based
on actual products.
Define the deliverables for each task in
terms of quality, non–functional
requirements as well as the functional
requirements.
Project–wide Visibility of Progress to
Plan
Put the schedule, risk management, and all
deliverables in a public location for access by
all participants.
This is more than using some source code
control system. The paper schedules are
currently on display. The electronic
versions are being kept on a server, but
this is not enough. A Project Web site will be
created for all the materials related to the
project.
Defect Tracking Against Quality Targets
Implement practices to find defects when
they occur.
Continuous smoke testing of the software
will be instituted once the baseline
components are stabilized.
Configuration Management
Use change tracking to formally track the
status of shared products, problem reports,
cost and schedule base line, test programs,
internal and external interfaces, reports used
by more than one organization, and all
concurrently non–baselined information
shared within the project or approved for
internal release through the binary quality
gates.
Make complete use of a source code
control system. If there are not sufficient
capabilities to manage multiple version of
each component, then some other
application must be found. This will be a
critical success factor for the project, since
not only are multiple components being
built, they are being built at different sites,
by diverse groups.

27. 24 Agile PM Methods
Best Practice Call to Action
People–aware Management
Accountability
Minimize burnout.
Help the staff maintain their personal
technical competency.
Manage the time allocated to each task so
that the developer has a high probability of
success without heroic efforts. The project
must invest in timely training. The
subcontracts should be selected that
already have the necessary training.
Figure 12 – Nine Best Practices of a Success Software Project
Agile Project Management Summary
Building on the Software Program Managers Nine Best Practices, the well
established project management methods of the past, the fundamentals of any
project management method, and finally common sense, a framework for Agile
Project Management can be built.
Values of Agile Project Management
Before the principles of Agile Project Management can be defined, a set of underlying
values must be stated. It is from these values that the principles are derived.
n Communication – starts with the project manager and involves all the
stakeholders. The communication of information is constant between
a project manager, the contributors and the stakeholder. It is the
responsibility of the project manager to ensure that the
communication occurs effectively, clearly, and in a timely manner.
Since change is a constant process in an Agile project management
environment, communication is the means to address change.
n Simplicity – defines the approach to discovering the critical success factors
of the project. All activities must add measurable value to the project
management process in some measurable way. Measuring the value of
any activity or produced artifact is the role of the stakeholders and the
project manager. By first asking the question “what is the value of this
specific task?” is the starting point of simplifying the project
management methodology.
n Feedback – “optimism is an occupational hazard of software
development, feedback is the cure” [Beck 99]. Continuous feedback is
a powerful tool for maintaining agility.

28. Lean PM Methods 25
n Courage – important decisions and changes in direction need to be
made with the courage and understanding that change in part of any
modern IT project. Dealing with the consequences through further
change or discarding the outcome when the decision is proven
inadequate requires courage.
n Humility – the best project managers acknowledge they don’t know
everything. The stakeholders, fellow project participants, and
customers all have their our areas of expertise to add value to the
project. An effective approach is to assume that everyone involved
with your project has equal value and therefore should be treated with
respect.
Applying Agile Principles in Practice
Applying these principles in practice creates the foundation for managing IT
projects in an Agile manner.
n Assume Simplicity – as the project evolves it should be assumed that the
simplest solution is the best solution. Overbuilding the system, or
overbuilding any artifact of the project should be avoided. The project
manager should have the courage to not perform any task or produce
any artifact that is not clearly stated in the requirements as needed for the
immediate benefit of the stakeholders.
n Embrace Change – since requirements evolve over time. The
stakeholder understanding of the requirements will change over time.
Project stakeholders themselves may change as the project makes
progress. Project stakeholders may change their point of view, which
in turn will change the goals and success criteria of the project
management effort.
n Enabling The Next Effort Is A Secondary Goal – the project can still be
considered a failure even when the team delivers a working system to
the users. Part of fulfilling the needs of the project stakeholders is to
ensure that the system is robust enough to be extended over time.
Using Alistair Cockburn concept, “when you are playing the software
development game your secondary goal is to setup to play the next
game.” The next effort may be the development of a major release of
your system or it may simply be the operation and support of the
current version of the system.
n Incremental Change – in an important concept. The pressure to get it
right the first time, can overwhelm even the best project manager.
Instead of futilely trying to develop an all encompassing project plan

29. 26 Agile PM Methods
from the start, putting a stake in the ground by developing a small
portion of the system, or perhaps a high–level model of a larger
portion of the system, and then evolving it over time (or simply
discard it when you no longer need it) in an incremental manner.
n Maximize Stakeholder Value – the project stakeholders are investing
resources — time, money, facilities, and etc. — to have a system
deployed that meets their needs. Stakeholders expect that their
investment will be applied in the best way manner. They also deserve
to have the final say in how those resources are invested.
n Manage With A Purpose – create artifacts of the project management
process that have stakeholder value. If you cannot identify why and
for whom you are creating an artifact then why bother doing the
work? Identify a valid purpose for creating an artifact and the
audience for that artifact. Based on that purpose and audience,
develop it to the point where it is both sufficiently accurate and
sufficiently detailed. This principle also applies to a change to an
existing artifacts as well. An important consequence of this principle is
the need to know the audience for the artifact. Go talk to them and
find out what will meet their needs as well as the larger needs of the
project.
n Multiple Project Views – provide different views of the same process for
different audiences. Considering the complexity of any modern
software system construction or acquisition process, there is a need
for a wide range of presentation formats in order to effectively
communicate with the stakeholders, participants, and providers.
n Rapid Feedback – the time between an action and the feedback on that
action must be minimized. Working closely with the stakeholders, to
understand the requirements, to analyze those requirements, and
develop a actionable project plan, provides opportunities for rapid
feedback.
n Working Software Is The Primary Goal of the Project – the goal of any
software project is to produce software that meets the needs of your
project stakeholders in an effective manner. The primary goal is not
to produce extraneous documentation, extraneous management
artifacts, or even models of these artifacts. Any activity that does not
directly contribute to the goal of producing a working system should
be examined.
n Travel Light – since every artifact that is created, and then kept, will
need to be maintained over it’s life cycle. The effort needed for this

30. Lean PM Methods 27
maintenance must be balanced with the value of the artifact. Not only
must the effort be considered, but the risk that the artifact will create
confusion over time if it is not properly maintained must be
considered.

31. 28 Agile PM Methods
Bibliography
[Agresti 86] “New Paradigms for Software Development,” IEEE CS Press,
1986.
[Alleman 01] “Anti Patterns in Project Management: A Book Review,” Glen B.
Alleman,
http://www.pmforum.org/library/books/antipatters.PDF.
[Ambler 01] “Agile Modeling,” Scott Ambler, www.agilemodeling.com.
[Aoyama 98] “New Age of Software Development: How Component Based
Software Engineering Changes the Way of Software
Development,” Mikio Aoyama, 1998 International Workshop on
Competent–Based Software Engineering, 1998.
[Aoyama 8A] “Agile Software Process and Its Experience,” Mikio Aoyama,
International Conference on Software Engineering, 1998.
[Basili 75] “Iterative Enhancement: A Practical Technique for Software
Improvement,” Victor Basili, IEEE Transactions on Software
Engineering, 1(4), December, 1975.
[Beck 99] Extreme Programming Explained, Kent Beck, Addison Wesley, 1999.
[Bennington 56] “Production of Large Computer Programs,” Bennington,
Symposium on Advanced Computer Programs for Digital Computers,
sponsored by Office of Naval Research, June 1956. Reprinted in
Annals of the History of Computing, October 1983, pp. 350–361.
Reprinted at ICSE ’87, Monterey, California, March 30 – April 7,
1987.
[Blackbook 97] “A Condensed Guide to Software Acquisition Best Practices,”
Software Program Managers Network, 1997. Can be found in
HTML format at
http://www_ied.belvoir.army.mil/odisc4/docs/blackbook/black
book.htm.
[Blum 94] “A Taxonomy of Software Development Methods,” Bruce I.
Blum, Communications of the ACM, 37(11), November 1994, pp.
82–86.

32. Lean PM Methods 29
[Bowen 99] “Formal Methods,” Jonathan Bowen, FM’99: World Congress on
Formal Methods, http://archive.comlab.ox.ac.uk/formal–
methods.html.
[Boehm 85] "A Spiral Model of Software Development and Enhancement,"
B. W. Boehm, from Proceedings of an International Workshop on
Software Process and Software Environments, Coto de Caza, Trabuco
Canyon, California, March 27–29, 1985.
[Brooks 87] “No Silver Bullet: Essence and Accidents of Software
Engineering,” Fred Brooks, IEEE Software, 20(4) April 1987, pp.
10–19.
[Brooks 95] The Mythical Man–Month, Fred Brooks, Addison Wesley, 1995.
[Ciapessoni 99] “From Formal Models To Formally Based Methods: An
Industrial Experience,” Emanuele Ciapessoni, Piergiorgio
Mirandola, Alberto Coen–Porisini, Dino Mandrioli and Angelo
Morzenti, ACM Transactions on Software Engineering and Methodology,
8(1), January 1999, pp. 79–113.
[Cockburn 99] “A Methodology per Project,” Alistair Cockburn, Humans and
Technology Technical Report, TR 99.04, October 1999.
http://www.crystalmethodologies.org/articles/mpp/methodolog
yperproject.html
[Cockburn 00] “Selecting a Project’s Methodology,” Alistair Cockburn, IEEE
Software, July/August 2000, pp. 64–71.
[Connolly 96] “The Effects of Extended CASE technology on Group Process
and the Management of Cognitive Breakdowns in Systems
Analysis Teams,” James R. Connolly, PhD Dissertation,
University of Colorado, College of Business and Administartion,
1996.
[Coplien 01] “Project Management Pattern Language,” James Coplien,
http://i44pc48.info.uni-karlsruhe.de/cgi-
bin/OrgPatterns?FrontPage.
[Coplien 95] “A Generative Development–Process Pattern,” James Coplien,
Pattern Languages of Program Design, Addison Wesley, 1995.

33. 30 Agile PM Methods
[Coplien 95a] Patterns Languages of Program Design, edited by James Coplien and
Douglas Schmidt, Addison Wesley, 1995.
[Corry 96] “A Taxonomy of Software Design Methodologies,” Michael
Corry, http://gwis2.circ.gwu.edu/~mcorry/597final.htm.
[Defense 94] Report of the Defense Science Board Task Force on Acquiring
Defense Software Commercially,
www.stsc.hill.af.mil/crosstalk/1994/dec/defense.asp.
[Flower 99] “The New Methodology,” Martin Fowler,
www.martinfowler.com/articles/newMethodology.html
[Goldman 95] Agile Competitors and Virtual Organizations: Strategies for Enriching the
Customer, S. L. Goldman.
[Humphrey 99] “Pathways to Process Maturity: The Personal Software Process
and Team Software Process,” Watts Humphrey, SEInteractive, 2(2),
June 1999,
http://interactive.sei.cmu.edu/Features/1999/June/Background
/Background.jun99.htm.
[Jones 00] Software Assessments, Benchmarks, and Best Practices, Capers
Jones, Addison Wesley, 2000.
[Martin 97] Patterns Languages of Program Design 3, edited by Robert Martin,
Dirk Riehle and Frank Buschmann, Addison Wesley, 1995.
[Osterweil 87] “Software Processes are Software Too,” Leon J. Osterweil,
Proceedings of the 9th International Conference on Software Engineering
(ICSE 1987), pp. 2–13, March 1987, Monterey, CA.
[Osterweil 97] “Software Processes Are Software Too, Revisited,” Leon J.
Osterweil, Proceedings of the 19th International Conference on Software
Engineering (ICSE 1997), pp. 540–548, May 1997, Boston, MA.
[Porter 98] “Understanding the Sources of Variation in Software
Inspections,” Adam Porter, Harvey Siy, Audris Mockus, and
Lawrence Votta, ACM Transactions of Software Engineering and
Methodology, 7(1), January 1998, pp. 41–79.
[Ramo 80] The Management of Innovative Technological Organizations,
Simon Ramo, John Wiley & Sons, 1980.

34. Lean PM Methods 31
[Royce 70] “Managing the Development of Large Software Systems,” Walker
Royce, Proceedings of IEEE WESCON, August 1970.
[Royce 98] Software Project Management: A Unified Framework, Walker Royce,
Addison Wesley, 1998.
[SEI 96] “Software Development Taxonomy,”
www.sei.cmu.edu/legacy/kit/taxonomy.html.
[Sutherland 00] “SCRUM Hyperactive Software Development Method,” Jeff
Sutherland, http://jeffsutherland.com/scrum.
[Standish 95] “Chaos,” http://www.standishgroup.com/visitor/chaos.htm.
[Tausworthe 79] Standard Development of Computer Software, Robert C. Tausworthe,
Prentice Hall, 1977.
[Vlissides 95] Patterns Languages of Program Design 2, edited by John Vlissides,
James Coplien and Norman Kerth, Addison Wesley, 1995.
[WIKI 00] http://www.c2.com/cgi/wiki?CategoryMethodology