Agile pm

Agile Project Management:Principles and Tools

by Jim HighsmithFellow, 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.

G46G46

Acce

ss

Rob Austin Christine Davis Tom DeMarco Jim Highsmith Tim Lister Ken Orr Ed Yourdon

About Cutter Consortium

Cutter Consortiums mission is to foster the debate of, and dialogue on, thebusiness-technology issues challenging enterprises today and to help orga-nizations leverage IT for competitive advantage and business success. Cuttersphilosophy is that most of the issues managers face are complex enough tomerit examination that goes beyond simple pronouncements. The Consortiumtakes a unique view of the business-technology landscape, looking beyond theone-dimensional technology fix approach so common today. We know thereare no silver bullets in IT and that successful implementation and deploymentof a technology is as crucial as the selection of that technology.

To accomplish our mission, we have assembled the worlds preeminent ITconsultants a distinguished group of internationally recognized expertscommitted to delivering top-level, critical, objective advice. Each of theConsortiums nine practice areas features a team of Senior Consultants whosecredentials are unmatched by any other service provider. This group of expertsprovides all the consulting, performs all the research and writing, develops andpresents all the workshops, and fields all the inquiries from Cutter clients.

This is what differentiates Cutter from other analyst and consulting firms andwhy we say Cutter gives you access to the experts. All of Cutters products andservices are provided by todays top thinkers in business and IT. Cutters clientstap into this brain trust and are the beneficiaries of the dialogue and debate ourexperts engage in at the annual Cutter Summit, in the pages of the Cutter ITJournal, through the collaborative forecasting of the Cutter Business TechnologyCouncil, and in our many reports and advisories.

Cutter Consortiums menu of products and services can be customized to fit yourorganizations budget. Most importantly, Cutter offers objectivity. Unlike so manyinformation providers, the Consortium has no special ties to vendors and cantherefore be completely forthright and critical. Thats why more than 5,300global organizations rely on Cutter for the no-holds-barred advice they needto gain and to maintain a competitive edge and for the peace of mind thatcomes with knowing they are relying on the best minds in the business fortheir information, insight, and guidance.

Accessto the

Experts

Cutter Business Technology Council

Over the last year Ive been work-ing with a software product com-pany in Canada that has a mixedproduct portfolio of large legacyproducts and exciting new ones.With some of its new products,the company literally doesntknow past the next two- to three-week development iterationwhich features will be included inthe subsequent development iter-ation. It does have a clear productvision. It does have a productbusiness feasibility plan. It doeshave a general idea about whatfeatures are needed in the prod-uct. It does have active involve-ment from product marketing. Itdoes have a general release timeframe and resource expenditureplan. It does have an overall prod-uct platform architecture. Within

this vision, business and technicalframework, and overall productrelease plan, the company deliv-ers tested features every twoto three weeks and then adaptsits plans to the reality of the situ-ation as it is today, not how itwas months ago when the projectfirst began.

Recently, this company released anew product, on a new hardwareplatform, in a matter of months,to rave reviews. This is the type ofproduct and the type of businessenvironment that needs agile proj-ect management (APM) and agilesoftware development. At thesame time, this company utilizesagile practices on its large legacyapplications to improve respon-siveness to customer enhance-ment requests.

Though agile practices have themost notoriety in the softwaredevelopment arena, all of theprinciples and most of the prac-tices (except some of the techni-cal practices such as refactoring)are applicable to nonsoftwaredevelopment projects. In fact, sev-eral of the named agile softwaredevelopment methodologies (orecosystems, to use a word I pre-fer) Scrum, Dynamic SystemsDevelopment Method (DSDM),adaptive software development are project managementoriented.

WHERE APM IS NEEDED

APM complements traditionalproject management (TPM) inmany ways. Good project man-agers should understand thebasics of setting up project

by Jim Highsmith, Fellow, Cutter Business Technology Council

Agile Project Management:Principles and Tools Executive Report, Vol. 4, No. 2

VOL. 4, NO. 2 www.cutter.com

22

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: [email protected]; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: [email protected] Editor: Rick Saia, E-mail: [email protected]. Production Editor: Allison Make, E-mail: [email protected]. ISSN: 1540-6768. 2003 by CutterConsortium. 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 8700or e-mail [email protected].

organizations, budgeting, criticalpath scheduling, and myriad otherestablished project managementpractices. However, good projectmanagers should also know whenand how to apply agile practices.There are three broad situationsin which APM would be moreappropriate than TPM:

1. High exploration-factor projects

2. Projects in which customerresponsiveness is paramount

3. Organizations with innovativecultures

High Exploration-Factor Projects

Projects run the gamut fromlow exploration-factor projectsin which the technology is wellknown and the requirementsare relatively stable to very highexploration-factor ones in whichthe technology is bleeding edgeand the requirements are highlyvolatile. Exploration factors are atype of risk factor, combining sev-eral aspects of risk into an overallassessment. Some project teamsventure into the unknown. Likethe early explorers James Cookand his South Pacific explorations,for example these teams areexploring new technologies,new products, or new business

initiatives. The more uncertainthe future, the more a projectmanagement methodology mustfocus on short-interval deliveryand constant adaptation.

Responsiveness to Customers

Projects that fall into this categoryemphasize cost containmentrather than high explorationfactors, but customer interactionis critical to the projects success.For example, Sam Bayer, a CutterConsortium Senior Consultant andcolleague of mine, has been usingAPM practices to deliver resultsto a banking client.

Innovative OrganizationalCultures

One of the factors that determinesthe success or failure of method-ology or process improvementinitiatives one that is repeatedlyignored is organizationalculture. Highly compliance-oriented processes, such as theInternational Organization forStandardization (ISO) and theSoftware Engineering Institutes(SEI) Capability Maturity Model

(CMM), fit best within a control-oriented culture. In innovation-oriented cultures, such as thosein many high-tech companies,the perceived bureaucracy of theCMM often precludes its imple-mentation. Agile approaches,with their emphasis on delivery,individual capability, and reducedformality, appeal to these innova-tive cultures.

My project managers are freakingout, lamented one senior IT man-ager (a comment I hear more andmore frequently). He was refer-ring to the misalignment betweensoftware development teamsusing Extreme Programming (XP)or another agile software develop-ment method and his projectmanagement office staff, who aresteeped in traditional ProjectManagement Institute (PMI)centric project managementpractices. One objective of thisExecutive Report is to help bridgethat gap. However, the gap doesntdisappear. There are significantlydifferent principles that drive agileand traditional project manage-ment, but there are also differ-ences driven by the unique

For details, see Agile Development Innovation Only? Cutter ConsortiumAgile Project Management E-Mail Advisor,9 January 2003.

For an in-depth look at culture and meth-odology matching, see chapter 24 of [9].

problems encountered in extreme,high-speed, high-change projects.

WHAT IS AGILITY?

Agility does not come in a can.One size does not fit all. There areno five common steps to achieve-ment [3]. What is agility? Why isit important? How do we becomeagile? In the software world,the concept of agile softwaredevelopment can be tracedback to February 2001 when theAgileAlliance wrote the Manifestofor Agile Software Development(www.agilealliance.org). But theconcept of agility has a longerhistory in the manufacturingworld. As a response to Japanesemanufacturers effective use ofLean Manufacturing practices inthe 1980s, a group of US manufac-turers initiated agility researchprograms, some of which werefunded by the US Departmentof Defense (DOD).

Defining Agility

In their book Agile Competitorsand Virtual Organizations, StevenGoldman, Roger Nagel, andKenneth Preiss write, Agilityis dynamic, context-specific,aggressively change-embracing,and growth-oriented. It is notabout improving efficiency, cuttingcosts, or battening down the busi-ness hatches to ride out fearsomecompetitive storms. It is aboutsucceeding and about winning:about succeeding in emergingcompetitive arenas, and aboutwinning profits, market share,and customers in the very center

of the competitive storms manycompanies now fear [4].

For myself, Ive concocted asomewhat shorter definition:Agility is the ability to both createand respond to change. Creatingchange disrupts competitors;responding to change guardsagainst competitive thrusts.Creating change requires innova-tion: developing new products,creating new sales channels,reducing product developmenttime, customizing products forincreasingly smaller market seg-ments. Rather than resist change,product development and projectmanagement practices shouldseek to create change for yourcompetitors. In addition, yourorganizational environment mustbe able to respond quickly to bothanticipated and unanticipatedchanges created by your com-petitors and customers.

Why Agility Is Important

