Agile PM

Agile Project
Management
Vol. 4, No. 2
Agile Project Management:

Principles and Tools
by Jim Highsmith
Fellow, Cutter Business Technology Council
Traditional project management and agile project management dont have

to be like oil and water. While project managers should understand the
basic practices that fall under traditional project management, they should
also know when and where to apply agile practices. In this Executive
Report, Cutter Business Technology Council Fellow Jim Highsmith outlines

three situations in which managers should strongly lean toward agile over
traditional, describes an overall project management framework for thinking
about the phases of an agile project, indentifies a series of tools that have
proven effective for each of these phases, and defines nine principles that
apply to all agile projects.
About Cutter Consortium
Access
to the
Access
Experts
Cutter Consortiums mission is to foster the debate of, and dialogue on, the
business-technology issues challenging enterprises today and to help organizations leverage IT for competitive advantage and business success. Cutters
philosophy is that most of the issues managers face are complex enough to
merit examination that goes beyond simple pronouncements. The Consortium
takes a unique view of the business-technology landscape, looking beyond the
one-dimensional technology fix approach so common today. We know there
are no silver bullets in IT and that successful implementation and deployment
of a technology is as crucial as the selection of that technology.
To accomplish our mission, we have assembled the worlds preeminent IT
consultants a distinguished group of internationally recognized experts
committed to delivering top-level, critical, objective advice. Each of the
Consortiums nine practice areas features a team of Senior Consultants whose
credentials are unmatched by any other service provider. This group of experts
provides all the consulting, performs all the research and writing, develops and
presents all the workshops, and fields all the inquiries from Cutter clients.
This is what differentiates Cutter from other analyst and consulting firms and
why we say Cutter gives you access to the experts. All of Cutters products and
services are provided by todays top thinkers in business and IT. Cutters clients
tap into this brain trust and are the beneficiaries of the dialogue and debate our
experts engage in at the annual Cutter Summit, in the pages of the Cutter IT
Journal, through the collaborative forecasting of the Cutter Business Technology
Council, and in our many reports and advisories.
Cutter Consortiums menu of products and services can be customized to fit your
organizations budget. Most importantly, Cutter offers objectivity. Unlike so many
information providers, the Consortium has no special ties to vendors and can
therefore be completely forthright and critical. Thats why more than 5,300
global organizations rely on Cutter for the no-holds-barred advice they need
to gain and to maintain a competitive edge and for the peace of mind that
comes with knowing they are relying on the best minds in the business for
their information, insight, and guidance.
Cutter Business Technology Council

Rob Austin
Christine Davis
Tom DeMarco
Jim Highsmith
Tim Lister
Ken Orr
Ed Yourdon
Agile Project Management:

Principles and Tools
AGILE PROJECT MANAGEMENT
ADVISORY SERVICE
Executive Report, Vol. 4, No. 2
by Jim Highsmith, Fellow, Cutter Business Technology Council

Over the last year Ive been working with a software product company in Canada that has a mixed
product portfolio of large legacy
products and exciting new ones.
With some of its new products,
the company literally doesnt
know past the next two- to threeweek development iteration
which features will be included in
the subsequent development iteration. It does have a clear product
vision. It does have a product
business feasibility plan. It does
have a general idea about what
features are needed in the product. It does have active involvement from product marketing. It
does have a general release time
frame and resource expenditure
plan. It does have an overall product platform architecture. Within
this vision, business and technical

framework, and overall product
release plan, the company delivers tested features every two
to three weeks and then adapts
its plans to the reality of the situation as it is today, not how it
was months ago when the project
first began.
Recently, this company released a
new product, on a new hardware
platform, in a matter of months,
to rave reviews. This is the type of
product and the type of business
environment that needs agile project management (APM) and agile
software development. At the
same time, this company utilizes
agile practices on its large legacy
applications to improve responsiveness to customer enhancement requests.
Though agile practices have the

most notoriety in the software
development arena, all of the
principles and most of the practices (except some of the technical practices such as refactoring)
are applicable to nonsoftware
development projects. In fact, several of the named agile software
development methodologies (or
ecosystems, to use a word I prefer) Scrum, Dynamic Systems
Development Method (DSDM),
adaptive software development
are project managementoriented.
WHERE APM IS NEEDED
APM complements traditional
project management (TPM) in
many ways. Good project managers should understand the
basics of setting up project
2
organizations, budgeting, critical
path scheduling, and myriad other
established project management
practices. However, good project
managers should also know when
and how to apply agile practices.
There are three broad situations
in which APM would be more
appropriate than TPM:
1. High exploration-factor projects
2. Projects in which customer
responsiveness is paramount
3. Organizations with innovative
cultures
High Exploration-Factor Projects
Projects run the gamut from

low exploration-factor projects
in which the technology is well
known and the requirements
are relatively stable to very high
exploration-factor ones in which
the technology is bleeding edge
and the requirements are highly
volatile. Exploration factors are a
type of risk factor, combining several aspects of risk into an overall
assessment. Some project teams
venture into the unknown. Like
the early explorers James Cook
and his South Pacific explorations,
for example these teams are
exploring new technologies,
new products, or new business
initiatives. The more uncertain

the future, the more a project
management methodology must
focus on short-interval delivery
and constant adaptation.
Responsiveness to Customers
Projects that fall into this category

emphasize cost containment
rather than high exploration
factors, but customer interaction
is critical to the projects success.
For example, Sam Bayer, a Cutter
Consortium Senior Consultant and
colleague of mine, has been using
APM practices to deliver results
to a banking client.1
Innovative Organizational
Cultures
One of the factors that determines

the success or failure of methodology or process improvement
initiatives one that is repeatedly
ignored is organizational
culture. Highly complianceoriented processes, such as the
International Organization for
Standardization (ISO) and the
Software Engineering Institutes
(SEI) Capability Maturity Model
1For details, see Agile Development
Innovation Only? Cutter Consortium

Agile Project Management E-Mail Advisor,
9 January 2003.
(CMM), fit best within a controloriented culture. In innovationoriented cultures, such as those
in many high-tech companies,
the perceived bureaucracy of the
CMM often precludes its implementation. Agile approaches,
with their emphasis on delivery,
individual capability, and reduced
formality, appeal to these innovative cultures.2
My project managers are freaking
out, lamented one senior IT manager (a comment I hear more and
more frequently). He was referring to the misalignment between
software development teams
using Extreme Programming (XP)
or another agile software development method and his project
management office staff, who are
steeped in traditional Project
Management Institute (PMI)
centric project management
practices. One objective of this
Executive Report is to help bridge
that gap. However, the gap doesnt
disappear. There are significantly
different principles that drive agile
and traditional project management, but there are also differences driven by the unique
2For an in-depth look at culture and meth-
odology matching, see chapter 24 of [9].
The Agile Project Management Advisory Service Executive Report is published by the Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA
02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America,
+1 800 888 1816; E-mail: service@cutter.com; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: kletourneau@cutter.com.
Managing Editor: Rick Saia, E-mail: rsaia@cutter.com. Production Editor: Allison Make, E-mail: amake@cutter.com. ISSN: 1540-6768. 2003 by Cutter
Consortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law.
Reprints make an excellent training tool. For information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700
or e-mail service@cutter.com.
VOL. 4, NO. 2
www.cutter.com
EXECUTIVE REPORT
problems encountered in extreme,
high-speed, high-change projects.
of the competitive storms many

companies now fear [4].
WHAT IS AGILITY?
For myself, Ive concocted a

somewhat shorter definition:
Agility is the ability to both create
and respond to change. Creating
change disrupts competitors;
responding to change guards
against competitive thrusts.
Creating change requires innovation: developing new products,
creating new sales channels,
reducing product development
time, customizing products for
increasingly smaller market segments. Rather than resist change,
product development and project
management practices should
seek to create change for your
competitors. In addition, your
organizational environment must
be able to respond quickly to both
anticipated and unanticipated
changes created by your competitors and customers.
Agility does not come in a can.

One size does not fit all. There are
no five common steps to achievement [3]. What is agility? Why is
it important? How do we become
agile? In the software world,
the concept of agile software
development can be traced
back to February 2001 when the
AgileAlliance wrote the Manifesto
for Agile Software Development
(www.agilealliance.org). But the
concept of agility has a longer
history in the manufacturing
world. As a response to Japanese
manufacturers effective use of
Lean Manufacturing practices in
the 1980s, a group of US manufacturers initiated agility research
programs, some of which were
funded by the US Department
of Defense (DOD).
Why Agility Is Important

Defining Agility
In their book Agile Competitors

and Virtual Organizations, Steven
Goldman, Roger Nagel, and
Kenneth Preiss write, Agility
is dynamic, context-specific,
aggressively change-embracing,
and growth-oriented. It is not
about improving efficiency, cutting
costs, or battening down the business hatches to ride out fearsome
competitive storms. It is about
succeeding and about winning:
about succeeding in emerging
competitive arenas, and about
winning profits, market share,
and customers in the very center
2003 CUTTER CONSORTIUM
Business is changing. Customers

are fickle and demanding. Technology is changing faster than we
can master it. Investors romp from
one industry to another, or one
country to another, with blinding
speed. New business models
demand a quick response (or
sometimes no response). Some
companies and some industries
are more isolated from these
changes than others. Your company doesnt have to be super
agile, just more agile than your
competitors if you can figure
out who they will be tomorrow.
If companies are to survive in this

turbulent Internet economy, they
must change both their processes and their perspectives with
respect to change. We are no
longer talking about 15%-20%
scope creep on projects; we
are talking about everything
scope, features, technology, architecture changing within the
span of six months. In case after
case, when Ive talked to companies with projects that are
attempting to create change
and achieve competitive advantage, Im continuously surprised
by the magnitude of change their
projects undergo. The traditional
project management maxim of
conforming to plan fails dramatically in these situations.
How We Become Agile
Finally, how do we become agile?

Agility is more attitude than
process, more environment than
methodology. H.T. Goranson has a
somewhat surprising set of three
principles that answer this question of becoming agile [6]. First,
an organization must have a
robust system of self-organizing
agents. In his book Response
Ability, Rick Dove discusses
the need for continuous reconfigurability of both manufacturing
infrastructures and people infrastructures [3]. Agility doesnt
come from top-down planning
but from bottom-up, goal-seeking
self-organization.
Second, agility requires a common goal, a High Concept goal in
VOL. 4, NO. 2
4
Goransons terminology. A High
Concept goal provides a clear
indication of the objective that
can rally the diverse agents but
leaves the details to the participants. Finally, and most surprising,
Goranson says that agility depends
on a well-trusted, but fluid, contracting system. He uses the
Hollywood movie-making business as an example in which
major deals are made with little
formalization. Both case law as
well as long-developed and informal but binding ways of operating
allow rapid formulation of movie
teams who trust the system
to work.
How agile is your organization?
How agile does it need to be?
How agile do your project management practices need to be?
Answering these questions is not
easy, because the answers will
cause severe headaches. You
have to be willing to reexamine
every assumption upon which
current practices are based.
REFRAMING PROJECT
MANAGEMENT
The original Manifesto for Agile
Software Development was
obviously intended for software
development, but with a few
alterations, it can become a
Manifesto for Agile Project
Management [7]:
n Individuals and interactions
over processes and tools
n Delivering features over
compliance activities
VOL. 4, NO. 2
AGILE PROJECT MANAGEMENT ADVISORY SERVICE

n Customer collaboration over
contract negotiation
n Responding to change over
following a plan
As I wrote in Agile Software
Development Ecosystems, The
left side of the Agile Manifesto
value statements indicates what
Agilists consider more important
than the items on the right side.
This should not be construed
as indicating that tools, process,
compliance, contracts, or plans
are unimportant. There is a
tremendous difference between
one thing being more or less
important than another and being
unimportant. Judicious use of
tools is absolutely critical to
speeding software development
and reducing its costs. Contracts
are one vital component to understanding developer-customer
relationships. Documentation, in
moderation, aids communication,
enhances knowledge transfer,
preserves historical information,
and fulfills governmental and legal
requirements [9].
Agile project management
reframes several fundamental
assumptions about project management. Although many of the
practices and tools of APM are the
same as those of TPM, the fundamental strategies and assumptions are different, and therefore
the application of those practices
and tools will be different.
The Project Management
Body of Knowledge
(PMBOK) Guide of PMI is

based on two underlying
theories: managementas-planning (for planning
and execution) and the
thermostat model (for control). Unfortunately, both
theories can be shown to
be heroically simplistic and
insufficient from the point
of view of project management reality. [11]
This quote sounds somewhat
extreme. It could possibly have
been uttered by one of Cutters
esteemed extreme project management practitioners such as
Doug DeCarlo or Rob Thomsett.
However, this questioning of conventional project management
wisdom doesnt come from some
high-tech source, but from one
we generally consider low-tech
the construction industry. In many
debates, Ive seen or heard comments like, The traditional project management practices work
fine for the construction industry
where many of them originated,
but they dont apply to high-tech
software development. But if
these practices are being challenged within the construction
industry itself, maybe there
is even more reason to challenge
them in the IT industry.
TPM is composed of three
processes that exchange information planning, controlling,
and executing. In construction
projects, the authors of the quote
above see several troubling
www.cutter.com
EXECUTIVE REPORT
aspects of traditional planning.
First, the motivation for planning
often comes from outside the
project; that is, plans are developed to satisfy legal, regulatory, or
management requirements rather
than basing them on the actual
work that needs to be accomplished. Second, the motivation
for plans often relates more to the
desire for control than the needs
of actual work execution. We see
this constantly in software development, where the task-based
planning that project managers
use for control has little relationship to how developers actually
work. Third, planning and control
become the focal points; execution is relegated to minor importance status, and legitimizing the
project takes precedence over
producing results.
Since planning and control
become the focus in TPM, this
philosophy gives rise to the notion
that a good project manager can
run any type of project with relatively little domain knowledge of
the work itself. Therefore, a good
project manager could, theoretically, run a construction project
or a software project with little
knowledge of either domain.
Control has traditionally centered
on correction, not learning,
because the plans are viewed as
correct, and translating the plan
into action is considered a simple
process. Witness the conventional
wisdom that construction itself
(carpentry, electrical, plumbing,
etc.) is merely manual, mechanical work without much decisionmaking or creativity (just follow
the plans) or that programming
is just coding whats specified. If
plans are viewed as correct, then
control focuses on fixing mistakes,
not learning something new that
might legitimately alter the plans.
Explaining discrepancies, not
learning, takes center stage. Other
issues with this traditional view
of control include: inappropriate
manipulation of work in order to
meet the plan, reduced possibilities for collaboration, incorrect
interpretation of performance,
and reluctance to revise plans.
APM is an execution-biased
model. TPM is a planning-andcontrolbiased model. In APM,
the project managers primary
role is to create a vision of the
product to be produced and
guide the team toward making
that vision a reality. In TPM, the
project managers primary role
is to develop plans and schedules
and control progress such that
the plan is implemented. There
are projects that have been very
successful using both APM and
TPM approaches. The determination of which to use should be
based on project type and organizational culture.
Agile project management could
also be labeled collaborative project management. Though agile
projects need project managers,
the role is more of a facilitator,
influencer, and coordinator than
a controller and ultimate authority.