Business is changing. Customersare fickle and demanding. Tech-nology is changing faster than wecan master it. Investors romp fromone industry to another, or onecountry to another, with blindingspeed. New business modelsdemand a quick response (orsometimes no response). Somecompanies and some industriesare more isolated from thesechanges than others. Your com-pany doesnt have to be superagile, just more agile than yourcompetitors if you can figureout who they will be tomorrow.

If companies are to survive in thisturbulent Internet economy, theymust change both their proc-esses and their perspectives withrespect to change. We are nolonger talking about 15%-20%scope creep on projects; weare talking about everything scope, features, technology, archi-tecture changing within thespan of six months. In case aftercase, when Ive talked to com-panies with projects that areattempting to create changeand achieve competitive advan-tage, Im continuously surprisedby the magnitude of change theirprojects undergo. The traditionalproject management maxim ofconforming to plan fails dra-matically in these situations.

How We Become Agile

Finally, how do we become agile?Agility is more attitude thanprocess, more environment thanmethodology. H.T. Goranson has asomewhat surprising set of threeprinciples that answer this ques-tion of becoming agile [6]. First,an organization must have arobust system of self-organizingagents. In his book ResponseAbility, Rick Dove discussesthe need for continuous reconfig-urability of both manufacturinginfrastructures and people infra-structures [3]. Agility doesntcome from top-down planningbut from bottom-up, goal-seekingself-organization.

Second, agility requires a com-mon goal, a High Concept goal in

2003 CUTTER CONSORTIUM VOL. 4, NO. 2

EXECUTIVE REPORT 33

Goransons terminology. A HighConcept goal provides a clearindication of the objective thatcan rally the diverse agents butleaves the details to the partici-pants. Finally, and most surprising,Goranson says that agility dependson a well-trusted, but fluid, con-tracting system. He uses theHollywood movie-making busi-ness as an example in whichmajor deals are made with littleformalization. Both case law aswell as long-developed and infor-mal but binding ways of operatingallow rapid formulation of movieteams who trust the systemto work.

How agile is your organization?How agile does it need to be?How agile do your project man-agement practices need to be?Answering these questions is noteasy, because the answers willcause severe headaches. Youhave to be willing to reexamineevery assumption upon whichcurrent practices are based.

REFRAMING PROJECTMANAGEMENT

The original Manifesto for AgileSoftware Development wasobviously intended for softwaredevelopment, but with a fewalterations, it can become aManifesto for Agile ProjectManagement [7]:

Individuals and interactionsover processes and tools

Delivering features overcompliance activities

Customer collaboration overcontract negotiation

Responding to change overfollowing a plan

As I wrote in Agile SoftwareDevelopment Ecosystems, Theleft side of the Agile Manifestovalue statements indicates whatAgilists consider more importantthan the items on the right side.This should not be construedas indicating that tools, process,compliance, contracts, or plansare unimportant. There is atremendous difference betweenone thing being more or lessimportant than another and beingunimportant. Judicious use oftools is absolutely critical tospeeding software developmentand reducing its costs. Contractsare one vital component to under-standing developer-customerrelationships. Documentation, inmoderation, aids communication,enhances knowledge transfer,preserves historical information,and fulfills governmental and legalrequirements [9].

Agile project managementreframes several fundamentalassumptions about project man-agement. Although many of thepractices and tools of APM are thesame as those of TPM, the funda-mental strategies and assump-tions are different, and thereforethe application of those practicesand tools will be different.

The Project ManagementBody of Knowledge

(PMBOK) Guide of PMI isbased on two underlyingtheories: management-as-planning (for planningand execution) and thethermostat model (for con-trol). Unfortunately, boththeories can be shown tobe heroically simplistic andinsufficient from the pointof view of project manage-ment reality. [11]

This quote sounds somewhatextreme. It could possibly havebeen uttered by one of Cuttersesteemed extreme project man-agement practitioners such asDoug DeCarlo or Rob Thomsett.However, this questioning of con-ventional project managementwisdom doesnt come from somehigh-tech source, but from onewe generally consider low-tech the construction industry. In manydebates, Ive seen or heard com-ments like, The traditional proj-ect management practices workfine for the construction industrywhere many of them originated,but they dont apply to high-techsoftware development. But ifthese practices are being chal-lenged within the constructionindustry itself, maybe thereis even more reason to challengethem in the IT industry.

TPM is composed of threeprocesses that exchange infor-mation planning, controlling,and executing. In constructionprojects, the authors of the quoteabove see several troubling


44 AGILE PROJECT MANAGEMENT ADVISORY SERVICE

aspects of traditional planning.First, the motivation for planningoften comes from outside theproject; that is, plans are devel-oped to satisfy legal, regulatory, ormanagement requirements ratherthan basing them on the actualwork that needs to be accom-plished. Second, the motivationfor plans often relates more to thedesire for control than the needsof actual work execution. We seethis constantly in software devel-opment, where the task-basedplanning that project managersuse for control has little relation-ship to how developers actuallywork. Third, planning and controlbecome the focal points; execu-tion is relegated to minor impor-tance status, and legitimizing theproject takes precedence overproducing results.

Since planning and controlbecome the focus in TPM, thisphilosophy gives rise to the notionthat a good project manager canrun any type of project with rela-tively little domain knowledge ofthe work itself. Therefore, a goodproject manager could, theoreti-cally, run a construction projector a software project with littleknowledge of either domain.

Control has traditionally centeredon correction, not learning,because the plans are viewed ascorrect, and translating the planinto action is considered a simpleprocess. Witness the conventionalwisdom that construction itself(carpentry, electrical, plumbing,

etc.) is merely manual, mechani-cal work without much decision-making or creativity (just followthe plans) or that programmingis just coding whats specified. Ifplans are viewed as correct, thencontrol focuses on fixing mistakes,not learning something new thatmight legitimately alter the plans.Explaining discrepancies, notlearning, takes center stage. Otherissues with this traditional viewof control include: inappropriatemanipulation of work in order tomeet the plan, reduced possibili-ties for collaboration, incorrectinterpretation of performance,and reluctance to revise plans.

APM is an execution-biasedmodel. TPM is a planning-and-controlbiased model. In APM,the project managers primaryrole is to create a vision of theproduct to be produced andguide the team toward makingthat vision a reality. In TPM, theproject managers primary roleis to develop plans and schedulesand control progress such thatthe plan is implemented. Thereare projects that have been verysuccessful using both APM andTPM approaches. The determina-tion of which to use should bebased on project type and orga-nizational culture.

Agile project management couldalso be labeled collaborative proj-ect management. Though agileprojects need project managers,the role is more of a facilitator,influencer, and coordinator than

a controller and ultimate authority.Agile project managers make deci-sions; its how those decisions aremade that differs. Agile projectmanagers dont burrow into theiroffices and invent project plans;they facilitate the entire core teamsdevelopment of those plans.

CONTROLLING AGILE PROJECTS

Project control concernssenior managers and executives.Elaborate planning and controlsystems, both project andaccounting based, have evolvedto provide executives with infor-mation that indicates projects andexpenditures are being adequatelycontrolled. Although many in thetechnical community are exas-perated at the intrusions intotheir work required to providethis information, executiveshave fiduciary, legal, and ethicalresponsibilities that dictate manyof these compliance activities.Nevertheless, in highly volatile,extreme projects, some of thecompliance systems designedfor more sedate environmentsare inappropriate, and othersmask actual performance.

Since TPM begins with determin-istic, predictive plans and thenexercises control over those plans,it can be characterized as havinga conformance to plan controlmentality. For example, earnedvalue analysis is one way ofmeasuring conformance to plan.However, when projects areconstantly changing, measuring


EXECUTIVE REPORT 55

performance by conformance toplan will be counterproductive.

Executives and managers shouldask slightly different questionsabout agile projects:

Are we getting customervalue from the project? Inan agile project, in which manythings can change over thecourse of an iteration or mile-stone, we need to constantlyreview the projects businesscase. The project customersand sponsor will need to makefrequent adjustments in thefeature priorities based on theirinterpretation of feature value.Sponsors will be involved intradeoff decisions betweentime, cost, and scope. Becauseof the nature of agile projects,they often become relativelyfixed in time and cost (thehighest priority to control)and flexible in scope.

Is the project progressingsatisfactorily? This questionis more difficult to answer thanIs the project conforming toplan? Conformance to planis one aspect of satisfactoryprogression, but only one.

Is the project team adaptingeffectively to changesimposed by management,customers, or technology?If managers and executiveswant projects teams thatcan be flexible and adaptto change, then they mustask slightly different questionsabout performance.

DELIVERY VERSUSCOMPLIANCE

APM focuses on delivery, whileTPM often seems to focus oncompliance. Unfortunately,compliance activities dontbuild products. In working withseveral organizations recently, Iveaddressed the issues surroundingcompliance with various stan-dards such as ISO and CMM. Eventhough the SEIs intention is toraise organizational capability totake on software projects and itsstaff does not recommend strivingto attain some level just to beable to say, Were CMM Level 3,reality indicates that many orga-nizations have this motivation.Contractors to the DOD, in particu-lar, are thus motivated becausethe DOD specifies CMM capabilitylevels in contracts. These organi-zations may not think CMM isthe best way to deliver software,but they need to comply with itsmandates.

In reality, every product develop-ment organization, every project,and every company has issueswith compliance. A spate ofrecent business news accusescorporations of not complyingwith accounting, legal, and ethicalstandards. Though the pharma-ceutical companies may decryUS Food and Drug Administrationinefficiencies, few consumerswould want to buy drugsunfettered by federal oversight.Executives have a responsibilityto shareholders, employees, andcustomers to exercise oversight.

This oversight may take the formof audits, project status reports,purchasing policies, or certifica-tions such as ISO. Companiesmay see certification as a market-ing tool; consider, for example,the large number of Indiancompanies certified at high CMMlevels. Concerns over productliability drive companies to com-ply with extensive documentationrequirements.

In short, there will always bea necessity for organizationsto comply with certain internaland external constraints. Com-pliance is a cost of doing busi-ness. However, compliance canalso strangle innovation, raisecosts dramatically, and lengthenproduct development cycles. AsFigure 1 shows, compliance activi-ties can spiral out of control asperformance shortfalls are fixedby additional compliance activities(Well never make that mistakeagain!), which in turn negativelyimpact delivery results.

Dont confuse delivery activitieswith compliance activities. Forexample, lets postulate that ateam constructs a series of designdiagrams on a whiteboard. Froma product delivery perspective,taking digital photos of the dia-grams and storing them in aproject folder may be sufficient.However, from a complianceperspective (say, to maintain ISOcertification, which is important tothe company), the diagrams needto be formalized and documentedin a standard format. Informal



documentation satisfies the deliv-ery process; the formal documen-tation satisfies the complianceprocess.

For our delivery process, weshould concentrate on a stream-lined set of activities that directlydeliver value. We should ruth-lessly eliminate overhead activi-ties. We should target skillstraining and tools at the coredevelopment activities to improvetheir effectiveness.

In contrast, we should think ofall compliance activities as over-head cost. Some complianceactivities are necessary, but theytend to get out of hand. Therefore,our first strategy should be tominimize compliance activitiesas much as possible. When com-pliance costs are too high, theyundermine the developmentprocess and lead to high-costproducts. But cost isnt the onlyproblem with compliance. Evenmore serious is the impact ofcompliance on development time.Therefore, our goal should beto offload compliance activitiesfrom the development team tothe greatest extent possible.

Lets further examine the designdocument example. Once thedesign diagrams are complete onthe whiteboards, support staff not the developers should con-vert the low-ceremony diagramsinto formal documentation. Thesupport staff cost can be lower,and these individuals can freeup the development staff to

continue on with the project withminimal schedule impact. Whenwe fail to differentiate betweendelivery and compliance activities,we fall into the trap of believingthat cleaning up and formalizingthe documentation is actuallyhelping developers build betterproducts. By offloading, we forceourselves to confront the truecost of compliance. By offloading,we keep compliance activitiesfrom wrecking developmentschedules.

We can rail against the compli-ance process, but its mostlyfutile (not that we shouldnt atleast try to eliminate truly onerouscompliance processes even so).Compliance activities are neces-sary, and they are not going away.

However, compliance require-ments should not be confusedwith development objectives.We want to design the bestprocess possible to meet thedevelopment objectives, andthen, and only then, we wantto add the compliance activitiesalongside the delivery process.We want our delivery processesto be effective. We want our com-pliance processes to be efficient.Keeping the two separated willdo your product developmentprocess a world of good.


EXECUTIVE REPORT 77

Perceived

Performance

Shortfall

Compliance

Activity

Delivery

Activity

Delivered

Results

increases

decreasesdecreases

increases

Figure 1 The compliance paradox.

For additional discussion on this issue,see Lean Development: Delivery VersusCompliance, Cutter Business TechnologyTrends and Impacts Council Opinion, Vol. 4,No. 1, January 2003.

APM FOCUS

The remainder of this ExecutiveReport covers three aspects ofAPM. First, it describes an overallproject management frameworkfor thinking about the phases of anagile project. Second, it identifiesa series of tools that have proveneffective for each of the phases.This is not an exhaustive set ofproject management tools (thereare many more that are the sub-ject of numerous project manage-ment books), but rather a set thatfocuses on visioning, delivery, andadapting an agile set of tools.Third, the report defines nineprinciples that apply to all agileprojects. Although specific toolsmay vary from project to project,these nine key principles arealways in the forefront of theproject teams consciousness.

These principles are guidelinesthat breathe life into the tools.So, for example, Tool I2: DailyInteraction with Customers (onpage 21) describes how develop-ment teams need frequent inter-action with customers on a varietyof issues. (Why this is importantis summarized in the principleDeliver Something Useful onpage 30.) Without tools, the princi-ples are empty. Without principles,the tools are sterile and inflexible.

AN AGILE PROJECTMANAGEMENT MODEL

The agile project managementmodels flow, as shown in Figure2, appears similar to that of atraditional model. However, tradi-tional models focus on planningand control, while the APM modelfocuses on delivery (execution)

and adaptation. The APM modelalso identifies both phases andresults. For example, the envisionphase results in a project vision.There are other differences that,while they may seem subtle,are significant. First, envisionreplaces the traditional initiateto indicate the criticality of vision.Second, a speculate phasereplaces a plan phase. Wordsconvey certain meanings, andthose meanings arise from sys-tematic use over time. The wordplan has become associatedwith prediction and relative cer-tainty. Speculate indicates thatthe future is uncertain. We knowthat the future of any project,particularly extreme projects,contains uncertainty, but we stilltry to plan that uncertainty away.We have to learn to speculate andadapt rather than plan and build.

Third, the APM model specifiesiterative delivery it is an explic-itly nonlinear, concurrent, non-waterfall model. The APM modelfocuses on how project managerscontribute to product delivery firstand compliance a distant second.The TPM model, on the otherhand, emphasizes control. Myvision of control is someonesitting atop a large piece of con-struction machinery controllingit. Project teams are groups ofpeople, not cogs in machines.They can be led, motivated,organized, and coordinated, butcontrol is a relic of the past. Soa team practicing APM monitorsinformation and adapts to current



Envision

SpeculateIteratively

Deliver Features

Monitor

and Adapt

Close

Feature

Plan

Tested

Features

Adaptations

Final

Product

Vision

Feature

List

Figure 2 The agile project management model.

conditions. Finally, the APM modelends with a close phase, in whichthe primary objectives are knowl-edge transfer and, of course, acelebration.

To sum up, the five phases of agileproject management are:

1. Envision determine theproduct vision, who is goingto do the work, and how theteam will work together.

2. Speculate develop a feature-based release, milestone, anditeration plan.

3. Iteratively deliver features deliver tested features in shorttime frames.

4. Monitor and adapt reviewthe delivered results, the cur-rent business environment,and the teams performance and adapt as necessary.

5. Close conclude the project,wrap up loose ends, andcelebrate.

AGILE PROJECTMANAGEMENT TOOLS

The APM tools are presentedunder an appropriate frameworkphase, although some of thetools can, and should, be usedin several phases.

Envision

Project envisioning covers what,who, and how. I use the wordenvision, rather than the morecommon initiate, becausethe key success factor in the

beginning of a project is to createa vision for the customers and theproject team. Absent a vision, theremaining activities in getting aproject off the ground are wastedeffort. In business-speak, vision isthe critical success factor of thisphase. First, we need to envisionwhat to deliver a vision of theproduct and the scope of the proj-ect. Second, we need to envisionwho will be involved the com-munity of project team membersand other stakeholders. And third,the project team members mustenvision how they intend to worktogether. How a team intends towork together their practicesand guiding principles is asimportant to success as a clearlyarticulated vision [13].