Agile project managers make decisions; its how those decisions are
made that differs. Agile project
managers dont burrow into their
offices and invent project plans;
they facilitate the entire core teams
development of those plans.
CONTROLLING
AGILE PROJECTS
Project control concerns
senior managers and executives.
Elaborate planning and control
systems, both project and
accounting based, have evolved
to provide executives with information that indicates projects and
expenditures are being adequately
controlled. Although many in the
technical community are exasperated at the intrusions into
their work required to provide
this information, executives
have fiduciary, legal, and ethical
responsibilities that dictate many
of these compliance activities.
Nevertheless, in highly volatile,
extreme projects, some of the
compliance systems designed
for more sedate environments
are inappropriate, and others
mask actual performance.
Since TPM begins with deterministic, predictive plans and then
exercises control over those plans,
it can be characterized as having
a conformance to plan control
mentality. For example, earned
value analysis is one way of
measuring conformance to plan.
However, when projects are
constantly changing, measuring
VOL. 4, NO. 2
6
performance by conformance to
plan will be counterproductive.
Executives and managers should
ask slightly different questions
about agile projects:
n Are we getting customer
value from the project? In
an agile project, in which many
things can change over the
course of an iteration or milestone, we need to constantly
review the projects business
case. The project customers
and sponsor will need to make
frequent adjustments in the
feature priorities based on their
interpretation of feature value.
Sponsors will be involved in
tradeoff decisions between
time, cost, and scope. Because
of the nature of agile projects,
they often become relatively
fixed in time and cost (the
highest priority to control)
and flexible in scope.
n Is the project progressing
satisfactorily? This question
is more difficult to answer than
Is the project conforming to
plan? Conformance to plan
is one aspect of satisfactory
progression, but only one.
n Is the project team adapting
effectively to changes
imposed by management,
customers, or technology?
If managers and executives
want projects teams that
can be flexible and adapt
to change, then they must
ask slightly different questions
about performance.
VOL. 4, NO. 2

DELIVERY VERSUS
COMPLIANCE
APM focuses on delivery, while
TPM often seems to focus on
compliance. Unfortunately,
compliance activities dont
build products. In working with
several organizations recently, Ive
addressed the issues surrounding
compliance with various standards such as ISO and CMM. Even
though the SEIs intention is to
raise organizational capability to
take on software projects and its
staff does not recommend striving
to attain some level just to be
able to say, Were CMM Level 3,
reality indicates that many organizations have this motivation.
Contractors to the DOD, in particular, are thus motivated because
the DOD specifies CMM capability
levels in contracts. These organizations may not think CMM is
the best way to deliver software,
but they need to comply with its
mandates.
In reality, every product development organization, every project,
and every company has issues
with compliance. A spate of
recent business news accuses
corporations of not complying
with accounting, legal, and ethical
standards. Though the pharmaceutical companies may decry
US Food and Drug Administration
inefficiencies, few consumers
would want to buy drugs
unfettered by federal oversight.
Executives have a responsibility
to shareholders, employees, and
customers to exercise oversight.
This oversight may take the form

of audits, project status reports,
purchasing policies, or certifications such as ISO. Companies
may see certification as a marketing tool; consider, for example,
the large number of Indian
companies certified at high CMM
levels. Concerns over product
liability drive companies to comply with extensive documentation
requirements.
In short, there will always be
a necessity for organizations
to comply with certain internal
and external constraints. Compliance is a cost of doing business. However, compliance can
also strangle innovation, raise
costs dramatically, and lengthen
product development cycles. As
Figure 1 shows, compliance activities can spiral out of control as
performance shortfalls are fixed
by additional compliance activities
(Well never make that mistake
again!), which in turn negatively
impact delivery results.
Dont confuse delivery activities
with compliance activities. For
example, lets postulate that a
team constructs a series of design
diagrams on a whiteboard. From
a product delivery perspective,
taking digital photos of the diagrams and storing them in a
project folder may be sufficient.
However, from a compliance
perspective (say, to maintain ISO
certification, which is important to
the company), the diagrams need
to be formalized and documented
in a standard format. Informal
www.cutter.com
EXECUTIVE REPORT
documentation satisfies the delivery process; the formal documentation satisfies the compliance
process.
For our delivery process, we
should concentrate on a streamlined set of activities that directly
deliver value. We should ruthlessly eliminate overhead activities. We should target skills
training and tools at the core
development activities to improve
their effectiveness.
In contrast, we should think of
all compliance activities as overhead cost. Some compliance
activities are necessary, but they
tend to get out of hand. Therefore,
our first strategy should be to
minimize compliance activities
as much as possible. When compliance costs are too high, they
undermine the development
process and lead to high-cost
products. But cost isnt the only
problem with compliance. Even
more serious is the impact of
compliance on development time.
Therefore, our goal should be
to offload compliance activities
from the development team to
the greatest extent possible.
Lets further examine the design
document example. Once the
design diagrams are complete on
the whiteboards, support staff
not the developers should convert the low-ceremony diagrams
into formal documentation. The
support staff cost can be lower,
and these individuals can free
up the development staff to
increases
Perceived
Performance
Shortfall
Compliance
Activity
Delivered
Results
decreases
increases
Delivery
Activity
decreases
Figure 1 The compliance paradox.
continue on with the project with

minimal schedule impact. When
we fail to differentiate between
delivery and compliance activities,
we fall into the trap of believing
that cleaning up and formalizing
the documentation is actually
helping developers build better
products. By offloading, we force
ourselves to confront the true
cost of compliance. By offloading,
we keep compliance activities
from wrecking development
schedules.
We can rail against the compliance process, but its mostly
futile (not that we shouldnt at
least try to eliminate truly onerous
compliance processes even so).
Compliance activities are necessary, and they are not going away.
However, compliance requirements should not be confused

with development objectives.
We want to design the best
process possible to meet the
development objectives, and
then, and only then, we want
to add the compliance activities
alongside the delivery process.
We want our delivery processes
to be effective. We want our compliance processes to be efficient.
Keeping the two separated will
do your product development
process a world of good.3
3For additional discussion on this issue,
see Lean Development: Delivery Versus

Compliance, Cutter Business Technology
Trends and Impacts Council Opinion, Vol. 4,
No. 1, January 2003.
VOL. 4, NO. 2
APM FOCUS
The remainder of this Executive
Report covers three aspects of
APM. First, it describes an overall
project management framework
for thinking about the phases of an
agile project. Second, it identifies
a series of tools that have proven
effective for each of the phases.
This is not an exhaustive set of
project management tools (there
are many more that are the subject of numerous project management books), but rather a set that
focuses on visioning, delivery, and
adapting an agile set of tools.
Third, the report defines nine
principles that apply to all agile
projects. Although specific tools
may vary from project to project,
these nine key principles are
always in the forefront of the
project teams consciousness.
These principles are guidelines

that breathe life into the tools.
So, for example, Tool I2: Daily
Interaction with Customers (on
page 21) describes how development teams need frequent interaction with customers on a variety
of issues. (Why this is important
is summarized in the principle
Deliver Something Useful on
page 30.) Without tools, the principles are empty. Without principles,
the tools are sterile and inflexible.
AN AGILE PROJECT
MANAGEMENT MODEL
The agile project management
models flow, as shown in Figure
2, appears similar to that of a
traditional model. However, traditional models focus on planning
and control, while the APM model
focuses on delivery (execution)
Envision
Adaptations
Vision
Speculate
Feature
Plan
Iteratively
Deliver Features
Tested
Features
Feature
List
Monitor
and Adapt
Close
Final
Product
Figure 2 The agile project management model.
VOL. 4, NO. 2
and adaptation. The APM model

also identifies both phases and
results. For example, the envision
phase results in a project vision.
There are other differences that,
while they may seem subtle,
are significant. First, envision
replaces the traditional initiate
to indicate the criticality of vision.
Second, a speculate phase
replaces a plan phase. Words
convey certain meanings, and
those meanings arise from systematic use over time. The word
plan has become associated
with prediction and relative certainty. Speculate indicates that
the future is uncertain. We know
that the future of any project,
particularly extreme projects,
contains uncertainty, but we still
try to plan that uncertainty away.
We have to learn to speculate and
adapt rather than plan and build.
Third, the APM model specifies
iterative delivery it is an explicitly nonlinear, concurrent, nonwaterfall model. The APM model
focuses on how project managers
contribute to product delivery first
and compliance a distant second.
The TPM model, on the other
hand, emphasizes control. My
vision of control is someone
sitting atop a large piece of construction machinery controlling
it. Project teams are groups of
people, not cogs in machines.
They can be led, motivated,
organized, and coordinated, but
control is a relic of the past. So
a team practicing APM monitors
information and adapts to current
www.cutter.com
EXECUTIVE REPORT
conditions. Finally, the APM model
ends with a close phase, in which
the primary objectives are knowledge transfer and, of course, a
celebration.
To sum up, the five phases of agile
project management are:
1. Envision determine the
product vision, who is going
to do the work, and how the
team will work together.
2. Speculate develop a featurebased release, milestone, and
iteration plan.
3. Iteratively deliver features
deliver tested features in short
time frames.
4. Monitor and adapt review
the delivered results, the current business environment,
and the teams performance
and adapt as necessary.
5. Close conclude the project,
wrap up loose ends, and
celebrate.
AGILE PROJECT
MANAGEMENT TOOLS
The APM tools are presented
under an appropriate framework
phase, although some of the
tools can, and should, be used
in several phases.
Envision
Project envisioning covers what,

who, and how. I use the word
envision, rather than the more
common initiate, because
the key success factor in the
beginning of a project is to create

a vision for the customers and the
project team. Absent a vision, the
remaining activities in getting a
project off the ground are wasted
effort. In business-speak, vision is
the critical success factor of this
phase. First, we need to envision
what to deliver a vision of the
product and the scope of the project. Second, we need to envision
who will be involved the community of project team members
and other stakeholders. And third,
the project team members must
envision how they intend to work
together. How a team intends to
work together their practices
and guiding principles is as
important to success as a clearly
articulated vision [13].
It is a little difficult to determine
where envisioning begins,
because the APM model as shown
is not a portfolio or product management model but a project
management model. Some companies employ extensive feasibility
and marketing studies prior to
initiating development projects,
while others use only brief project
requests. Depending upon the
situation, the information available to an envision phase may
vary, but the key output remains
constant: a mutually agreed-upon
product vision. Although there are
other important aspects of initiating a project budgets, staff
organization, reporting needs
without a commonly held product
vision, the project will falter.
The purpose of the envisioning

phase is to clearly identify what
is to be done and under what conditions it is to be accomplished.
Specifically, this phase answers
the following questions:
n What is the product vision?
n What is the purpose of the
project (objectives) and its
constraints?
n Who will be included in the
project community?
n How will the team deliver
the product?
For small projects, much if not
most of the project envisioning
work can be accomplished in a
single kickoff week. For larger
projects, additional training,
resource procurement, architectural work, and justification analysis may take longer and can be
included in an Iteration 0 (see
Tool S5 on page 20).
Figure 3 depicts the evolution
of a project plan from vision,
to scope, to features utilizing
three simple but powerful artifacts: the vision box, the project
data sheet (PDS), and the iterative
feature plan. Each of these artifacts is simple (in concept), powerful, low ceremony (informal),
and contains limited real estate.
The vision box exercise forces
the team to condense information
about a product vision onto the
limited space of a box. The project data sheet forces the team
to condense key project scope
VOL. 4, NO. 2
10
Product Vision Box

Project Data Sheet
Project Name:
Project Start Date:
Clients:
Project Leader:
Executive Sponsor:
Client Benefits:
Project Objective Statement:
Performance Quality Attributes:
Project Data Sheet
Focus Matrix:
Excel
Improve
Accept
Target
Scope
Schedule
Defects
Resource
Features: (Ability to Statements)
Architecture:
Major Milestones:
Issues/Risks:
will be sold in shrink-wrapped

boxes, and their task is to design
the product box front and back.
This involves coming up with a
product name, a graphic, three to
four key bullet points on the front
to sell the product, a detailed
feature description on the back,
and operating requirements.
Figure 4 shows a sample vision
box developed during a workshop session.
Date
1.
2.
3.
4.
1992-97 Knowledge Structures, Inc.
Cycle 0
Architecture
1.0
Cycle 1
Architecture
1.1
Cycle 2
Cycle 3
Cycle 4
Architecture
1.2
Feature 1
Feature/Component Requirements Card
Requirements
Cards
Feature/Component ID:
Feature/Component Name:
Feature/Component Type:
Feature/Component Description:
Planned Cycle:
Feature 3
Feature 7