It is a little difficult to determinewhere envisioning begins,because the APM model as shownis not a portfolio or product man-agement model but a projectmanagement model. Some com-panies employ extensive feasibilityand marketing studies prior toinitiating development projects,while others use only brief projectrequests. Depending upon thesituation, the information avail-able to an envision phase mayvary, but the key output remainsconstant: a mutually agreed-uponproduct vision. Although there areother important aspects of initiat-ing a project budgets, stafforganization, reporting needs without a commonly held productvision, the project will falter.

The purpose of the envisioningphase is to clearly identify whatis to be done and under what con-ditions it is to be accomplished.Specifically, this phase answersthe following questions:

What is the product vision?

What is the purpose of theproject (objectives) and itsconstraints?

Who will be included in theproject community?

How will the team deliverthe product?

For small projects, much if notmost of the project envisioningwork can be accomplished in asingle kickoff week. For largerprojects, additional training,resource procurement, architec-tural work, and justification analy-sis may take longer and can beincluded in an Iteration 0 (seeTool S5 on page 20).

Figure 3 depicts the evolutionof a project plan from vision,to scope, to features utilizingthree simple but powerful arti-facts: the vision box, the projectdata sheet (PDS), and the iterativefeature plan. Each of these arti-facts is simple (in concept), pow-erful, low ceremony (informal),and contains limited real estate.The vision box exercise forcesthe team to condense informationabout a product vision onto thelimited space of a box. The proj-ect data sheet forces the teamto condense key project scope


EXECUTIVE REPORT 99

information into a single page.Feature cards force the team tocondense the key informationabout a feature onto a single 4 x 6inch index card. Limitingthe space in which we recordinformation requires focus andselection it requires intensecollaboration and thinking.

Tool E1: Product Vision Boxand Elevator Test Statement

The product vision box and eleva-tor test statement are two toolsthat enable a team to create aproduct vision. The box exerciseemphasizes that projects produceproducts, because even withinan IT organization, every project

should be considered to producea product. Whether the projectresults involve enhancements toan internal accounting system ora new e-commerce site, product-oriented thinking pays benefits.

The design-the-box exercise(originally developed by mycolleague Bill Shackelford) isan effective practice for gettingteams to think about a productvision. In this exercise, the entireteam, including customers,breaks up into groups of four tosix people (this works best withcross-functional participation).The team members make theassumption that the product

will be sold in shrink-wrappedboxes, and their task is to designthe product box front and back.This involves coming up with aproduct name, a graphic, three tofour key bullet points on the frontto sell the product, a detailedfeature description on the back,and operating requirements.Figure 4 shows a sample visionbox developed during a work-shop session.

Coming up with 15 or 20 productfeatures proves to be easy. Itsfiguring out which three or fourwould cause someone to buy theproduct that is difficult. One thingthat usually happens is an intensediscussion about who the cus-tomer really is. It always amazesme that, when using a very simpleproduct example, the productvision boxes end up so disparateamong three to five teams.Presentations by each of thegroups are then followed by adiscussion of how the differentfocal points can be reduced toa few that everyone agrees upon.A lot of good information getsgenerated by this exercise plus,its fun.

A second visioning, and focusing,tool is the elevator test statement:

For mid-sized companysmarketing and sales depart-ments who need basic ofCRM functionality, the CRM-Innovator is a Web-basedservice that provides salestracking, lead generation,and sales representative



Product Vision Box

Iterative Feature Plan

Project Data Sheet

Project Data SheetProject Name: Project Leader:Project Start Date: Executive Sponsor:Clients: Client Benefits:

Project Objective Statement:

Performance Quality Attributes:

Focus Matrix: Excel Improve Accept Target

Scope

Schedule

Defects

Resource

Features: (Ability to Statements) Architecture:

Major Milestones: Issues/Risks:Date

1.

2.

3.

4.

1992-97 Knowledge Structures, Inc.

Cycle 0 Cycle 1 Cycle 3 Cycle 4Cycle 2

Architecture

1.0

RequirementsCards

Feature/Component Requirements Card

Feature/Component ID: Planned Cycle:

Feature/Component Name:

Feature/Component Type:

Feature/Component Description:

Est. Work Effort:

Requirements Uncertainty (H,M,L):

Dependencies with other Features:

Architecture

1.1

Architecture

1.2






Est. Work Effort:



Feature 1

Feature 2






Est. Work Effort:








Est. Work Effort:



Feature 3

Feature 4






Est. Work Effort:








Est. Work Effort:



Feature 5

Feature 6






Est. Work Effort:



Feature 7

Figure 3 The evolution of a project plan.

support features thatimprove customer relation-ships at critical touchpoints. Unlike otherservices or package soft-ware products, our productprovides very capable ser-vices at a moderate cost.

This product vision model helpsteam members pass the elevatortest the ability to explain theproject to someone within twominutes [16]:

For (target customer)

Who (statement of the needor opportunity)

The (product name) is a(product category)

That (key benefit, compellingreason to buy)

Unlike (primary competitivealternative)

Our product (statement ofprimary differentiation).

For any project, but particularlythose with high uncertainty forwhich significant requirementschanges are anticipated, creatinga product vision statement helpsteams remain focused on the criti-cal aspects of the product, evenwhen details are changing rapidly.It is very easy to get focused onthe short-term issues associatedwith a two- to four-week develop-ment iteration and lose track ofthe overall product vision.

Finally, with several hours ofactive discussion recorded onflipchart paper, the group canconstruct a good outline for acomplete one- to three-pageproduct vision document thatmight include: the mission state-ment, a tradeoff matrix (scope,schedule, cost, defects), picturesof the boxes, target customersand each of their needs, customersatisfaction measures, key tech-nology and operational require-ments, critical product constraints(performance, ease of use,volumes), and key financialindicators.

For a four- to six-month project,this visioning exercise might takeabout half a day, but it will paybig dividends. Recently, Ive hada client report that spending threeto four hours for a visioning ses-sion brought a group with widelydifferent ideas about productdirection into close alignment.The more critical the deliveryschedule and the more volatilethe project, the more importantit is that the team have a goodvision of the final desired out-come. Minus this vision, iterativedevelopment projects are likelyto become oscillating projectsbecause everyone is looking


EXECUTIVE REPORT 1111

Figure 4 Product vision box example.

at the minutiae rather than thebig picture.

Tool E2: Stakeholder Identification

Identifying a projects stakehold-ers is a project management taskthat is very easy to say and oftenmost difficult to do well. Forexample, a large companysenterprise resource planning(ERP) or customer relationshipmanagement (CRM) applicationimplementation could have hun-dreds, or even thousands, ofstakeholders. Commercial soft-ware products may have millionsof stakeholders. Project team afterproject team has been blindsidedby previously unidentified stake-holders coming forth to bury theproject with unforeseen informa-tion or internal political agendas.

A general categorization of stake-holders could be:

Customers the group ofpeople who will actually usethe system and may, in thecase of a commercial product,be the purchaser.

Sponsors the person, orgroup of people, who cham-pion the product and make keydecisions about the productsgoals and constraints.

Project manager the personwho leads the team chargedwith delivering results.

Management a potentiallywide range of individuals whocan be in charge of customer,sponsor, or developmentteam organizations. Theymay have budget or technical

decisionmaking authority orinfluence the project outcomes.

Project team the individuals,both full-time and part-time,who are charged with deliver-ing results.

The more complex the stake-holder group, the more timeproject managers must spendmanaging the expectations ofthe various groups, getting criticalproject decisions made, andkeeping the project from beingpulled in too many directions.

Identification is the first step inintegrating various stakeholdersinto the project community.

Tool E3: Customer-ProjectTeam Interface

Figure 5 identifies the compo-nents of a customer-project teaminterface for the customers whowill be defining feature require-ments and helping the projectteam make day-to-day decisions.In the software world, XP postu-lates an onsite customer whohas specific duties of definingrequirements and making featurepriority decisions. However, largerprojects may have many cus-tomers who often have conflictingpriorities. No single person mayhave the knowledge of all thefeature requirements. For largerprojects or for projects with wide-ranging needs for customer infor-mation, the important issue is notto have a single customer, but to



Customers Project Team

Product Vision

Feature ID

Requirements

Conversation

Feature Priority

Acceptance

Figure 5 Customer-project team interface.For an in-depth look at stakeholder iden-tification and management, see [18].

consolidate multiple voices intoa single customer voice. Theexchange between the projectteam and this consolidatedvoice includes the identificationof features, prioritization of thosefeatures (so there must be sometype of decisionmaking processon the customers part), andongoing conversations and inter-actions between customers andthe project team.

IT organizations and productdevelopment organizations (bothsoftware and industrial products)will have different players onthe customer side, but the inter-actions will be similar. Whereas aproduct group may use a productmanager role to facilitate theinteraction, an IT organizationmay designate a business analyst.In order to guard intellectual prop-erty, product companies may bereluctant to release early versionsof their products to customers.Whatever the complexities oneither side of the customer-developer interface, the basicinteractions shown in Figure 5are necessary for a successfulagile project.

The worst situation arises whenprioritization fails and the devel-opment team, in order to keepthe project from bogging down,begins making the priority deci-sions itself. This often degeneratesinto a no-win situation, as the cus-tomers can always fault the deci-sions and then use that failure asan excuse to reduce their support

of the project. The project losesits partnership relationships.

To address this issue, I recom-mend that every project everysingle one have a product man-ager role (separate from the proj-ect managers role). In a small,colocated team project, this rolecan be played by the onsitecustomer advocated by XP.Product companies (both indus-trial products and software prod-ucts) usually have an actualproduct manager who acts asa focal point for these decisions.In large companies, with a multi-plicity of customers, this role canbe played by a small productmanagement team that representsmultiple parties but can provideunambiguous information anddecisions to the project team.

Tool E4: Project Scope andConstraints (Project Data Sheet,Tradeoff Matrix, and Delay Cost)

A PDS is the second majorvisioning tool in the evolutionof a project plan, as shownback in Figure 3 on page 10.

A project data sheet is asingle-page summary of keybusiness objective, productspecification, and projectmanagement information. Itis a document to help focusthe project team, manage-ment, and customers. ThePDSs simplicity belies itspower to convey quicklythese key project elements.It is one of those simple

tools with a powerfulimpact. Not only does itscondensed format appealto stakeholders who mightnot be fully involved in theproject, and remind thosewho are fully involvedabout the most importantaspects of the project, italso plays a part with thosewho develop it. [8]

Sections of the PDS might includesome combination of the follow-ing, depending on organizationand project type:

Clients/customers a list ofthe key clients or customers

Project objective statement should be specific, short (25or fewer words), and includeimportant scope, schedule, andresource information from thetradeoff matrix

Features a list of the keyfeatures

Client benefits the keybenefits and/or selling pointsof the product

Performance/quality attri-butes a list of the keyperformance and qualityattributes of the product

Architecture key architec-tural components of the prod-uct (platform, component,interface, module)

Issues/risks factors thatcould adversely impact thisproject



A project tradeoff matrix (TOM),as shown in Figure 6, depictsthe key dimensions that create aproducts value features, deliv-ery schedule, defect levels, andresources. The matrix indicatesthe relative importance of eachdimension, and columns 1 and 2,excel and improve, can eachcontain only one entry. If the high-est priority is features, then every-thing else takes second place.Schedule might be designated assecond-highest priority (improve).Similarly, the team would strive tomaintain acceptable defect levels(within some specified tolerancelevel; for example, 5 sigma).

The TOM is a contract betweenthe project team and the cus-tomer, sponsor, and managementstakeholders. It is used to managechange during the project. Forexample, the lower-priority char-acteristics usually have a broadertolerance, so if schedule is exceland resources are accept, then theteam (within boundaries) already

knows that spending additionalfunds is an acceptable adaptationto keep on schedule. The TOMalso informs all stakeholdersthat changes have consequencesand acts as a criterion for teamdecisionmaking.

One other simple but powerfultool that can assist teams in mak-ing project decisions is delay cost.I once worked with a project teamfor which the calculated delaycost was nearly a million dollars aday in lost revenue. Knowing thiscost drove much of the decision-making on the project and helpedward off the constant flow of newfeatures from marketing. Whenstakeholders insist that scheduleis the most critical element of aproject, having them calculate adelay cost puts the criticality ofthe schedule in perspective.

Tool E5: Exploration Factor

One issue in selecting projectmanagement practices andprocesses is the particular prob-lem domain in which the projectteam has to operate. Big projects

are different than small projects;risky projects are different thanlow-risk ones. It is important toidentify the various problemdomain factors, but it is evenmore important to tailor processesand practices to the problem andto adjust expectations (measuresof success) accordingly.

To discuss problem domains,Ive been using the concept ofan exploration factor, in whicha factor of 10 indicates a highlyexploration-oriented (high-risk)problem domain and a 1 indi-cates a very stable problem envi-ronment. The exploration factorderives from a combination of thevolatility of a products require-ments and the newness andthus uncertainty of its tech-nology platform.

As shown in Figure 7, there arefour categories of requirements:erratic, fluctuating, routine, andstable. Erratic requirementswould be encountered in a situa-tion in which the product goalwas understood but the businessor product requirements werevery new and untried. An examplewould be a new product devel-opment effort in which featureswere unfolding as the projectwent forward. In this case, therequirements might change drasti-cally as the project proceeded, notfrom poor requirements gathering,but from evolving knowledge ofthe product area. Fluctuatingrequirements would be one stepdown in uncertainty. While anerratic problem space might



Excel Improve Accept

Features X

Schedule X

Defects X

Resources X

Figure 6 Tradeoff matrix.

For more information on project envisioningsee Chapter 4 of [8].

experience 25%-50% or morerequirements change, a fluctuat-ing one might be more sedateat 20%-25%. Routine changeswould apply to a wide range ofprojects in which up-front require-ments gathering would yield areasonably stable baseline forfurther work, while a stableenvironment might be somethinglike a federally mandated changeto a payroll system that was welldefined and unlikely to change.

The technology dimension alsohas four categories: bleedingedge, leading edge, familiar,and well-known. Bleeding edgewould involve a technology sonew that very few people haveexperience with it. With bleeding-edge technology, learning by try-ing is the only strategy becauseno one else knows how to use iteither. Microsoft .NET might bean example of bleeding-edgetechnology. Leading-edge tech-nology is relatively new, but thereare pockets of expertise to turnto although price and availabil-ity might be an issue. Developingmiddleware using J2EE mightbe classified as leading-edgetechnology. Projects employingbleeding- and leading-edge tech-nology have much higher riskprofiles than those using familiaror well-known technologies.One of the issues with manyIT projects initiated over thepast several years has been thata large number have employed,or tried to employ, new and riskytechnologies.

Finally, Figure 7 combines theseelements of requirements volatilitywith technology risk. For example,an erratic requirements, bleeding-edge technology problem spacereceives an exploration factorof 10, whereas a stable require-ments, well-known technologyproject receives a factor of 1. Aproject with fluctuating require-ments and leading-edge technol-ogy receives a factor of 7.

We can now discuss projectsfrom the perspective of the over-all uncertainty of the problemspace. An 8, 9, or 10 project willrequire a very agile approachsince the uncertainty and riskare high. Short iterations, feature-driven planning, frequent reviewswith customers, and a recognitionthat plans are very speculative areimperative for solving problems inthis domain. In contrast, projectswith a 1, 2, or 3 rating will be rela-tively stable and low risk. Plansshould be more stable, iterations

could be somewhat longer, andadditional up-front requirementsgathering and design can be cost-effective.

Without the recognition of differ-ent problem domains, one-size-fits-all project processes andpractices seem justified. Withsuch a recognition, customizationand tailoring to specific problemswill enable project teams to bemore successful.

Tool E6: Product Architecture

Product architecture may seemlike an odd tool to put into a proj-ect management toolbox, but aproducts technical architecture,together with the overall size ofthe project, has significant impli-cations for project management.For example, if a team is buildinga complex product with bothhardware and software compo-nents, the interface specificationsmay have a major impact on the



Technology Dimension

ProductRequirementsDimension

BleedingEdge

LeadingEdge Familiar

Well-Known

Erratic 10 8 7 7

Fluctuating 8 7 6 5

Routine 7 6 4 3

Stable 7 5 3 1

Figure 7 Project exploration factors.

change management process.Similarly, the component andmodule organization may impactoutsourcing or distributed devel-opment decisions and how tomanage distributed groups.

In general, agile practices encour-age change and adaptation;however, certain changes havesignificant impact on others andrequire careful coordination. Forexample, in automobile design,the transmission and drive traincomponents have a certain well-defined interface. Changes withinthe component that dont changethe interface can be handled lessformally than those that do affectthe interface. It is not a matter ofcontrol who gets to make thedecisions as much as it is amatter of coordination makingsure we understand the totalimpact of a change and whichgroups are affected. Poor technicalarchitectures make this changecoordination job much more diffi-cult. Astute project teams will rec-ognize when excessive time spenton cross-component coordinationor integration is pointing to poorarchitectural decisions that needto be remedied.