Est. Work Effort:
Requirements Uncertainty (H,M,L):
Dependencies with other Features:
Feature 2

Planned Cycle:
Planned Cycle:
Feature 5
Est. Work Effort:

Planned Cycle:
Est. Work Effort:

Planned Cycle:
Feature 4
Est. Work Effort:


Est. Work Effort:
Planned Cycle:
Iterative Feature Plan
Feature 6
Est. Work Effort:
Planned Cycle:
Est. Work Effort:

Figure 3 The evolution of a project plan.
information into a single page.

Feature cards force the team to
condense the key information
about a feature onto a single
4 x 6inch index card. Limiting
the space in which we record
information requires focus and
selection it requires intense
collaboration and thinking.
Tool E1: Product Vision Box
and Elevator Test Statement
The product vision box and elevator test statement are two tools
that enable a team to create a
product vision. The box exercise
emphasizes that projects produce
products, because even within
an IT organization, every project
VOL. 4, NO. 2
should be considered to produce

a product. Whether the project
results involve enhancements to
an internal accounting system or
a new e-commerce site, productoriented thinking pays benefits.
The design-the-box exercise
(originally developed by my
colleague Bill Shackelford) is
an effective practice for getting
teams to think about a product
vision. In this exercise, the entire
team, including customers,
breaks up into groups of four to
six people (this works best with
cross-functional participation).
The team members make the
assumption that the product
Coming up with 15 or 20 product

features proves to be easy. Its
figuring out which three or four
would cause someone to buy the
product that is difficult. One thing
that usually happens is an intense
discussion about who the customer really is. It always amazes
me that, when using a very simple
product example, the product
vision boxes end up so disparate
among three to five teams.
Presentations by each of the
groups are then followed by a
discussion of how the different
focal points can be reduced to
a few that everyone agrees upon.
A lot of good information gets
generated by this exercise plus,
its fun.
A second visioning, and focusing,
tool is the elevator test statement:
For mid-sized companys
marketing and sales departments who need basic of
CRM functionality, the CRMInnovator is a Web-based
service that provides sales
tracking, lead generation,
and sales representative
www.cutter.com
11
EXECUTIVE REPORT
support features that
improve customer relationships at critical touch
points. Unlike other
services or package software products, our product
provides very capable services at a moderate cost.
This product vision model helps
team members pass the elevator
test the ability to explain the
project to someone within two
minutes [16]:
n For (target customer)
n Who (statement of the need
or opportunity)
n The (product name) is a
(product category)
Figure 4 Product vision box example.
n That (key benefit, compelling

reason to buy)
n Unlike (primary competitive
alternative)
n Our product (statement of
primary differentiation).
For any project, but particularly
those with high uncertainty for
which significant requirements
changes are anticipated, creating
a product vision statement helps
teams remain focused on the critical aspects of the product, even
when details are changing rapidly.
It is very easy to get focused on
the short-term issues associated
with a two- to four-week development iteration and lose track of
the overall product vision.
Finally, with several hours of

active discussion recorded on
flipchart paper, the group can
construct a good outline for a
complete one- to three-page
product vision document that
might include: the mission statement, a tradeoff matrix (scope,
schedule, cost, defects), pictures
of the boxes, target customers
and each of their needs, customer
satisfaction measures, key technology and operational requirements, critical product constraints
(performance, ease of use,
volumes), and key financial
indicators.
For a four- to six-month project,

this visioning exercise might take
about half a day, but it will pay
big dividends. Recently, Ive had
a client report that spending three
to four hours for a visioning session brought a group with widely
different ideas about product
direction into close alignment.
The more critical the delivery
schedule and the more volatile
the project, the more important
it is that the team have a good
vision of the final desired outcome. Minus this vision, iterative
development projects are likely
to become oscillating projects
because everyone is looking
VOL. 4, NO. 2
12
at the minutiae rather than the

big picture.
Tool E2: Stakeholder Identification
Identifying a projects stakeholders is a project management task

that is very easy to say and often
most difficult to do well. For
example, a large companys
enterprise resource planning
(ERP) or customer relationship
management (CRM) application
implementation could have hundreds, or even thousands, of
stakeholders. Commercial software products may have millions
of stakeholders. Project team after
project team has been blindsided
by previously unidentified stakeholders coming forth to bury the
project with unforeseen information or internal political agendas.
A general categorization of stakeholders could be:
decisionmaking authority or
influence the project outcomes.
n Customers the group of

people who will actually use
the system and may, in the
case of a commercial product,
be the purchaser.
n Project team the individuals,

both full-time and part-time,
who are charged with delivering results.
n Sponsors the person, or

group of people, who champion the product and make key
decisions about the products
goals and constraints.
n Project manager the person
who leads the team charged
with delivering results.
n Management a potentially
wide range of individuals who
can be in charge of customer,
sponsor, or development
team organizations. They
may have budget or technical
Product Vision
Feature ID
Customers
Feature Priority
Project Team
Requirements
Conversation
Acceptance
The more complex the stakeholder group, the more time

project managers must spend
managing the expectations of
the various groups, getting critical
project decisions made, and
keeping the project from being
pulled in too many directions.4
Identification is the first step in
integrating various stakeholders
into the project community.
Tool E3: Customer-Project
Team Interface
Figure 5 identifies the components of a customer-project team

interface for the customers who
will be defining feature requirements and helping the project
team make day-to-day decisions.
In the software world, XP postulates an onsite customer who
has specific duties of defining
requirements and making feature
priority decisions. However, larger
projects may have many customers who often have conflicting
priorities. No single person may
have the knowledge of all the
feature requirements. For larger
projects or for projects with wideranging needs for customer information, the important issue is not
to have a single customer, but to
4For an in-depth look at stakeholder iden-
Figure 5 Customer-project team interface.
VOL. 4, NO. 2
tification and management, see [18].
www.cutter.com
13
EXECUTIVE REPORT
consolidate multiple voices into
a single customer voice. The
exchange between the project
team and this consolidated
voice includes the identification
of features, prioritization of those
features (so there must be some
type of decisionmaking process
on the customers part), and
ongoing conversations and interactions between customers and
the project team.
IT organizations and product
development organizations (both
software and industrial products)
will have different players on
the customer side, but the interactions will be similar. Whereas a
product group may use a product
manager role to facilitate the
interaction, an IT organization
may designate a business analyst.
In order to guard intellectual property, product companies may be
reluctant to release early versions
of their products to customers.
Whatever the complexities on
either side of the customerdeveloper interface, the basic
interactions shown in Figure 5
are necessary for a successful
agile project.
The worst situation arises when
prioritization fails and the development team, in order to keep
the project from bogging down,
begins making the priority decisions itself. This often degenerates
into a no-win situation, as the customers can always fault the decisions and then use that failure as
an excuse to reduce their support
of the project. The project loses

its partnership relationships.
To address this issue, I recommend that every project every
single one have a product manager role (separate from the project managers role). In a small,
colocated team project, this role
can be played by the onsite
customer advocated by XP.
Product companies (both industrial products and software products) usually have an actual
product manager who acts as
a focal point for these decisions.
In large companies, with a multiplicity of customers, this role can
be played by a small product
management team that represents
multiple parties but can provide
unambiguous information and
decisions to the project team.
Tool E4: Project Scope and
Constraints (Project Data Sheet,
Tradeoff Matrix, and Delay Cost)
A PDS is the second major

visioning tool in the evolution
of a project plan, as shown
back in Figure 3 on page 10.
A project data sheet is a
single-page summary of key
business objective, product
specification, and project
management information. It
is a document to help focus
the project team, management, and customers. The
PDSs simplicity belies its
power to convey quickly
these key project elements.
It is one of those simple
tools with a powerful

impact. Not only does its
condensed format appeal
to stakeholders who might
not be fully involved in the
project, and remind those
who are fully involved
about the most important
aspects of the project, it
also plays a part with those
who develop it. [8]
Sections of the PDS might include
some combination of the following, depending on organization
and project type:
n Clients/customers a list of
the key clients or customers
n Project objective statement
should be specific, short (25
or fewer words), and include
important scope, schedule, and
resource information from the
tradeoff matrix
n Features a list of the key
features
n Client benefits the key
benefits and/or selling points
of the product
n Performance/quality attributes a list of the key
performance and quality
attributes of the product
n Architecture key architectural components of the product (platform, component,
interface, module)
n Issues/risks factors that
could adversely impact this
project
VOL. 4, NO. 2
14
A project tradeoff matrix (TOM),

as shown in Figure 6, depicts
the key dimensions that create a
products value features, delivery schedule, defect levels, and
resources. The matrix indicates
the relative importance of each
dimension, and columns 1 and 2,
excel and improve, can each
contain only one entry. If the highest priority is features, then everything else takes second place.
Schedule might be designated as
second-highest priority (improve).
Similarly, the team would strive to
maintain acceptable defect levels
(within some specified tolerance
level; for example, 5 sigma).5
The TOM is a contract between
the project team and the customer, sponsor, and management
stakeholders. It is used to manage
change during the project. For
example, the lower-priority characteristics usually have a broader
tolerance, so if schedule is excel
and resources are accept, then the
team (within boundaries) already
5For more information on project envisioning
see Chapter 4 of [8].
Features
Schedule
Defects
Resources
Excel
X
knows that spending additional

funds is an acceptable adaptation
to keep on schedule. The TOM
also informs all stakeholders
that changes have consequences
and acts as a criterion for team
decisionmaking.
One other simple but powerful
tool that can assist teams in making project decisions is delay cost.
I once worked with a project team
for which the calculated delay
cost was nearly a million dollars a
day in lost revenue. Knowing this
cost drove much of the decisionmaking on the project and helped
ward off the constant flow of new
features from marketing. When
stakeholders insist that schedule
is the most critical element of a
project, having them calculate a
delay cost puts the criticality of
the schedule in perspective.
Tool E5: Exploration Factor
One issue in selecting project

management practices and
processes is the particular problem domain in which the project
team has to operate. Big projects
Improve
X
X
X
Figure 6 Tradeoff matrix.
VOL. 4, NO. 2
Accept
are different than small projects;

risky projects are different than
low-risk ones. It is important to
identify the various problem
domain factors, but it is even
more important to tailor processes
and practices to the problem and
to adjust expectations (measures
of success) accordingly.
To discuss problem domains,
Ive been using the concept of
an exploration factor, in which
a factor of 10 indicates a highly
exploration-oriented (high-risk)
problem domain and a 1 indicates a very stable problem environment. The exploration factor
derives from a combination of the
volatility of a products requirements and the newness and
thus uncertainty of its technology platform.
As shown in Figure 7, there are
four categories of requirements:
erratic, fluctuating, routine, and
stable. Erratic requirements
would be encountered in a situation in which the product goal
was understood but the business
or product requirements were
very new and untried. An example
would be a new product development effort in which features
were unfolding as the project
went forward. In this case, the
requirements might change drastically as the project proceeded, not
from poor requirements gathering,
but from evolving knowledge of
the product area. Fluctuating
requirements would be one step
down in uncertainty. While an
erratic problem space might
www.cutter.com
15
EXECUTIVE REPORT
experience 25%-50% or more
requirements change, a fluctuating one might be more sedate
at 20%-25%. Routine changes
would apply to a wide range of
projects in which up-front requirements gathering would yield a
reasonably stable baseline for
further work, while a stable
environment might be something
like a federally mandated change
to a payroll system that was well
defined and unlikely to change.
The technology dimension also
has four categories: bleeding
edge, leading edge, familiar,
and well-known. Bleeding edge
would involve a technology so
new that very few people have
experience with it. With bleedingedge technology, learning by trying is the only strategy because
no one else knows how to use it
either. Microsoft .NET might be
an example of bleeding-edge
technology. Leading-edge technology is relatively new, but there
are pockets of expertise to turn
to although price and availability might be an issue. Developing
middleware using J2EE might
be classified as leading-edge
technology. Projects employing
bleeding- and leading-edge technology have much higher risk
profiles than those using familiar
or well-known technologies.
One of the issues with many
IT projects initiated over the
past several years has been that
a large number have employed,
or tried to employ, new and risky
technologies.
Technology Dimension
Product
Requirements
Dimension
Erratic
Fluctuating
Routine
Stable
Bleeding Leading
WellEdge
Edge
Familiar Known
10
8
7
7
8
7
6
5
7
6
4
3
7
5
3
1
Figure 7 Project exploration factors.
Finally, Figure 7 combines these

elements of requirements volatility
with technology risk. For example,
an erratic requirements, bleedingedge technology problem space
receives an exploration factor
of 10, whereas a stable requirements, well-known technology
project receives a factor of 1. A
project with fluctuating requirements and leading-edge technology receives a factor of 7.
We can now discuss projects
from the perspective of the overall uncertainty of the problem
space. An 8, 9, or 10 project will
require a very agile approach
since the uncertainty and risk
are high. Short iterations, featuredriven planning, frequent reviews
with customers, and a recognition
that plans are very speculative are
imperative for solving problems in
this domain. In contrast, projects
with a 1, 2, or 3 rating will be relatively stable and low risk. Plans
should be more stable, iterations
could be somewhat longer, and

additional up-front requirements
gathering and design can be
cost-effective.
Without the recognition of different problem domains, one-sizefits-all project processes and
practices seem justified. With
such a recognition, customization
and tailoring to specific problems
will enable project teams to be
more successful.
Tool E6: Product Architecture
Product architecture may seem