In a very general way, technicalarchitectures utilize some combi-nation of platform, component,interface, and module architec-tures. A new sport utility vehicle(SUV) may begin with a truck ora car platform. A software productmay utilize a Windows or a Macplatform, or both. Our SUV hasa body, drive train, engine, and

many other components. A soft-ware component may have APIsthat specify how other compo-nents are to interact with it. Amultifunction PC device mayhave printer, scanner, and faxingcomponents, each of whichhas modules.

One of the reasons effectiveproject managers need technicaldomain experience as well asproject management skills is thattechnical architecture and projectorganization and communicationscannot be separated. Poor techni-cal structures can cause severeorganizational problems, just aspoor organizational structurescan sometimes result in poortechnical decisions.

Tool E7: Collaboration,Communication, andDecisionmaking Plan

Most project managementapproaches include a communi-cations plan. The PMIs A Guideto the Project Management Bodyof Knowledge includes projectcommunications managementas one of its key knowledge areas[1]. However, communications isnot enough. Communicationsis basically one-way I sendyou information. Collaboration,however, involves much morethan communication; it involvesinteraction to produce somejoint result. Collaboration inte-grates your ideas and mine into awhole. We communicate to man-agement with status reports. Wecollaborate among project teammembers using practices such

as whiteboard brainstorming ses-sions. People on a project needto understand each other: projectteam members need to under-stand the customer; qualityassurance engineers need tounderstand design engineers.Understanding comes from acombination of documentationand interaction, and of the two,interaction is the most important.Throughout the product develop-ment world, in industry afterindustry, the rising tide of cross-functional teams speaks to theneed for collaboration for under-standing. Communicationsthrough documentation alonehas not proven to be effective.

So one of the project teams keyplanning tasks is to put sufficientcollaboration practices into place.The team needs to ask questionssuch as: How will we collaboratewith customers? How will featureteam (subteam) members collab-orate with each other? How willthe team in Atlanta collaboratewith the team in Seattle or theteam in Bombay?

Finally, the core of good collabora-tion is decisionmaking, a skill areathat project management textsand institutions virtually ignore.

A later tool (I3) will provide howto details about decisionmaking(see page 21), but the team needsto address how decisions will bemade early in the project.



For example, nowhere in PMIs A Guide to theProject Management Body of Knowledge [1] isthere any reference at all to decisionmaking.

Tool E8: Guiding Principles

This Executive Report includesa description of both projectmanagement tools and principles.The principle Accelerate Through-put, for example, guides projectteam members when they areapplying the tools. Applying theAccelerate Throughput principleto the previous Collaboration,Communication, and Decision-making Plan tool would remindteam members to keep the planshort and focus on critical issues.Creating such a plan using anotherprinciple might result in lengthy,formalized documentation.

Guiding principles (GPs) guideactual product development. GPsarent measurable requirementsor constraints but conceptualguides. For example, defining theubiquitous phrase user-friendlymay be very difficult. However,a GP that states, The target userfor this product, an entry-levelmedical technician, should beable to use the basic features ofthe product with minimal trainingwould help guide a developmentteam in its user interface design.

GPs may also be used early in aproject before specific require-ments or design decisions havebeen made. They may even allowus to delay decisions until moreinformation has been gathered.For example, early in a project,the GP might be Maximize theuse of reusable components and

services to speed development.That GP could then be used asa factor in design; for example,it might encourage the selectionof a platform framework suchas Microsofts .NET.

Although some GPs may be devel-oped during project envisioning,they often emerge over the life ofthe project. Each principle shouldbe described in a sentence ortwo, and the total number for aproject, at any one time, shouldhover around 10.

Speculate (Plan)

The product of the speculatephase is a release plan that out-lines, to the best of the projectteams current knowledge, aniterative plan that is based onfeatures delivered rather thantasks. The release plan utilizesinformation about the productsspecification, platform architec-ture, resources, risk analysis, busi-ness constraints, cost budgets,and schedules.

Traditional project managers mayperceive APM as promoting a lackof planning. Actually, APM con-tains a significant amount of plan-ning it is just different in typeand objective. Project planninghelps us:

Think about the project, busi-ness goals, and customerexpectations

Provide necessary budgetand schedule informationto management

Establish priorities for tradeoffdecisions as changes occur

Coordinate interrelatedactivities and featuresacross feature teams

Consider alternatives and adaptive actions

Provide a baseline foranalyzing events that occur during the project

If the business world is as turbu-lent as we have told ourselvesover and over again, and agility isthe core competency that enablesus to navigate through these tur-bulent times, then one of project(and business) managementsmost cherished control mecha-nisms the plan is outdated.Conformance to plan has beenthe mantra of project managersfor decades it forms the foun-dation for project managementcertification and is at the coreof how managers think. Its timeto alter that thinking. Rather thanconformance to plan, we needto think about conformance tovision and value. We need tothink of plans as guides, notstraightjackets.

Tool S1: Product Feature List

Few, if any, products begin fromscratch. Feasibility or marketingstudies identify product featuresand performance characteristics.Initial requirements-gatheringefforts contribute items to thelist of potential product features.Product visioning exercises iden-tify features. For existing products,



One of my client colleagues introduced meto this idea of guiding principles.

customers, developers, productmanagers, and customer supportstaff are constantly making sug-gestions about product enhance-ments or minor maintenanceitems. Part of a product managersjob is to constantly sift throughthis list and sort it (with customerinvolvement) into higher- andlower-priority items. This list isa major source of informationfor Tool S4: Release, Milestone,and Iteration Plans (see page 19).

One big difference between APMand TPM projects is the volatilityof the features on this list. For amore sedate project in whichthe requirements are firmlyestablished in the beginning, thisfeature list becomes the input fora task plan that becomes relativelyfixed. In an agile project, the useof the list is much more dynamic.

During the planning for every iter-ation, the list of features to beincluded in that iteration canchange dramatically from theoriginal release plan.

Tool S2: Feature Cards

Feature cards (known as storycards in XP) are used to identify,but not to define, features. Featurecards act as agreements betweencustomers and project teammembers to have a discussionabout detail feature requirementsin the future. Feature cards iden-tify features that the customerwants in the product. For largeproducts, feature category cardscan be used to organize and planextensive feature lists. A categorycard may encompass 10, 15, oreven 20 detail features.

Feature cards are actual indexcards on which the project teamand customer representativesrecord the information gatheredin their product requirementsdiscussions. The critical piece isthe discussion. As in other agilepractices, the core team, not theproject manager alone, is respon-sible for interacting and producingthe feature cards. Though therecan be some variations in whatinformation is placed on the cards,Figure 8 shows one example.

Feature-driven development is nota software-only technique. Manyhardware product developmentefforts are driven by first develop-ing a product structure and thenan extensive list of the features.In addition, since more and moreproducts include embedded soft-ware, hardware and software fea-tures are both candidates for thisfeature-driven approach. At thelower levels of granularity, design-ers have to decide which featureswill be implemented in hardwareand which in software.

Tool S3: Feature Breakdown Structure

TPM plans utilize work break-down structures (WBSs) toorganize the work. Although expe-rienced project managers concen-trate first on deliverables and thenon the work necessary to createthose deliverables, work- or task-driven plans often degenerateinto very detailed, prescriptiveplans. Any product has a set offeatures that customers use to



Feature/Component Requirements CardFeature/Component ID: Planned Iteration:



Est. Work Effort:


Dependencies with Other Features:

Figure 8 A feature card.



some purpose. The more quicklywe can link those customers withfeatures they have requested andget feedback on them, the morelikely the product developmenteffort is to be successful. Evenin the physical product arena(as contrasted with softwareproducts), prototypes and sim-ulations of the final product arecritical to success.

Features arent documents aboutfeatures; they are product capabil-ities the customer can touch, feel,and see. Documents are essentialto the product developmentprocess, but they are often poorindicators of real project progress.All too often in TPM, deliverablesare documents, and the workbreakdown structures becomedocument delivery schedules.

Tool S4: Release, Milestone,and Iteration Plans

When people first learn aboutiterative development, they oftenthink in just terms of short time-boxed iterations. However, thereare two components to iterativeplanning the short iterationsand the use of features ratherthan tasks. Basing plans onthe products features (and itsarchitecture, which is instantiatedby features) keeps the projectteam and the products customerssynchronized (because the cus-tomers understand the productalthough they may not understandthe technical activities). It alsofocuses the team on delivering

the product rather than intermedi-ate documentation artifacts.

Its not that documentationartifacts are not useful; no onewould consider building, say, anairplane or an automobile withoutextensive documentation. Theproblem is not documentationper se but that project teams oftenget lost producing intermediateartifacts that have little bearing onthe final product. Feature-drivenplanning attempts to overcomethis problem.

Many project managers cantfathom a 12-month project brokendown into two-week iterations and in some ways this is under-standable. Once projects gobeyond four to five months, theyusually need interim checkpointsbetween two-week intervals andthe projects end. Larger projectsthat employ distributed teamsor vendor-supplied componentswill have problems synchronizingevery two weeks. So many proj-ects will require three (or evenmore) levels of iteration. Thelongest period is the release cycle.Products are generally releasedto customers periodically onceevery year or 18 months, forexample. As such, releaseimplies a release for customer use.

On the other end of the spectrum,an iteration is used by a develop-ment team to focus on smallincrements of work. In agile soft-ware development, an iterationmight be two weeks (XP), 30 days(Scrum), or slightly longer for

some projects. If youre buildingan airplane, the iterations willsurely be longer. Although con-tinuous integration is desirablefor software development, allfeatures developed within afeature team (usually fewer than10 people that work on a groupof features) should be integrated,and tested, by the end of theiteration.

From a technical perspective,milestones are intermediatepoints usually from one tothree months. Milestones canhave both a project managementfunction and a technical function.From a project management per-spective, milestones provide achance to review progress andmake more significant projectadjustments. For example,although most agilists recom-mend project mini-retrospectivesat the end of each iteration, mostwould actually employ themevery two to three iterations if theiterations were short (two weeks).Milestones can also be used asmajor synchronization and inte-gration points. For a product thathas both hardware and softwarecomponents, monthly (or evenlonger) synchronizations maybe entirely adequate. A softwareproduct team utilizing an externalvendor for a component mightplan to integrate that componentstarting at milestone two (twomonths into the project) and atevery other milestone after that;biweekly synchronization couldbe too costly. On the other hand,if less-frequent synchronizations

are going poorly, it might indicatethat the synchronization shouldoccur more frequently.

Tool S5: Iteration 0

Some people think agile devel-opment gives them an opportunityto dive in and build (or code, inthe software arena). They con-demn agile methods, sayingthey spend little or no time onearly requirements gathering orarchitectural issues. On the otherhand, there has been an equallynegative reaction to months andmonths of planning, requirementsspecification, and architecturalphilosophizing. There is obviouslya balance point, but many argu-ments imply there is no middleground. Iteration 0 is a tool tohelp teams find that middleground. The zero implies thatnothing useful to the customer features, in other words getsdelivered in this time period.However, the fact that we havedesignated an iteration impliesthat the work is useful to someother stakeholder.

A large business application proj-ect, one that must be integratedwith other business applications,may require some data architec-ture work in order to adequatelydefine the interfaces with thoseother applications. Teams utilizingunfamiliar technology may needtime for training prior to the proj-ects launch. A customer maydemand a more detailed require-ments document prior to signinga contract. All of these examples

indicate a need for some timeexpenditure prior to launchinginto actual feature development.

Though the range of issues canbe broad, the outcome is thesame some projects requiremore extensive initializationwork than others. The key toeffectively utilizing Iteration 0 isto balance the possible advan-tages of further planning withthe growing disadvantage of lackof customer-deliverable features.There are always tradeoffs. Ifthe cost of a technical platformchange is very high, then addi-tional work to improve the oddsof a correct decision may bejustified. Iteration 0 for a next-generation jumbo jetliner willbe much different than that fora standalone software product.

Iteratively Deliver Features

Managing agile projects hasproven difficult for many tradition-ally trained project managers.TPM deals with plans, tasks, PERTcharts, resource loads, and othertools that impart a deterministicflavor to projects. Surely, with allof these charts and graphs andsophisticated estimates, the proj-ect team merely has to executeaccording to the plan, and allwill be well.

Exploration projects are full ofchange, uncertainty, risk, andambiguity. Actually, most projectsexhibit these characteristics; wejust manage to sweep them underthe rug with all the traditional

project management tools. Prob-ably the most difficult mentalswitch for agile teams and agileproject managers is the switchfrom a deterministic mindset toan emergent one. A deterministicmindset says, We KNOW howto do everything lets get onwith it. An emergent mindsetsays, We understand the vis-ion, but the details are murky.However, we believe that thisteam will figure out the detailsas the project unfolds. Thesolution will emerge from thecollective knowledge and inter-actions of the team members.

APM requires a leadership-collaboration management style(see The Nine Principles of AgileProject Management beginningon page 30), one that encourages,and believes in, the power ofemergent behavior. As such,the key project managementtasks are establishing a visionand constraints and then creatinga collaborative work environmentin which emergence thrives. Thetools in this section are focusedon the latter objective.

Tool I1: Daily TeamIntegration Meetings

Normally the first agile tool imple-mented by my clients is the dailyteam integration meeting. Thesedaily get-togethers (referred toas Scrum meetings in the Scrummethodology or daily stand-upmeetings in XP) focus on oneobjective peer-to-peer infor-mation exchange. Daily software



builds are used to raise the vis-ibility of development work andensure that code modules inte-grate. Daily Scrum meetingsserve the same purpose forpeople raising the visibility ofeach persons work (to facilitateknowledge sharing and reduceoverlapping tasks) and ensuringthat their work is integrated. Ifdaily builds are good for code,then daily builds should beeven better for people [9].

The daily integration meetingenables the team to monitorstatus, focus on the work to bedone, and raise problems andissues. The meetings:

Are held at the same timeand place every day

Last less than 30 minutes (thetarget should be 15 minutes)

Are attended by all core teammembers

Can be attended by managersto keep track of status butnot to participate

Are used to raise issues andobstacles but not to pursuesolutions

Allow each participant toaddress three questions:What did you do yesterday?What are you planning todo today? What impedimentsgot in the way of your work?

Most team members find theseshort meetings to be efficient andeffective. They eliminate the needfor other meetings and help the

right people to team up to resolveissues. As with any other tool inthe APM toolkit, meeting time,frequency, and attendees willneed to evolve for different situa-tions. One such adaptation mightbe for the core delivery teammembers to meet daily, whilemembers from support functionsjoin in weekly.

Tool I2: Daily Interactionwith Customers

One of the key tenets of agileproject management is closeinteraction with customers. Whendealing with uncertainty, risk, fluidrequirements changes, and tech-nological frontiers, customers(and sponsors) need to be fullyinvolved in identifying features,specifying feature requirements,determining feature priorities,making key tradeoff decisions(cost, schedule, etc.), developingacceptance criteria and tests, andmore. Being a customer for anagile project is not an insignificantjob, but it may not need to be fulltime. The key to keeping the proj-ect moving is very frequent, if notdaily, interaction in which theproject team receives a constantflow of information and decisions.Interaction with customers maybe important to other typesof projects, but it is absolutelyessential with agile projects.

Tool I3: Collaborative Decisionmaking

That one decision-gradient dia-gram was the most importantpiece of the two-day consulting

session, said a product devel-opment VP client recently.

Its difficult to speed up develop-ment when management takesweeks to make key decisions,laments a Dublin, Ireland, devel-opment group whose companyexecutives are in Silicon Valley.

Our project managers are like aherd of deer standing on the high-way with a tractor-trailer truckbearing down on them, says oneproject team member. They cantfigure out which way to jump, butif they dont decide soon, weregoing to get run over.

As I trek around the world of soft-ware development and projectmanagement, Im continuallyamazed at how little organizationsthink about their decisionmakingprocesses. Many of them putmore time and energy into asoftware build process thaninto decisionmaking. However,in a fast-paced agile project,decisionmaking like otheractivities must be done quicklyand effectively. Slow decision-making, revisiting decisions againand again, overanalyzing deci-sions, and poor participation inthe decisionmaking process willdoom a project, as poor decisionscascade into a flood of additionaldecisions.

No doubt, decisionmaking is hard,but it is made harder than neces-sary by poor practices. Althoughrational decisionmaking may bea fantasy, there are practices that



can assist project teams in makingbetter, implementable decisions.Three elements key a decisionprocess: collaborative framing,collaborative decisionmaking, anddecision retrospection. Framingestablishes who gets involvedin the process, while collaborativedecisionmaking establishes howthe whos go about making adecision. Decision retrospectionprovides feedback into thedecisionmaking process.