like an odd tool to put into a project management toolbox, but a
products technical architecture,
together with the overall size of
the project, has significant implications for project management.
For example, if a team is building
a complex product with both
hardware and software components, the interface specifications
may have a major impact on the
VOL. 4, NO. 2
16
change management process.
Similarly, the component and
module organization may impact
outsourcing or distributed development decisions and how to
manage distributed groups.
In general, agile practices encourage change and adaptation;
however, certain changes have
significant impact on others and
require careful coordination. For
example, in automobile design,
the transmission and drive train
components have a certain welldefined interface. Changes within
the component that dont change
the interface can be handled less
formally than those that do affect
the interface. It is not a matter of
control who gets to make the
decisions as much as it is a
matter of coordination making
sure we understand the total
impact of a change and which
groups are affected. Poor technical
architectures make this change
coordination job much more difficult. Astute project teams will recognize when excessive time spent
on cross-component coordination
or integration is pointing to poor
architectural decisions that need
to be remedied.
In a very general way, technical
architectures utilize some combination of platform, component,
interface, and module architectures. A new sport utility vehicle
(SUV) may begin with a truck or
a car platform. A software product
may utilize a Windows or a Mac
platform, or both. Our SUV has
a body, drive train, engine, and
VOL. 4, NO. 2

many other components. A software component may have APIs
that specify how other components are to interact with it. A
multifunction PC device may
have printer, scanner, and faxing
components, each of which
has modules.
One of the reasons effective
project managers need technical
domain experience as well as
project management skills is that
technical architecture and project
organization and communications
cannot be separated. Poor technical structures can cause severe
organizational problems, just as
poor organizational structures
can sometimes result in poor
technical decisions.
Tool E7: Collaboration,
Communication, and
Decisionmaking Plan
Most project management

approaches include a communications plan. The PMIs A Guide
to the Project Management Body
of Knowledge includes project
communications management
as one of its key knowledge areas
[1]. However, communications is
not enough. Communications
is basically one-way I send
you information. Collaboration,
however, involves much more
than communication; it involves
interaction to produce some
joint result. Collaboration integrates your ideas and mine into a
whole. We communicate to management with status reports. We
collaborate among project team
members using practices such
as whiteboard brainstorming sessions. People on a project need

to understand each other: project
team members need to understand the customer; quality
assurance engineers need to
understand design engineers.
Understanding comes from a
combination of documentation
and interaction, and of the two,
interaction is the most important.
Throughout the product development world, in industry after
industry, the rising tide of crossfunctional teams speaks to the
need for collaboration for understanding. Communications
through documentation alone
has not proven to be effective.
So one of the project teams key
planning tasks is to put sufficient
collaboration practices into place.
The team needs to ask questions
such as: How will we collaborate
with customers? How will feature
team (subteam) members collaborate with each other? How will
the team in Atlanta collaborate
with the team in Seattle or the
team in Bombay?
Finally, the core of good collaboration is decisionmaking, a skill area
that project management texts
and institutions virtually ignore.6
A later tool (I3) will provide how
to details about decisionmaking
(see page 21), but the team needs
to address how decisions will be
made early in the project.
6For example, nowhere in PMIs A Guide to the
Project Management Body of Knowledge [1] is

there any reference at all to decisionmaking.
www.cutter.com
17
EXECUTIVE REPORT
Tool E8: Guiding Principles
This Executive Report includes

a description of both project
management tools and principles.
The principle Accelerate Throughput, for example, guides project
team members when they are
applying the tools. Applying the
Accelerate Throughput principle
to the previous Collaboration,
Communication, and Decisionmaking Plan tool would remind
team members to keep the plan
short and focus on critical issues.
Creating such a plan using another
principle might result in lengthy,
formalized documentation.
Guiding principles (GPs) guide
actual product development.7 GPs
arent measurable requirements
or constraints but conceptual
guides. For example, defining the
ubiquitous phrase user-friendly
may be very difficult. However,
a GP that states, The target user
for this product, an entry-level
medical technician, should be
able to use the basic features of
the product with minimal training
would help guide a development
team in its user interface design.
GPs may also be used early in a
project before specific requirements or design decisions have
been made. They may even allow
us to delay decisions until more
information has been gathered.
For example, early in a project,
the GP might be Maximize the
use of reusable components and
7One of my client colleagues introduced me
to this idea of guiding principles.
services to speed development.

That GP could then be used as
a factor in design; for example,
it might encourage the selection
of a platform framework such
as Microsofts .NET.
Although some GPs may be developed during project envisioning,
they often emerge over the life of
the project. Each principle should
be described in a sentence or
two, and the total number for a
project, at any one time, should
hover around 10.
Speculate (Plan)
The product of the speculate

phase is a release plan that outlines, to the best of the project
teams current knowledge, an
iterative plan that is based on
features delivered rather than
tasks. The release plan utilizes
information about the products
specification, platform architecture, resources, risk analysis, business constraints, cost budgets,
and schedules.
Traditional project managers may
perceive APM as promoting a lack
of planning. Actually, APM contains a significant amount of planning it is just different in type
and objective. Project planning
helps us:
n Think about the project, business goals, and customer
expectations
n Provide necessary budget
and schedule information
to management
n Establish priorities for tradeoff

decisions as changes occur
n Coordinate interrelated
activities and features
across feature teams
n Consider alternatives
and adaptive actions
n Provide a baseline for
analyzing events that
occur during the project
If the business world is as turbulent as we have told ourselves
over and over again, and agility is
the core competency that enables
us to navigate through these turbulent times, then one of project
(and business) managements
most cherished control mechanisms the plan is outdated.
Conformance to plan has been
the mantra of project managers
for decades it forms the foundation for project management
certification and is at the core
of how managers think. Its time
to alter that thinking. Rather than
conformance to plan, we need
to think about conformance to
vision and value. We need to
think of plans as guides, not
straightjackets.
Tool S1: Product Feature List
Few, if any, products begin from

scratch. Feasibility or marketing
studies identify product features
and performance characteristics.
Initial requirements-gathering
efforts contribute items to the
list of potential product features.
Product visioning exercises identify features. For existing products,
VOL. 4, NO. 2
18
customers, developers, product

managers, and customer support
staff are constantly making suggestions about product enhancements or minor maintenance
items. Part of a product managers
job is to constantly sift through
this list and sort it (with customer
involvement) into higher- and
lower-priority items. This list is
a major source of information
for Tool S4: Release, Milestone,
and Iteration Plans (see page 19).
One big difference between APM
and TPM projects is the volatility
of the features on this list. For a
more sedate project in which
the requirements are firmly
established in the beginning, this
feature list becomes the input for
a task plan that becomes relatively
fixed. In an agile project, the use
of the list is much more dynamic.
During the planning for every iteration, the list of features to be

included in that iteration can
change dramatically from the
original release plan.
Tool S2: Feature Cards
Feature cards (known as story

cards in XP) are used to identify,
but not to define, features. Feature
cards act as agreements between
customers and project team
members to have a discussion
about detail feature requirements
in the future. Feature cards identify features that the customer
wants in the product. For large
products, feature category cards
can be used to organize and plan
extensive feature lists. A category
card may encompass 10, 15, or
even 20 detail features.

Planned Iteration:
Feature cards are actual index

cards on which the project team
and customer representatives
record the information gathered
in their product requirements
discussions. The critical piece is
the discussion. As in other agile
practices, the core team, not the
project manager alone, is responsible for interacting and producing
the feature cards. Though there
can be some variations in what
information is placed on the cards,
Figure 8 shows one example.
Feature-driven development is not
a software-only technique. Many
hardware product development
efforts are driven by first developing a product structure and then
an extensive list of the features.
In addition, since more and more
products include embedded software, hardware and software features are both candidates for this
feature-driven approach. At the
lower levels of granularity, designers have to decide which features
will be implemented in hardware
and which in software.
Tool S3: Feature Breakdown Structure
Est. Work Effort:

Dependencies with Other Features:
Figure 8 A feature card.
VOL. 4, NO. 2
TPM plans utilize work breakdown structures (WBSs) to

organize the work. Although experienced project managers concentrate first on deliverables and then
on the work necessary to create
those deliverables, work- or taskdriven plans often degenerate
into very detailed, prescriptive
plans. Any product has a set of
features that customers use to
www.cutter.com
19
EXECUTIVE REPORT
some purpose. The more quickly

we can link those customers with
features they have requested and
get feedback on them, the more
likely the product development
effort is to be successful. Even
in the physical product arena
(as contrasted with software
products), prototypes and simulations of the final product are
critical to success.
Features arent documents about
features; they are product capabilities the customer can touch, feel,
and see. Documents are essential
to the product development
process, but they are often poor
indicators of real project progress.
All too often in TPM, deliverables
are documents, and the work
breakdown structures become
document delivery schedules.
Tool S4: Release, Milestone,
and Iteration Plans
When people first learn about

iterative development, they often
think in just terms of short timeboxed iterations. However, there
are two components to iterative
planning the short iterations
and the use of features rather
than tasks. Basing plans on
the products features (and its
architecture, which is instantiated
by features) keeps the project
team and the products customers
synchronized (because the customers understand the product
although they may not understand
the technical activities). It also
focuses the team on delivering
the product rather than intermediate documentation artifacts.

Its not that documentation
artifacts are not useful; no one
would consider building, say, an
airplane or an automobile without
extensive documentation. The
problem is not documentation
per se but that project teams often
get lost producing intermediate
artifacts that have little bearing on
the final product. Feature-driven
planning attempts to overcome
this problem.
Many project managers cant
fathom a 12-month project broken
down into two-week iterations
and in some ways this is understandable. Once projects go
beyond four to five months, they
usually need interim checkpoints
between two-week intervals and
the projects end. Larger projects
that employ distributed teams
or vendor-supplied components
will have problems synchronizing
every two weeks. So many projects will require three (or even
more) levels of iteration. The
longest period is the release cycle.
Products are generally released
to customers periodically once
every year or 18 months, for
example. As such, release
implies a release for customer use.
On the other end of the spectrum,
an iteration is used by a development team to focus on small
increments of work. In agile software development, an iteration
might be two weeks (XP), 30 days
(Scrum), or slightly longer for
some projects. If youre building

an airplane, the iterations will
surely be longer. Although continuous integration is desirable
for software development, all
features developed within a
feature team (usually fewer than
10 people that work on a group
of features) should be integrated,
and tested, by the end of the
iteration.
From a technical perspective,
milestones are intermediate
points usually from one to
three months. Milestones can
have both a project management
function and a technical function.
From a project management perspective, milestones provide a
chance to review progress and
make more significant project
adjustments. For example,
although most agilists recommend project mini-retrospectives
at the end of each iteration, most
would actually employ them
every two to three iterations if the
iterations were short (two weeks).
Milestones can also be used as
major synchronization and integration points. For a product that
has both hardware and software
components, monthly (or even
longer) synchronizations may
be entirely adequate. A software
product team utilizing an external
vendor for a component might
plan to integrate that component
starting at milestone two (two
months into the project) and at
every other milestone after that;
biweekly synchronization could
be too costly. On the other hand,
if less-frequent synchronizations
VOL. 4, NO. 2
20
are going poorly, it might indicate
that the synchronization should
occur more frequently.
Tool S5: Iteration 0
Some people think agile development gives them an opportunity

to dive in and build (or code, in
the software arena). They condemn agile methods, saying
they spend little or no time on
early requirements gathering or
architectural issues. On the other
hand, there has been an equally
negative reaction to months and
months of planning, requirements
specification, and architectural
philosophizing. There is obviously
a balance point, but many arguments imply there is no middle
ground. Iteration 0 is a tool to
help teams find that middle
ground. The zero implies that
nothing useful to the customer
features, in other words gets
delivered in this time period.
However, the fact that we have
designated an iteration implies
that the work is useful to some
other stakeholder.
A large business application project, one that must be integrated
with other business applications,
may require some data architecture work in order to adequately
define the interfaces with those
other applications. Teams utilizing
unfamiliar technology may need
time for training prior to the projects launch. A customer may
demand a more detailed requirements document prior to signing
a contract. All of these examples
VOL. 4, NO. 2

indicate a need for some time
expenditure prior to launching
into actual feature development.
Though the range of issues can
be broad, the outcome is the
same some projects require
more extensive initialization
work than others. The key to
effectively utilizing Iteration 0 is
to balance the possible advantages of further planning with
the growing disadvantage of lack
of customer-deliverable features.
There are always tradeoffs. If
the cost of a technical platform
change is very high, then additional work to improve the odds
of a correct decision may be
justified. Iteration 0 for a nextgeneration jumbo jetliner will
be much different than that for
a standalone software product.
Iteratively Deliver Features
Managing agile projects has

proven difficult for many traditionally trained project managers.
TPM deals with plans, tasks, PERT
charts, resource loads, and other
tools that impart a deterministic
flavor to projects. Surely, with all
of these charts and graphs and
sophisticated estimates, the project team merely has to execute
according to the plan, and all
will be well.
Exploration projects are full of
change, uncertainty, risk, and
ambiguity. Actually, most projects
exhibit these characteristics; we
just manage to sweep them under
the rug with all the traditional
project management tools. Probably the most difficult mental

switch for agile teams and agile
project managers is the switch
from a deterministic mindset to
an emergent one. A deterministic
mindset says, We KNOW how
to do everything lets get on
with it. An emergent mindset
says, We understand the vision, but the details are murky.
However, we believe that this
team will figure out the details
as the project unfolds. The
solution will emerge from the
collective knowledge and interactions of the team members.
APM requires a leadershipcollaboration management style
(see The Nine Principles of Agile
Project Management beginning
on page 30), one that encourages,
and believes in, the power of
emergent behavior. As such,
the key project management
tasks are establishing a vision
and constraints and then creating
a collaborative work environment
in which emergence thrives. The
tools in this section are focused
on the latter objective.
Tool I1: Daily Team
Integration Meetings
Normally the first agile tool implemented by my clients is the daily