Collaborative framing. First,forget about the word empow-erment. The intention ofempowerment is to delegatedecisionmaking authority to lowerlevels of organizations. For themost part, empowering involveslots of verbiage and little action,because the fundamental hier-archical, command-control man-agement structure remains firmlyin place. Empowerment focuseson who makes decisions. Collab-orative framing focuses on whogets involved in decisions.Managers who make decisionswithout input from subordinatesand peers make poor decisions.Engineers who make decisionswithout input from managersand peers make poor decisions.Who makes the decision is lessimportant than getting the rightpeople involved in the decision.

The first task in framing decisionsinvolves identifying types of deci-sions that need to be made overthe life of a project. For example,in an agile project, replanningoccurs at the end of each iteration

or milestone. Replanning ofteninvolves making tradeoff deci-sions schedule versus costversus features. To take anotherexample, software projectsshould include a defect triagedecision framework basicallyasking and answering the ques-tion, Is this product shippable?For each decision type, framingquestions are:

Who is affected by thedecision?

Who needs to provide inputto the decision?

Who should be involved in thediscussions about the decision?

Who should make the decision(the manager, the projectmanager, the project team,the project manager withthe team, etc.)?

Who should review thedecision?

What decision criteria shouldbe used?

How and to whom shouldthe decision results becommunicated?

The answers to these questionswill involve overlapping groups.For example, there may be a widegroup of people affected by thedecision, but only selected indi-viduals from those groups may becontacted for input. Everyone whoprovides input to a decision maynot be involved in the discussionsabout those decisions. There maybe an entire set of decisions that

bore project team members,and thus they dont want to beinvolved, while they do want to beheard on other decisions. Sortingout the various involvementsshould not be left to chance.

Staff members often feel isolatedfrom decision processes, notknowing when, why, or how deci-sions got made. Making decisionsis only part of implementing them.Rapid, effective implementationrequires a collaborative processthat involves the right people,who possess the relevant infor-mation, gathered together at theright time.

Many companies and projectmanagers spend far more timeon development processes thandecisionmaking giving rise tothe analogy of a racecar enginerunning on increasingly viscoussludge. Both will grind to a halt.Framing is the first step in gettingthe sludge out of your decision-making process.

Collaborative decisionmaking.Collaboration is hard. Seeminglyinterminable meetings are oftenstruggling in the groan zone,Sam Kaners wonderful term forthe time period in which meetingparticipants struggle to under-stand each other. Though manypeople have heard of the famousteam progression process form-ing, storming, norming, perform-ing (or, more aptly at times,forming, storming, thrashing,crashing), Kaners modelconsists of the divergent zone,



the groan zone, and finally theconverging zone [12].

In many organizations, decision-making is viewed as a win-loseproposition. Participants in theprocess have a preconceivedview of the decision, and theirapproach is to argue as loudly aspossible until the opposition givesup. Collaborative decisionmakingfocuses on win-win or as Kanersays, both/and rather thaneither/or. Win-win decision-making focuses on mutualunderstanding rather than loudposturing. This shouldnt implylack of heated discussion, but adiscussion focused on trying tounderstand the underlying issuesrather than debating preordainedpositions. Collaborative decision-making can be contentious butcivil, based on mutual trust andrespect it moves teams beyondcompromise. I am indebted toCutter Business TechnologyCouncil Fellow Rob Austin forthe term reconceiving to replacecompromise. Collaborativedecisionmaking is a process ofreconceiving a solution to a prob-lem based on information fromall team members. Compromiseimplies giving up one idea foranother; reconceive implies ajoining of ideas.

There are two objectives againstwhich any decisionmakingprocess must be judged. First,does the process result in the bestchoice given the circumstancesin which the decision was made?

Second, was the decision imple-mented? As many project man-agers have found out the hardway, making and implementingdecisions are two different things.How many times have youencountered decisions madewithin the confines of a confer-ence room that completely fallapart when the participants walkout the door? Kaner refers to sus-tainable decisions those thatactually get implemented. Anyonecan make a decision, but effectivemanagers grasp that implementa-tion requires people to understandand support the decision.

A collaborative decisionmakingprocess has three components:principles, framework, and prac-tices. The fundamental principleshave just been alluded to: viewingthe process as a win-win processand treating all participants withrespect. All collaborative practicesare based on trust and respect, orperhaps more precisely, on build-ing trust and respect. Kanersdiverge-groan-converge modelprovides the framework. Practicesrun the gamut from facilitationtricks to decision gradients.

In the diverge-groan-convergeframework, the transition from thedivergent zone to the convergentzone explains how team mem-bers move from having individualopinions to having a unifiedposition. At first, peoples ideasdiverge. Even though each personwants to contribute to successand to make a quick decision,

each wants to voice his or herown opinion. Everyone has adifferent perspective or a differentexperience, which brings neededdiversity to the decision processbut not much agreement.

Convergence occurs as thegroups individual ideas areintegrated into a whole solution.Convergence, done correctly,does not necessarily mean thateveryone is in complete agree-ment but that everyone has partic-ipated and will support the finaldecision. The goal is not merelyagreement, but sustainableagreement a unified position.

The transition period betweendivergence and convergence, thegroan zone, is the time duringwhich team members groan andcomplain. In the divergent zone,most group members voice theiropinions to make sure their ownideas are heard by the group.Much of this time could be con-sidered presentation, duringwhich members are less con-cerned with understandingeach other than with selling theirown ideas. They begin to groanbecause they are trying to under-stand one another, and under-standing requires thought. It isrelatively easy to take a positionand argue for it. It is much moredifficult to attempt to understandwhy other participants hold otheropinions. The groan zone providesa perfect description of whathappens in most teams it is a



turbulent zone where innovative,creative results are generated.

An additional benefit to a collabo-rative process such as the one justdescribed is that as mutual under-standing of the context (includingthe decision criteria) increases,the time required to make similardecisions decreases rapidly. Forexample, a defect triage team thatdevelops a shared understandingof the relevant factors involvedin reaching decisions will speedup its decisions over time. Con-versely, teams that do not takesome additional time in the begin-ning to fully understand forexample, to understand eachothers perspective on quality will constantly argue the samepoints meeting after meeting.

Different kinds of decisionsrequire different processes. Coinflipping works for deciding whattime to go to lunch. Project man-agers must often make decisionswithout explicit group discussion.However, the key decisions thatimpact the project team will bebetter served by a collaborativedecision process.

Decision retrospection. If projectretrospectives are difficult to doin general, decision retrospec-tives border on the impossible,because finding whom to blameoften seems more importantthan learning. But how do weget better at decisions unlesswe understand which onesworked out well and which onesdidnt? We are sometimes our

own worst enemies. In the med-ical profession, for example, airingmistakes is especially difficultbecause of the threat of medicalmalpractice suits. Sharing andlearning from decisions becomeseverely inhibited; therefore, thesame mistakes are repeated byother doctors or other hospitalsbecause little retrospectionoccurs. A recent television pro-gram described an initiative inthe northeastern US in whichthis veil of secrecy was lifted in aconcerted and collaborative effortbetween doctors and hospitals.Not surprisingly, problem ratesdecreased.

Still, few organizations want toexamine decisions in any depth,which probably corresponds tothe general lack of interest indecisionmaking. Was a buggyproduct shipped? Why? What wasthe series of decisions that led upto the ship decision? Maybe thedecision was actually a goodone from a market perspective.If so, then the development staffneeds to understand the natureof the decision, why it was made,and who was involved in thedecision. Maybe the decision wasbased on market timing informa-tion, but the decisionmakers justdidnt listen to the developers,and the actual release was adisaster. If the disaster isnt ana-lyzed, if the decision tradeoff ofproduct stability versus marketneed isnt revisited, then nothingwill be learned, and similar mis-takes will be made in the future.

Or a decision may be perceivedas incorrect, but further analysisshows that it was actually the cor-rect one give the circumstances.In this case, lack of analysis mightkeep us from making the samecorrect decision in the future.

Collaborative decisionmaking mayspell the difference between suc-cess and failure on agile projects.Framing decisions, developinga collaborative decisionmakingprocess, and conducting decisionretrospectives to learn from bothsuccess and failure are requiredcomponents of this practice.

Tool I4: Set- and Delay-BasedDecisionmaking

Point-based engineering domi-nates product development. Point-based engineering views designas a series of serial decisions inwhich each decision narrows theoptions for further decisions, andthe product progresses in a steadyfashion from a gleam in the mar-keters eye to a final product.

Toyota upset this applecart, atleast as it pertains to the auto-motive industrys design process.Toyotas approach, set-basedconcurrent engineering