team integration meeting. These
daily get-togethers (referred to
as Scrum meetings in the Scrum
methodology or daily stand-up
meetings in XP) focus on one
objective peer-to-peer information exchange. Daily software
www.cutter.com
21
EXECUTIVE REPORT
builds are used to raise the visibility of development work and
ensure that code modules integrate. Daily Scrum meetings
serve the same purpose for
people raising the visibility of
each persons work (to facilitate
knowledge sharing and reduce
overlapping tasks) and ensuring
that their work is integrated. If
daily builds are good for code,
then daily builds should be
even better for people [9].
The daily integration meeting
enables the team to monitor
status, focus on the work to be
done, and raise problems and
issues. The meetings:
n Are held at the same time
and place every day
n Last less than 30 minutes (the
target should be 15 minutes)
n Are attended by all core team
members
n Can be attended by managers
to keep track of status but
not to participate
n Are used to raise issues and
obstacles but not to pursue
solutions
n Allow each participant to
address three questions:
What did you do yesterday?
What are you planning to
do today? What impediments
got in the way of your work?
right people to team up to resolve

issues. As with any other tool in
the APM toolkit, meeting time,
frequency, and attendees will
need to evolve for different situations. One such adaptation might
be for the core delivery team
members to meet daily, while
members from support functions
join in weekly.
Tool I2: Daily Interaction
with Customers
One of the key tenets of agile

project management is close
interaction with customers. When
dealing with uncertainty, risk, fluid
requirements changes, and technological frontiers, customers
(and sponsors) need to be fully
involved in identifying features,
specifying feature requirements,
determining feature priorities,
making key tradeoff decisions
(cost, schedule, etc.), developing
acceptance criteria and tests, and
more. Being a customer for an
agile project is not an insignificant
job, but it may not need to be full
time. The key to keeping the project moving is very frequent, if not
daily, interaction in which the
project team receives a constant
flow of information and decisions.
Interaction with customers may
be important to other types
of projects, but it is absolutely
essential with agile projects.
Tool I3: Collaborative Decisionmaking
Most team members find these

short meetings to be efficient and
effective. They eliminate the need
for other meetings and help the
That one decision-gradient diagram was the most important

piece of the two-day consulting
session, said a product development VP client recently.

Its difficult to speed up development when management takes
weeks to make key decisions,
laments a Dublin, Ireland, development group whose company
executives are in Silicon Valley.
Our project managers are like a
herd of deer standing on the highway with a tractor-trailer truck
bearing down on them, says one
project team member. They cant
figure out which way to jump, but
if they dont decide soon, were
going to get run over.
As I trek around the world of software development and project
management, Im continually
amazed at how little organizations
think about their decisionmaking
processes. Many of them put
more time and energy into a
software build process than
into decisionmaking. However,
in a fast-paced agile project,
decisionmaking like other
activities must be done quickly
and effectively. Slow decisionmaking, revisiting decisions again
and again, overanalyzing decisions, and poor participation in
the decisionmaking process will
doom a project, as poor decisions
cascade into a flood of additional
decisions.
No doubt, decisionmaking is hard,
but it is made harder than necessary by poor practices. Although
rational decisionmaking may be
a fantasy, there are practices that
VOL. 4, NO. 2
22
can assist project teams in making

better, implementable decisions.
Three elements key a decision
process: collaborative framing,
collaborative decisionmaking, and
decision retrospection. Framing
establishes who gets involved
in the process, while collaborative
decisionmaking establishes how
the whos go about making a
decision. Decision retrospection
provides feedback into the
decisionmaking process.
or milestone. Replanning often

involves making tradeoff decisions schedule versus cost
versus features. To take another
example, software projects
should include a defect triage
decision framework basically
asking and answering the question, Is this product shippable?
For each decision type, framing
questions are:
Collaborative framing. First,

forget about the word empowerment. The intention of
empowerment is to delegate
decisionmaking authority to lower
levels of organizations. For the
most part, empowering involves
lots of verbiage and little action,
because the fundamental hierarchical, command-control management structure remains firmly
in place. Empowerment focuses
on who makes decisions. Collaborative framing focuses on who
gets involved in decisions.
Managers who make decisions
without input from subordinates
and peers make poor decisions.
Engineers who make decisions
without input from managers
and peers make poor decisions.
Who makes the decision is less
important than getting the right
people involved in the decision.
n Who needs to provide input

to the decision?
The first task in framing decisions

involves identifying types of decisions that need to be made over
the life of a project. For example,
in an agile project, replanning
occurs at the end of each iteration
VOL. 4, NO. 2
n Who is affected by the

decision?
n Who should be involved in the

discussions about the decision?
n Who should make the decision
(the manager, the project
manager, the project team,
the project manager with
the team, etc.)?
n Who should review the
decision?
n What decision criteria should
be used?
n How and to whom should
the decision results be
communicated?
The answers to these questions
will involve overlapping groups.
For example, there may be a wide
group of people affected by the
decision, but only selected individuals from those groups may be
contacted for input. Everyone who
provides input to a decision may
not be involved in the discussions
about those decisions. There may
be an entire set of decisions that
bore project team members,

and thus they dont want to be
involved, while they do want to be
heard on other decisions. Sorting
out the various involvements
should not be left to chance.
Staff members often feel isolated
from decision processes, not
knowing when, why, or how decisions got made. Making decisions
is only part of implementing them.
Rapid, effective implementation
requires a collaborative process
that involves the right people,
who possess the relevant information, gathered together at the
right time.
Many companies and project
managers spend far more time
on development processes than
decisionmaking giving rise to
the analogy of a racecar engine
running on increasingly viscous
sludge. Both will grind to a halt.
Framing is the first step in getting
the sludge out of your decisionmaking process.
Collaborative decisionmaking.
Collaboration is hard. Seemingly
interminable meetings are often
struggling in the groan zone,
Sam Kaners wonderful term for
the time period in which meeting
participants struggle to understand each other. Though many
people have heard of the famous
team progression process forming, storming, norming, performing (or, more aptly at times,
forming, storming, thrashing,
crashing), Kaners model
consists of the divergent zone,
www.cutter.com
23
EXECUTIVE REPORT
the groan zone, and finally the
converging zone [12].
In many organizations, decisionmaking is viewed as a win-lose
proposition. Participants in the
process have a preconceived
view of the decision, and their
approach is to argue as loudly as
possible until the opposition gives
up. Collaborative decisionmaking
focuses on win-win or as Kaner
says, both/and rather than
either/or. Win-win decisionmaking focuses on mutual
understanding rather than loud
posturing. This shouldnt imply
lack of heated discussion, but a
discussion focused on trying to
understand the underlying issues
rather than debating preordained
positions. Collaborative decisionmaking can be contentious but
civil, based on mutual trust and
respect it moves teams beyond
compromise. I am indebted to
Cutter Business Technology
Council Fellow Rob Austin for
the term reconceiving to replace
compromise. Collaborative
decisionmaking is a process of
reconceiving a solution to a problem based on information from
all team members. Compromise
implies giving up one idea for
another; reconceive implies a
joining of ideas.
There are two objectives against
which any decisionmaking
process must be judged. First,
does the process result in the best
choice given the circumstances
in which the decision was made?
Second, was the decision implemented? As many project managers have found out the hard
way, making and implementing
decisions are two different things.
How many times have you
encountered decisions made
within the confines of a conference room that completely fall
apart when the participants walk
out the door? Kaner refers to sustainable decisions those that
actually get implemented. Anyone
can make a decision, but effective
managers grasp that implementation requires people to understand
and support the decision.
A collaborative decisionmaking
process has three components:
principles, framework, and practices. The fundamental principles
have just been alluded to: viewing
the process as a win-win process
and treating all participants with
respect. All collaborative practices
are based on trust and respect, or
perhaps more precisely, on building trust and respect. Kaners
diverge-groan-converge model
provides the framework. Practices
run the gamut from facilitation
tricks to decision gradients.
In the diverge-groan-converge
framework, the transition from the
divergent zone to the convergent
zone explains how team members move from having individual
opinions to having a unified
position. At first, peoples ideas
diverge. Even though each person
wants to contribute to success
and to make a quick decision,
each wants to voice his or her

own opinion. Everyone has a
different perspective or a different
experience, which brings needed
diversity to the decision process
but not much agreement.
Convergence occurs as the
groups individual ideas are
integrated into a whole solution.
Convergence, done correctly,
does not necessarily mean that
everyone is in complete agreement but that everyone has participated and will support the final
decision. The goal is not merely
agreement, but sustainable
agreement a unified position.
The transition period between
divergence and convergence, the
groan zone, is the time during
which team members groan and
complain. In the divergent zone,
most group members voice their
opinions to make sure their own
ideas are heard by the group.
Much of this time could be considered presentation, during
which members are less concerned with understanding
each other than with selling their
own ideas. They begin to groan
because they are trying to understand one another, and understanding requires thought. It is
relatively easy to take a position
and argue for it. It is much more
difficult to attempt to understand
why other participants hold other
opinions. The groan zone provides
a perfect description of what
happens in most teams it is a
VOL. 4, NO. 2
24
turbulent zone where innovative,
creative results are generated.
An additional benefit to a collaborative process such as the one just
described is that as mutual understanding of the context (including
the decision criteria) increases,
the time required to make similar
decisions decreases rapidly. For
example, a defect triage team that
develops a shared understanding
of the relevant factors involved
in reaching decisions will speed
up its decisions over time. Conversely, teams that do not take
some additional time in the beginning to fully understand for
example, to understand each
others perspective on quality
will constantly argue the same
points meeting after meeting.
Different kinds of decisions
require different processes. Coin
flipping works for deciding what
time to go to lunch. Project managers must often make decisions
without explicit group discussion.
However, the key decisions that
impact the project team will be
better served by a collaborative
decision process.
Decision retrospection. If project
retrospectives are difficult to do
in general, decision retrospectives border on the impossible,
because finding whom to blame
often seems more important
than learning. But how do we
get better at decisions unless
we understand which ones
worked out well and which ones
didnt? We are sometimes our
VOL. 4, NO. 2

own worst enemies. In the medical profession, for example, airing
mistakes is especially difficult
because of the threat of medical
malpractice suits. Sharing and
learning from decisions become
severely inhibited; therefore, the
same mistakes are repeated by
other doctors or other hospitals
because little retrospection
occurs. A recent television program described an initiative in
the northeastern US in which
this veil of secrecy was lifted in a
concerted and collaborative effort
between doctors and hospitals.
Not surprisingly, problem rates
decreased.
Still, few organizations want to
examine decisions in any depth,
which probably corresponds to
the general lack of interest in
decisionmaking. Was a buggy
product shipped? Why? What was
the series of decisions that led up
to the ship decision? Maybe the
decision was actually a good
one from a market perspective.
If so, then the development staff
needs to understand the nature
of the decision, why it was made,
and who was involved in the
decision. Maybe the decision was
based on market timing information, but the decisionmakers just
didnt listen to the developers,
and the actual release was a
disaster. If the disaster isnt analyzed, if the decision tradeoff of
product stability versus market
need isnt revisited, then nothing
will be learned, and similar mistakes will be made in the future.
Or a decision may be perceived

as incorrect, but further analysis
shows that it was actually the correct one give the circumstances.
In this case, lack of analysis might
keep us from making the same
correct decision in the future.
Collaborative decisionmaking may
spell the difference between success and failure on agile projects.
Framing decisions, developing
a collaborative decisionmaking
process, and conducting decision
retrospectives to learn from both
success and failure are required
components of this practice.
Tool I4: Set- and Delay-Based
Decisionmaking
Point-based engineering dominates product development. Pointbased engineering views design

as a series of serial decisions in
which each decision narrows the
options for further decisions, and
the product progresses in a steady
fashion from a gleam in the marketers eye to a final product.
Toyota upset this applecart, at
least as it pertains to the automotive industrys design process.
Toyotas approach, set-based
concurrent engineering (SBCE),
provides an insight into software
design. SBCE operates on two
fundamental concepts: postpone
design decisions as late as possible and maintain sets of design
solutions throughout the majority
of the design process.
www.cutter.com
25
EXECUTIVE REPORT
SBCE assumes that reasoning
and communicating about sets
of ideas leads to more robust,
optimized systems and greater
overall efficiency than working
with one idea at a time, even
though the individual steps may
look inefficient, write Durward K.
Sobek, Allen C. Ward, and Jeffrey
K. Liker [17]. Rather than converge on a design answer,
Toyotas engineers maintain sets
of designs. For a particular car
project, they might maintain
six alternative solutions for the
exhaust system design, including
prototypes and mockups.
Unlike point requirements, setbased requirements focus on
ranges or minimum constraints.
So the body design group would
impose a range of criteria on
the exhaust system, keeping the
tolerances as broad as possible
in the beginning and narrowing
them over time as the car
approaches manufacturing. As
the body design and exhaust system designs evolve, engineers are
more likely to balance subsystem
optimization with overall vehicle
optimization. In a point-based
approach, each subsystem team
has a greater tendency to create
optimized designs for its particular subsystem.
Using a process very different
from its US counterparts, Toyotas
slow narrowing of options extends
to actual die making. Rather than
specify precise part fit, designers
specify looser tolerances. The die
makers themselves create the
parts, see how they actually fit

together, and then send the precise measurements back to the
design groups to finalize the
detail computer-aided design
(CAD) drawings.
today, what would the best design

now look like? Just as set-based
concurrent engineering may look
inefficient, refactoring may also.
Over the life of the project, however, both prove their worth.
Engineers, whether of automobiles or software, tend toward

point-based solutions they
analyze the problem, understand
the constraints, and then design
the solution. But there are
always multiple design options,
and the larger the product or
product family, the more likely
that early design decisions will
lock the team into suboptimal
solutions. Maintaining multiple
sets of solutions and delaying
final design decisions, even
though it may appear to be inefficient, may in fact be faster and
more efficient in the long run. As
Sobek and his coauthors observe,
Toyota considers a broader range
of possible designs and delays
certain decisions longer than
other automotive companies do,
yet has what may be the fastest
and most efficient vehicle development cycles in the industry.
Software engineers and architects

may want to practice both refactoring and set-based design.
Coming up with several design
options for the database, layers of
architecture, placement of components, middleware options, and
so on (particularly in embedded
software situations in which there
are tradeoffs between hardware
and software features) can be
beneficial. Furthermore, refining
these options over time rather
than selecting one or another
early on may lead to better decisions. Once decisions are made,
refactoring helps to refine those
decisions or possibly revisit them.
Refactoring leads us away from
point-based engineering, but it
doesnt explicitly direct us into
set-based thinking. Using the
two methods in combination
can be very powerful in complex
software product design.
Even software engineers who do

iterative, concurrent development
usually practice what Sobek and
his colleagues call point-based
concurrent engineering. These
engineers make short-cycle
design decisions, but they do not
maintain multiple options. In a
way, refactoring forces developers
to revisit designs and consider
new options. Refactoring says,
With the new information I have
Tool I5: Project Information Display

(Product Data Sheet, Risk List,
Issues, Vision Box)
Agile projects are open projects,

meaning that project information
is widely shared among all team
members and with customers and
other stakeholders. Project teams
need to have key information
readily available and communally
shared. Communal information
VOL. 4, NO. 2
26
ties teams together. It needs
to be visual and prominently
posted either on walls or a
whiteboard for colocated teams
or on a common virtual whiteboard for distributed teams.
Visual displays of project information need to concentrate on
vision, focus, scope, and issues.
Often teams get so caught up in
details that the big picture gets
lost. Intense arguments over
details can often be resolved by
reviewing the product vision information or the guiding principles.
Risk and issue lists keep these
things in the team members consciousness so they are constantly
thinking about solutions.
Meetings are the bane of many
organizations, especially for those
who do not differentiate between
meeting types. Collaboration
meetings to create joint designs
or gather requirements should be
different from those that convey
status. Project information displays should reflect the results
of key collaborative efforts (the
vision box) and project status. To
the extent these presentations
are effective, they can minimize
status review meetings.
Tool I6: Mood Management
No, you didnt read the heading

wrong; it does say mood management. I was working with a
project team last year that was
under enormous stress tight
delivery deadlines, constantly
changing requirements, and
VOL. 4, NO. 2

intense pressure because of the
revenue implications of the projects outcome. The team leaders
and many staff members thought
the ambiguity and change within
the project should somehow be
mitigated, that the environment
should be less chaotic and more
stable. I pointed out that this kind
of project was always borderline
chaotic and, furthermore, that
attempting to stabilize it
although it might make everyone
feel better was unlikely to lead
to successful completion.
One thing I did, which ultimately
helped the situation, was to show
the team leaders how they were
making the situation worse by
reflecting, rather than absorbing,
the teams frustration. Each time
a team member would come to
a team leader and say something
like, Wow, things are really
screwed up, the leader would
counter with, They sure are,
and I wish someone would fix
it. This exchange magnified the
frustrations. Though the team
leaders needed to acknowledge
the reality of the situation, they
also needed to respond positively,
to defuse the situation by remaining calm themselves. Just my
telling the team leaders that a
degree of ambiguity and frustration was a natural part of this
type of project helped reduce
their anxiety and kept the emotion
and frustration level below a
constant crisis level.
Recent management research is
showing that mood or emotional
intelligence in leaders has a

much larger impact on performance than we may have imagined. The leaders mood and
behaviors drive the moods and
behaviors of everyone else. A
cranky and ruthless boss creates
a toxic organization filled with
negative underachievers who
ignore opportunities, say Daniel
Goleman, Richard Boyatzis, and
Annie McKee [5]. These authors
describe how a leaders emotional intelligence is contagious,
racing through an organization
like electricity through wires.
Researchers at the University of
Michigan found that in 70 work
teams in diverse industries, team
members picked up the same
moods within a couple of hours.
Project teams are groups of
people, people who respond to
emotions and whose emotions
may have wide swings from
despair to euphoria over the
life of a project. Encouraging
appropriate moods can help create group interactions conducive
to generating emergent results.
Monitor and Adapt
Monitoring attempts to answer

the three critical questions posed
earlier: Are we getting customer
value from the project?; Is the
project progressing satisfactorily?;
and Is the project team adapting
effectively to changes imposed
by management, customers,
or technology?
At the end of each milestone,
and for some practices such as
www.cutter.com
27
EXECUTIVE REPORT
customer focus groups (CFGs) at
the end of every iteration, a brief
period for review, reflection, and
adaptation should be observed.
There are four basic items to
monitor: the product via some
type of customer review, the technical quality, the projects status,
and the teams performance.
A team that rushes to deliver
features but creates buggy code
should be refocused by a good
technical review. A creeping
degeneration of the overall design
should give rise to a refactoring
task in the next iteration. Cost
overruns should be highlighted
by the project status review and
appropriate action taken. The final
item is the teams evaluation of
itself and the team members
identification of adaptive actions
to take.
Tool M1: Customer Focus Groups
The basics of a CFG are easy;

the implications are more difficult.
A customer focus group
review brings together
developers and customers
in a facilitated session,
the objective of which is
to document requested
changes to the reviewed
application. Customer focus
group sessions are the
single most important
technique for developers
to get close to the customer
and thereby build good
customer relationships.
Like JAD [joint application
development] sessions,
customer focus groups

are special meetings
with specific objectives:
n Each session is a review
of the product itself, not
of documents about the
product.
n Each session is designed
to help participants find
and record customer
change requests.
n Each session requires
that participants adopt
roles, such as facilitator.
n Each session stipulates
that developers act as if
they are behind one-way
glass that is, they are,
in general, to be seen,
not heard. [8]
CFGs are not like day-to-day
prototyping sessions with onsite
users. CFGs are used at the end
of iterations and milestones to
involve a wider range of customer
representatives. In the shoe development process, for example,
designers work with ideas,
sketches, and then more formal
CAD drawings. At several points
in the process, the designers takes
their ideas over to the lab where
technicians build mockups of the
shoe. These mockups are wearable, usable shoes built in very
small quantities. At the end of
a milestone, the shoes can be
shown to marketing staff for their
feedback or even to a selected
group of target customers. Software CFGs demonstrate how the
various features will be used

in the customers environment.
CFGs are particularly useful in
distributed development scenarios
in which daily contact between
development teams and customers is difficult. Frequent
CFGs can keep the project from
wandering very far off track.8
Tool M2: Milestone Retrospectives
(Monitor Teams Agility)
Another fundamental tenet of

APM is that projects are different
and people are different and
thus teams are different. Therefore, we should not try to shoehorn every team into the same
set of processes and practices.
Project teams should work within
an overall framework and guidelines (such as this APM framework and its associated guiding
principles), but they should be
able to adapt their practices to
meet their unique needs.
Many project management
methodologies recommend
doing retrospectives at the end
of a project. This may be fine
for passing learning on to other
teams, but it doesnt help improve
performance during a project.
Milestone retrospectives of even
an hour or two give teams an
opportunity to reflect on what
is working well and what isnt.
8For a detailed examination of customer focus
groups, see Customer-Focused Development:

The Art and Science of Conversing with
Customers, Cutter Consortium Agile Project
Management Executive Report, Vol. 2, No. 4,
April 2001.
VOL. 4, NO. 2
28
For teams that are new to using
agile practices, a questionnaire
can help them measure their
agility rating.9
Tool M3: Milestone/Iteration
Technical Review
Early renditions of rapid application development often

circumvented technical quality,
as speed was touted above all
else. Timeboxing, for example,
was inappropriately used to
force teams into delivering poorquality, high-defect software.
One of the APM principles is to
champion technical excellence,
and APM proponents would argue
that, in fact, speed and quality are
not conflicting but complementary
objectives. Producing buggy,
poorly designed features at
the end of an iteration does
not constitute delivery.
Technical reviews, informal
ones at least, occur continuously
during an iterative delivery
cycle. However, at periodic
intervals and at least once per
milestone the technical team
should take time to reflect on
the overall technical quality of
the product and make recommendations about redesign, refactoring, additional testing, more
frequent integration, or other
technical remedies.
9The best reference book on conducting
retrospectives is Project Retrospectives:

A Handbook for Team Reviews by
Norm Kerth [14].
VOL. 4, NO. 2

Tool M4: Milestone/Iteration
Project Status Review
Engineers want to engineer.

Scientists want to research. These
individuals want to accomplish
what they define as productive
work, and whats more, they are
probably right. Status meetings,
management presentations,
creating information for accounting reports, and a raft of similar
activities drain valuable time from
delivering product. At the same
time, management and customers
are spending money for some
product, and they arent receptive
to being told, Just wait six
months until we are finished.
Managers have a fiduciary responsibility, and they need periodic
information to fulfill that duty.
Furthermore, customers and
sponsors need information to
make tradeoff decisions. Is the
prognosis for the product such
that it is no longer economically
feasible? Should features be
eliminated to ensure the product
release schedule is made? The
project team needs to generate
information to answer these kinds
of questions.
Tool M5: Adaptive Adjustments
Traditional project managers are

usually asked to compare actual
progress to plans and to take
appropriate corrective actions.
The PMBOK defines corrective
action as anything done to bring
expected future schedule (cost,
etc.) performance in line with
the project plan. The very term
corrective action is based on

the assumption that the plan
is correct and the actual performance lacking.
The term adaptive adjustments
conveys a different sense. There
are really three data points at any
iteration or milestone boundary:
Where are we? Where did we
plan to be? Where does our
current information indicate we
should be? Adaptive adjustments
run the gamut, from minor tweaks
to the next iterations planned
features, to adding resources, to
shortening the projects schedule
(with appropriate feature adjustments). Adaptive adjustments can
impact technical activities for
example, allocating more time for
refactoring or modifying delivery
processes to make them more
effective. Any of the four review
types product, technical, project status, team can result in
adaptive adjustments.
APM is more realistic than TPM
when it comes to scope management. Scope creep isnt the problem, even though many TPM
practices lament the problems
with escalating scope. Reality is
more complex than an admonition to avoid scope creep can
handle. Some scope changes are
inexpensive but valuable. Some
scope changes are extensive and
expensive but crucial to delivering
customer value.
At XP2002 in Italy, Jim Johnson
of the Standish Group presented
some interesting information
www.cutter.com
29
EXECUTIVE REPORT
related to scope. First, Johnson
discussed two federally mandated
state child welfare projects
one in Florida and the other in
Minnesota. The Florida project
was begun in 1990 with an original budget of US $32 million, a
staff of 100, and a delivery date
of 1998. As of the last review,
the project was estimated at
$170 million and expected to be
completed in 2005. The Minnesota
system, with the same basic goals,
began in 1999 and finished in
2000 with a staff of eight who
expended $1.1 million. Admittedly,
many factors could be responsible
for the differences, but a significant portion of the difference
was attributed to gold plating
requirements.
Traditional up-front requirements
gathering often leads to requirements bloat. Johnson reported
on two other studies, one by
DuPont and another by the
Standish Group. In the first,
DuPont estimates that only 25%
of the features implemented are
actually needed. The Standish
study estimates that 45% of software features are never used, and
only 20% are used often or always.
If you were able to cut project
sizes in half, and project teams in
half, wouldnt that greatly speed
development and reduce costs
at the same time?
Its ironic that many traditional
requirements gathering practices
decry the dreaded feature creep
as a major problem in software
development. I would contend

that its faster and cheaper to
let features evolve over the life
of the project (within some limits
of course) than to hallucinate
about what the requirements are
in the beginning and then build
them without constant customer
involvement.
Agile development is about focus
and balance focusing on the
projects key vision and goals and
forcing hard tradeoff decisions
that bring balance to the product
requirements. Agile development
plans by feature, not by task.
These features are described in
customer terminology, thereby
focusing the planning process
on something the customer
can relate to and prioritize more
easily. Because plans are adjusted
each iteration based on actual
development experience, not
someones guesses or wishes,
nice-to-have features are pushed
into later iterations and often
eliminated completely.
However, scope evolution
should always be driven by
business value. One stakeholder
might want to change the products platform, but the cost may
be too high. One stakeholder
might want to change the interface between two components,
but the time loss may be
too great. A products scope
should be driven by customer
value, technical feasibility and
cost, the impact on a products
adaptability, and critical business
schedule needs. It should not be

held hostage to a plan developed
when our product and project
knowledge was still in its infancy.
The short iterations in agile
development, combined with
end-of-iteration customer reviews,
force the entire team developers, customers, and managers
to face reality. We can take a
requirements document and
estimate how long it will take
to develop and test the code, or
we can build a small set of features and measure what it actually
took to develop them. Yes, we
estimated that we could implement 25 features this iteration,
but in reality, we only delivered
15. Now what? We now have to
address the possible tradeoff decisions drop features, add staff,
extend the project time. However,
we do this early in a project when
there is still time to compensate.
Traditional approaches delay
these difficult decisions until the
point where adaptive action is
nearly impossible. Short-time
reality checks keep feature-itis
from getting out of hand.
Short iterations also keep developers focused. With a deadline
approaching every four weeks,
the tendency to enhance features diminishes. The prioritization
previously discussed focuses
on reducing the number of features undertaken. Short iterations
then act to limit the size of those
features.
VOL. 4, NO. 2
30
Close
Organizations have a tendency

to spend too much time initiating
projects and too little time closing
them. In a recent client engagement, I encountered the failure
to close problem again. The
clients of IT development in this
organization considered IT delivery to be less than stellar, partially
because they thought some projects had been underway for years.
In reality, the application in question had been installed for several
years, but ongoing enhancement
releases were not differentiated
from each other. There was no
ceremony to the escape of
development efforts into production, and often the releases were
a complete surprise to the clients.
So from the clients perspective,
the project just went on and on.
With resources scarce, people
are moved on to the next project
quickly, often without taking time
to close up the last project and get
credit for its completion. There
are several activities involved in
closing a project, most of which
dont take much time but really
pay off. First and foremost is a
celebration. A celebration serves
two primary purposes. One, it
shows an appreciation for all
those who worked on the project
and who often put in long hours.
Product companies seem to be
much better about celebrating
than IT organizations. Tight budgets are often limiting, but its
false skimping. Two, by including
key clients in the celebration, it
VOL. 4, NO. 2

helps declare that this particular
project is over, done, accomplished. It provides a sense of
closure. Projects (or a series
of projects couched as one)
that go on and on without any
closure are hard on morale.
A second, although much less
glamorous, activity in closing projects is to clean up all open items,
finalize documentation and production support material still open
(I know it should have been completed by now, but we know what
happens in reality), and prepare
whatever end-of-project administrative and financial reports are
required.
The third item on the list is
described in every project management book but rarely done
well in organizations the project
retrospective. If teams have been
doing iterative development, they
will, one hopes, have been doing
mini-retrospectives each iteration.
These minis are for the project
team to learn about their own
processes and team dynamics
as the project progresses. They
are intra-team learning activities.
The retrospective at the end is
for inter-team learning, for one
project team to pass along to
others in the organization what
went well and what went bump
in the night [14].
Companies often confuse products and projects. Products are
ongoing, while projects have a
finite lifespan (at least the good
ones do). Differentiating between

projects and products closing
projects and getting recognition
and closure is an important
but often overlooked aspect
of good project management.
THE NINE PRINCIPLES OF
AGILE PROJECT MANAGEMENT
Principles impact how tools and
practices are implemented. Tools
are how principles are acted
upon. Grand principles that generate no action are vaporware,
while specific tools, in the
absence of guiding principles,
are often inappropriately used.
In the following section, I describe
the nine principles of agile project
management. Although the use
of tools may vary from project
team to project team, the principles are constant. Principles
are the simple rules, the generative rules, of complex human
adaptive systems.
1. Deliver Something Useful
Although this may appear to be a

simple principle, one nearly too
simple to be articulated, it is one
that many project teams forget.
As organizations get bigger, as
administrivia increases, as compliance activities take a larger
and larger portion of a teams
time, as the communications
gap between customers and
project team members widens,
and as project management plans
focus on interminable intermediate artifacts, delivering something
useful to the customer gets lost.
www.cutter.com
31
EXECUTIVE REPORT
Agile teams constantly seek high
levels of customer involvement
and are always asking the question, Is what we are doing useful
to you in your business goals?
2. Cultivate Committed
Stakeholders
Though delivering something useful to the customer stakeholder

remains paramount, keeping all
the stakeholders informed and
involved is critical to success.
After all, the term customer can
be ambiguous. To some, customer
means the buyer, while to others,
customer means the ultimate user
of the product or results. Senior
management will usually have different project objectives than the
project sponsors. For IT projects,
the project sponsor may be a marketing executive who focuses on
features and business value, while
IT management may constrain the
project with architectural or platform requirements.
The success of any product
involves meeting expectations
those of the ultimate customer,
those of other management stakeholders, and those of the project
team itself. There is a large gap
between requirements and
expectations requirements
are tangible, but expectations are
intangible. Yet ultimately, it is the
intangible expectations against
which actual results will be measured. Cultivating committed stakeholders means involving them in
dialogue about both requirements
and expectations.
3. Employ a LeadershipCollaboration Management Style
Admiral Grace Hopper once said,

You cannot manage men into
battle: you manage things ... you
lead people. What is the difference between project management and project leadership? Tap
into the management literature on
leadership and there seems to be
an endless, but often elusive, line
between leadership and management. While both leadership and
management are critical to projects, to paraphrase leadership
expert John Kotter [15], Most
US software projects are
overmanaged and underled.
Management is about coping
with complexity.... Leadership,
by contrast, is about coping with
change.
Without adequate management,
complex projects rapidly descend
into chaos. Plans, controls, roles,
budgets, and other practices help
project managers to stave off
this potential project-threatening
complexity. However, when
uncertainty, risk, and change are
high, mere conformance to plans
and budgets wont suffice. As
Kotter says, More change always
requires more leadership.
Kotter contrasts the activities
of management and leadership:
planning and budgeting versus
setting a direction; organizing
and staffing versus aligning
people; controlling and problem
solving versus motivating and
inspiring. Project managers who
are effective at delivering in complex situations by planning in

detail, creating organizational
positions and roles, monitoring
through detailed budget and
progress reports, and solving
the myriad day-to-day project
problems dont like change.
Change leads to paradox and
ambiguity, and these managers
spend enormous energy trying
to drive ambiguity and change
out of their projects.
Leaders, on the other hand, are
trying to change things by creating a vision of future possibilities
that are probably short on details;
by interacting with a large network of people inside, and often
outside, the company in order
to sell their idea and discover
new information that will help
turn the vision into reality; and
by creating a sense of purpose
in the endeavor that will motivate
people to work on something
outside the norm.
Projects, like organizations,
need both leaders and managers.
Unfortunately, it is often difficult
to find both skill sets in the same
person. Furthermore, since creating a project budget is more
tangible than, say, resolving the
ambiguity that arises between
trying to satisfy conflicting customer groups, training tends to
focus on tangible practices and
tools. Growing leadership skills
in managers is clearly possible,
but it requires a dedication to
VOL. 4, NO. 2
32
understanding the differences
between the two activities.
Agile project managers help
their team balance at the edge
of chaos some structure, but
not too much; adequate documentation, but not too much;
some up-front shape architecture
work, but not too much; and so
on. Extreme projects are full of
anxiety, change, ambiguity, and
uncertainty. Traditional project
management approaches attempt
(unsuccessfully) to drive those
characteristics out of their projects. However, those are characteristics of the problem space
that the project team must deal
with. It is organic and quantum,
not deterministic and Newtonian,
project management. It takes a
different style of project management, a different pattern of operation for the project team, and a
different type of project manager.
As authors Phillip Hodgson
and Randall White observe,
Leadership is what crosses the
frontier between what we did yesterday and what well do tomorrow. Well argue that the real
mark of a leader is confidence
with uncertainty the ability to
admit to it and deal with it [10].
The authors pose six questions
that illustrate the damaging
illusions of our 20th-century
approaches to management:
1. Why do you believe you are
in control?
VOL. 4, NO. 2

2. Why do you behave as if you
can predict the future, its consequences, and outcomes?
3. Why do you think that because
youve done it before and it
worked that it will work again?
4. Why do you believe everything
important is measurable?
5. Why do you think that words
like leadership, management,
and change have the same
meaning for everyone?
6. Why do you think that reducing
uncertainty will necessarily
increase certainty?
Part of being agile, in fact a large
part of being agile, is attitude
an attitude that leads one to
seriously consider each of these
questions anew. APM requires
that we address our fundamental
management style, moving from
command-control to leadershipcollaboration.
4. Build Competent,
Collaborative Teams
First, Break All the Rules, a book

by Marcus Buckingham and Curt
Coffman, compiles the authors
experiences interviewing 80,000
managers in 400 companies over
25 years and attempts to answer
the question of what makes good
managers [2]. The fundamental
premise of the book is that the
only way to generate enduring
profits is to begin by building the
kind of work environment that
attracts, focuses, and keeps talented employees. And therefore,
the question is, How do the

worlds greatest managers find,
focus, and keep talented employees? The authors didnt interview
80,000 managers and average the
results; they picked the greatest
managers and found that their
answers were often different
from the commonly accepted
wisdom, hence the books title.
In finding these greatest managers, the authors asked questions
about four kinds of business outcomes: productivity, profitability,
employee retention, and customer
satisfaction.
The answer to the question of
how great managers find, focus,
and keep talented employees
boiled down to answering 12
questions. The first two questions
form the foundation of relationships with employees: Do I know
what is expected of me at work?
and Do I have the materials and
equipment I need to do my work
right? Great managers focus on
outcomes, not process (although
some processes and procedures
are required). Talented employees
want to understand, first of all,
what is expected of them.
The next set of four questions
continues building the base for
an employee/manager relationship. For example, At work, do
I have the opportunity to do what
I do best every day? In the past
seven days, have I received recognition or praise for doing good
work? Notice the specificity of the
second question recognition
www.cutter.com
33
EXECUTIVE REPORT
within the past seven days. The
authors stress that great managers
know each person on their staff
and treat each individually.
practices such as collaborative

decisionmaking, daily customer
interactions, and/or customer
focus groups.
The third set of questions

addresses whether or not the
employees feel a sense of belonging. For example, At work, do my
opinions seem to count? Do I have
a best friend at work? Nowhere
in the 12 questions is there anything about pay or benefits they
didnt make the cut. Instead, there
is a question about friendship
at work. A sense of community,
of relationships, is key to morale
and performance.
5. Enable Team Decisionmaking
One of the most interesting

ideas in the book is that great
managers know how to select
talent. Furthermore, talent, skill,
and knowledge are different. Skills
and knowledge can be learned
talent cant. Take two six-foot,
185-pound men (or women). One
has the talent to become a great
basketball point guard. The other,
no matter how much work and
training he or she undergoes,
will never be a great point guard.
Some have defined a specific
talent required for great programmers the ability to hold 25, 50,
or even 100 ideas in ones head
at a time (whereas the rest of
us are limited to 7 2). Some
managers have the talent
to detect talent; others dont.
In projects, individual competencies
must be melded into team competencies via good collaboration
Decisionmaking is the heart and

soul of collaboration. Anyone can
sit down and chat about a product
design. Collaboration means
working together to jointly build
some feature, create a design, or
write a products documentation.
Collaboration is a joint effort. So
whether you are programming
with another individual or struggling with feature priorities or
deciding whether the product is
ready to ship, there are literally
thousands of decisions, large and
small, to be made over the life of
a project. How a team handles
making those decisions determines whether the team is a
truly collaborative one.
As I said earlier, even the fountain of traditional project management knowledge, the Project
Management Institute, virtually
ignores decisionmaking as a
critical skill. In the PMBOK Guide,
there is no mention of decisionmaking. For all the talk about
empowerment over the last
decade or so, the PMI seems to
still be grounded in a commandcontrol management style.
Naturally then, a discussion of
collaborative decisionmaking has
no place in the PMBOK.
Several years ago, I wrote an article on distributed decisionmaking
for another Cutter publication. In

researching that article, I reviewed
six books on project management
and found one paragraph on decisionmaking. Many, if not most,
process-centric approaches to
both software development and
project management seem to
spend no time on decisionmaking
processes.
But for all the general neglect,
I think collaborative team
decisionmaking capabilities are
absolutely critical to successful
project management agile or
traditional. It is not a background
item but one of nine vital principles. From feasibility go/no-go
decisions, to whether or not to
release a product, to each and
every minute design choice
how teams make these decisions
will have a major impact on their
performance.
6. Use Iterative, Feature-Driven
Delivery
For projects and products in

which the requirements can
evolve over time, it is critical
that the results reviewed by customers during the development
process be as close to versions
of the actual product as possible.
Customers have a very difficult
time visualizing how a product
will function from documents,
which is why in industry after
industry, companies have
embraced modeling, simulations,
and prototyping to improve the
feedback loop from customers to
the development teams. The Agile
VOL. 4, NO. 2
34
Manifesto speaks to working
software over comprehensive
documentation, indicating that
customers respond to real versions of products they can actually
use to fulfill a business scenario.
Shoe developers build mockups
of shoes during the development
process. Airplane designers use
extensive simulations (that are
heavily visual) to make sure systems will integrate well before
spending hundreds of millions
of dollars building the first version
of a plane. Automobile designers
build both full-scale and reducedscale models of new cars. In each
of these cases, the developers
have support documentation
but the proof is in the actual
product. Whether the feature
is implemented in a prototype,
model, or simulation has to do
with the cost. Software features
can be demonstrated fairly inexpensively and then can be easily
changed. Building versions of an
airplane would be much more
expensive, hence the industrys
heavy reliance on simulations.
Experienced traditional project
managers understand that how
they break the project down
into work breakdown structures
can have a significant impact
on how that project is managed
and implemented. Each possible
WBS has advantages and disadvantages. Feature breakdown
structures may be more difficult
to administer for the project
manager, but they facilitate
VOL. 4, NO. 2

interactions between the project
team and customers. Phase-based
WBSs (requirements, design,
build, test, etc.) may be easier
to administer, but they are difficult for customers, especially,
to relate to.
Some people think APM is about
short iterative timeboxes in which
the team is driven to make time
deadlines. Actually, the core
APM principle is about both
timeboxes (short iterations) and
basing progress on customerunderstandable features, not
tasks. Features are closer to reality
than other intermediate artifacts.
They indicate real, not artificial,
progress. Once we have real
progress, project teams, customers, and stakeholders are
forced to make the difficult tradeoff decisions about cost, schedule,
and scope.
7. Encourage Adaptability
Everyone accepts the premise

that our business world constantly
changes. However, we still shrink
from the implications of those
changes. We still anticipate that
plans wont change, at least not
very much. We still view change
as something to be controlled, as
if we have some power over the
world outside our projects. And
we still believe the way to reduce
the cost of change is to anticipate
everything at the beginning of
the project.
Planning is an important activity,
but as the APM model shows,
speculating is probably a more

appropriate term. Speculating
establishes a target and a direction, but at the same time, it indicates that we expect much to
change over the life of a project.
When we plan, we expect the
actual project result to conform
to that plan. Deviations become
mistakes on the project teams
part or a sign of their failure to
work hard enough. When we
speculate, we view the actual
results positively its the plan
we suspect was wrong. The plan,
or speculation, is a piece of information, but it is only one piece
we examine as we determine
the course of action in the next
iteration.
If we constantly measure peoples
performance against the plan,
then adaptability wont be forthcoming. If we want adaptability
and flexibility from our project
teams, if we want them to
respond to customers as those
customers learn new information,
and if we want them to respond as
management changes constraints
or personnel, then we need to
reward the teams responsiveness
to these changes, not admonish
them for not making plan.
Through their actions, revised
performance measurements, and
vision, agile project leaders need
to constantly encourage teams
to learn and adapt as projects
evolve. Evolutionary projects
are difficult full of ambiguity,
change, and uncertainty but
www.cutter.com
35
EXECUTIVE REPORT
the rewards for adapting to deliver
business value are great.
success and the technical teams

satisfaction.
8. Champion Technical Excellence
One of the reasons project

managers, in the role of decisionmakers or influencers, need a
technical background is that while
technical excellence is a laudable
goal, there may be considerably
different approaches to achieving
that excellence. Should the team
focus on working software, refactoring, automated testing, and
simple design (XP flavor); extensive front-end modeling; or some
balance of the two? Republicans
and Democrats often espouse
the same goal, but they have
irreconcilable differences in
terms of how to achieve that goal.
Project management is
industry-independent
project managers are not.
Project managers who
dont understand the technology they are managing
can lose the confidence
of their teams, particularly
teams that are proud of
their technical ability. [19]
In my experience over the years,
Ive never encountered (although
my sample size is limited) a successful software company in
which the team leaders or project
managers were not technology
savvy. Whether a company is
building electronic instrumentation, jet engines, or pure software
products, project managers need
specific technical expertise to
adequately manage projects.
Championing technical excellence, one of the principles of
APM, requires that the project
manager, and team members in
general, understand what technical excellence means. They must
understand, within the context of
their specific product, the difference between excellence and
perfection. No company can
afford to produce a perfect product, but building a product that
delivers customer value (customer quality) and maintains
an internal technical integrity
is essential to commercial
Many TPM and process improvement proponents decry the lack of

discipline or maturity among engineers and software developers.
The implication is that project
team members are like a group
of disruptive children who need a
teacher at the front of the room
to maintain order. Ive never found
the teacher-child model to be
effective with project teams
they tend to be very resentful
of the insinuation.
Delivering project results requires
subject-area mastery, not discipline. Discipline is a relic held
over from an age that believed
employees worked because of
external, imposed controls rather
than internal motivation. If you
believe that the vast majority of
people, given a reasonable work
environment (managements
responsibility), want to do a good

job, then good project leaders
(and other managers) need to
focus not on discipline but on
helping staff improve their technical, business, or other skills.
In the software engineering field,
many of those who bemoan the
lack of discipline use the phrase
to deflect attention from their
own failure to convince people
to apply whatever practice they
are advocating.
9. Accelerate Throughput
If delivering customer value

is a project teams first priority,
then accelerating the delivery
of that value should be a close
second. Value has two basic
components benefit and cost.
Project teams want to maximize
the former and reduce the latter.
Schedule also factors into the
equation because earlier completion means earlier benefits.
One way to streamline projects
(doing fewer things, doing the
right things, eliminating bottlenecks) involves differentiating
between delivery activities and
compliance activities and applying
appropriate strategies to each.10
The issues surrounding delivery
versus compliance activities have
special significance for project
managers. First, project managers
need to analyze project activities
10For background information in this area,
although the authors dont refer to compliance or delivery activities, see James
Womack and Daniel Jones, Lean Thinking:
Banish Waste and Create Wealth in Your
Corporation (Simon & Schuster, 1996).
VOL. 4, NO. 2
36
to maximize time spent on delivery. And second, project managers must analyze their own
activities to determine whether
they are contributing to delivery
or compliance. For example,
when a project manager creates
a status report for management,
she is complying with a management dictum. However, when
she is coordinating the activities
between two feature teams or
assisting a team in reaching a
critical design decision, she is
contributing to delivery she
adds value to the delivery process.
Project managers need to relieve
the project team from as much
compliance work as possible,
even if that means taking on the
tasks themselves. Several years
ago, when talking to a project
manager of a very successful
CMM Level 5certified software
development organization, I asked
him about all the documentation,
metrics, and reporting work that
went into certification. Oh, he
said, I take care of most of that
myself. The development team
needs to concentrate on the
real work.
Streamlining processes, targeting
a level of bare sufficiency, and
recognizing the difference between
compliance and delivery activities
(and acting on that difference)
will pay big dividends in delivering
value to customers faster and at
a lower cost.
VOL. 4, NO. 2

CONCLUSIONS
Some people may think APM
isnt all that different from TPM.
Some people may already practice their own version of APM.
Some may think it heretical. I
think APM differs from TPM in
several significant ways.
First and foremost, APM is principles based and tools instantiated.
The nine principles of APM are
the drivers; they help us interpret
how to use tools, even tools that
may appear to be traditional ones.
Tools actual practices are
important also. They ground us in
the reality of actually doing the difficult work of managing projects.
Second, APM focuses on delivery, not compliance activities.
Because of this, customers and
products, rather than stakeholders
and activities, become the focal
points. Though project teams
need to respond to many stakeholders, the laser focus must be
on the end users, the customers
who actually have to employ the
product of the project teams
efforts. Because in the end, its
these customers who will
employ the product to deliver
business value.
Teams that focus on activities get
lost, and even worse, they often
dont realize it. Earned value
analysis a tool touted by many
large organizations has nothing
to do with value but with cost
accounting based on planned

tasks versus actual tasks. The
value of what those tasks actually
deliver gets lost, and then the
team gets lost. Teams that concentrate on products, and on the
features that make up those products, relate to their customers and
are constantly focused on delivering useful results.
Third, when we focus on customer needs and problems and
build products to solve those
needs and problems, then we
recognize that exploration, innovation, and adaptability are key to
success. And when these three
things are our objectives, competency and collaboration are the
natural means to our end.
These values customers, products, exploration, competency,
and collaboration define agile
project management. APM and
TPM both have a place in a project managers toolbox. Some projects dont have the characteristics
that dictate the use of an agile
approach. APM may use some
of the tools of TPM, or vice versa,
but the fundamental philosophies
differ. For more and more of
todays projects those that have
high-exploration factors, require
active customer responsiveness,
or those in organizations with
innovative cultures agile project
management should be strongly
considered in lieu of traditional
approaches.
www.cutter.com
37
EXECUTIVE REPORT
ABOUT THE AUTHOR
Jim Highsmith is a Fellow of
the Cutter Business Technology
Council, Director of Cutter
Consortiums Agile Project
Management Practice, and is
considered a leader of the agile
methodology movement. He is
a frequent keynoter at Cutter
Summits and symposia.
Mr. Highsmith is President of
Information Architects, Inc. and
has 20-plus years experience as
an IT manager, product manager,
project manager, consultant, and
software developer. He consults
with IT and product development
organizations and software companies worldwide to help them
adapt to the accelerated pace
of development in increasingly
complex, uncertain environments.
Mr. Highsmith is the author of
Agile Software Development
Ecosystems, which portrays the
principles, problem domains, key
industry leaders, and project success stories associated with agile
methodologies. His first book,
Adaptive Software Development:
A Collaborative Approach to
Managing Complex Systems,
won the prestigious Jolt award for
product excellence. Mr. Highsmith
is coauthor of the Agile Manifesto
and a founding member of the
AgileAlliance. He can be reached
at jhighsmith@cutter.com.
REFERENCES
1. A Guide to the Project Management Body of Knowledge. Project
Management Institute, 2000.
2. Buckingham, Marcus, and Curt

Coffman. First, Break All the Rules.
Simon & Schuster, 1999.
3. Dove, Rick. Response Ability.
John Wiley & Sons, 2001.
4. Goldman, Steven, Roger
Nagel, and Kenneth Preiss.
Agile Competitors and Virtual
Organizations. Van Nostrand
Reinhold, 1995.
5. Goleman, Daniel, Richard
Boyatzis, and Annie McKee.
Primal Leadership: The Hidden
Driver of Great Performance.
Harvard Business Review,
December 2001.
6. Goranson, H.T. The Agile
Virtual Enterprise: Cases, Metrics,
Tools. Quorum Books, 1999.
7. Fowler, Martin, and Jim
Highsmith. The Agile Manifesto,
Software Development, August
2001 (www.sdmagazine.com/
documents/s=844/sdm0108a/
0108a.htm).
8. Highsmith, Jim. Adaptive
Software Development. Dorset
House, 2000.
9. Highsmith, Jim. Agile Software
Development Ecosystems.
Addison-Wesley, 2002.
10. Hodgson, Phillip, and
Randall White. Relax, Its Only
Uncertainty: Lead the Way When
the Way Is Changing. Prentice
Hall, 2001.
11. Howell, Greg, and Lauri

Koskela. Reforming Project
Management: The Role of
Planning, Execution, and
Controlling. Proceedings of
the Eighth Annual Conference
of the International Group
for Lean Construction, 2000
(www.leanconstruction.org).
12. Kaner, Sam. Facilitators Guide
to Participatory Decision-Making.
New Society Publishers, 1996.
13. Katzenbach, Jon R., and
Douglas K. Smith. The Wisdom
of Teams: Creating the HighPerformance Organization.
Harvard Business School Press,
1993.
14. Kerth, Norm. Project
Retrospectives: A Handbook
for Team Reviews. Dorset
House, 2001.
15. Kotter, John. What Leaders
Really Do. Harvard Business
Review, December 2001.
16. Moore, Geoffrey. Crossing the
Chasm. HarperBusiness, 1991.
17. Sobek, Durward K. II, Allen
C. Ward, and Jeffrey K. Liker.
Toyotas Principles of Set-Based
Concurrent Engineering. Sloan
Management Review, Winter 1999.
18. Thomsett, Rob. Radical Project
Management. Prentice Hall, 2002.
19. Verzun, Eric. The Fast Forward
MBA in Project Management.
John Wiley & Sons, 1999.
VOL. 4, NO. 2
About the Practice
Agile Project
Management Practice
Cutter Consortiums Agile Project Management Practice helps companies succeed
under the pressures of this highly turbulent economy. The practice is unique in that
its Senior Consultants who write the reports and analyses for the information
service component of this practice and do the consulting and mentoring are the
people whove developed the groundbreaking practices of the Agile Methodology
movement. The Agile Project Management Practice also considers the more
traditional processes and methodologies to help companies decide what will
work best for specific projects or teams.
Through the subscription-based publications and the consulting, mentoring, and
training the Agile Project Management Practice offers, clients get insight into agile
methodologies, including Adaptive Software Development, Extreme Programming,
Dynamic Systems Development Method, and Lean Development; the peopleware
issues of managing high-profile projects; advice on how to elicit adequate
requirements and managing changing requirements; productivity benchmarking;
the conflict that inevitably arises within high-visibility initiatives; issues associated
with globally disbursed software teams; and more.
Products and Services Available from the Agile Project Management
Practice
The Agile Project Management Advisory Service

Consulting
Inhouse Workshops
Mentoring
Research Reports
Other Cutter Consortium Practices
Cutter Consortium aligns its products and services into the nine practice areas
below. Each of these practices includes a subscription-based periodical service,
plus consulting and training services.
Agile Project Management

Business Intelligence
Business-IT Strategies
Business Technology Trends and Impacts
Enterprise Architecture
IT Management
Measurement and Benchmarking Strategies
Risk Management and Security
Sourcing
Senior Consultant
Team
The Cutter Consortium Agile Project
Management Senior Consultant Team
includes many of the trailblazers in the project
management/peopleware field, from those
whove written the textbooks that continue
to crystallize the issues of hiring, retaining,
and motivating software professionals, to
those whove developed todays hottest agile
methodologies. Youll get sound advice and
cutting-edge tips, as well as case studies and
data analysis from best-in-class experts. This
brain trust includes:
Jim Highsmith, Director

Scott W. Ambler
Sam Bayer
Kent Beck
E.M. Bennatan
Tom Bragg
Robert N. Charette
Alistair Cockburn
Doug DeCarlo
Tom DeMarco
Khaled El Emam
Kerry Gentry
Ron Jeffries
Joshua Kerievsky
Brian Lawrence
Tim Lister
Michael C. Mah
Lynne Nix
Ken Orr
Roger Pressman
James Robertson
Suzanne Robertson
Alexandre Rodrigues
Johanna Rothman
Lou Russell
Ken Schwaber
Rob Thomsett
Colin Tully
Richard Zultner

Agile PM

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Agile PM

Diunggah oleh

Hak Cipta:

Format Tersedia

Agile Project

Agile Project Management:

Traditional project management and agile project management dont have

Report, Cutter Business Technology Council Fellow Jim Highsmith outlines

About Cutter Consortium

Cutter Business Technology Council

Agile Project Management:

by Jim Highsmith, Fellow, Cutter Business Technology Council

this vision, business and technical

Though agile practices have the

Projects run the gamut from

initiatives. The more uncertain

Projects that fall into this category

One of the factors that determines

Innovation Only? Cutter Consortium

odology matching, see chapter 24 of [9].

of the competitive storms many

For myself, Ive concocted a

Agility does not come in a can.

Why Agility Is Important

In their book Agile Competitors

2003 CUTTER CONSORTIUM

Business is changing. Customers

If companies are to survive in this

Finally, how do we become agile?

AGILE PROJECT MANAGEMENT ADVISORY SERVICE

(PMBOK) Guide of PMI is

2003 CUTTER CONSORTIUM

a controller and ultimate authority.

AGILE PROJECT MANAGEMENT ADVISORY SERVICE

This oversight may take the form

2003 CUTTER CONSORTIUM

Figure 1 The compliance paradox.

continue on with the project with

However, compliance requirements should not be confused

3For additional discussion on this issue,

see Lean Development: Delivery Versus

AGILE PROJECT MANAGEMENT ADVISORY SERVICE

These principles are guidelines

Figure 2 The agile project management model.

and adaptation. The APM model

Project envisioning covers what,

2003 CUTTER CONSORTIUM

beginning of a project is to create

The purpose of the envisioning

AGILE PROJECT MANAGEMENT ADVISORY SERVICE

Product Vision Box

Project Objective Statement:

Performance Quality Attributes:

Project Data Sheet

Features: (Ability to Statements)

will be sold in shrink-wrapped

Feature/Component Requirements Card

Feature/Component Requirements Card

Feature/Component Requirements Card

Est. Work Effort:

Est. Work Effort:

Feature/Component Requirements Card

Iterative Feature Plan

Est. Work Effort:

Figure 3 The evolution of a project plan.

information into a single page.

should be considered to produce