AGILEPRACTICEGUIDE

Thisbookwasprintedutilizingapatentedanti-counterfeitprinttechnologydesignedtopreventunauthorizedreproductions.Thepapercolorisgrayinsteadofwhite.Whenthepagesofthebookarecopiedorscannedahiddenwarningmessagewillappearinthebackground.Thissecurityfeatureisintendedtodiscourageanyonefromattemptingtoillegallyreproduceorcounterfeitthisbook.

LibraryofCongressCataloging-in-PublicationDatahasbeenappliedfor.

ISBN:978-1-62825-199-9

Publishedby:ProjectManagementInstitute,Inc.

14CampusBoulevardNewtownSquare,Pennsylvania19073-3299USAPhone:+1610-356-4600Fax:+1610-356-4647Email:customercare@pmi.orgInternet:www.PMI.org

©2017ProjectManagementInstitute,Inc.Allrightsreserved.

ProjectManagementInstitute,Inc.contentiscopyrightprotectedbyU.S.intellectualpropertylawthatisrecognizedbymostcountries.TorepublishorreproducePMI'scontent,youmustobtainourpermission.Pleasegotohttp://www.pmi.org/permissionsfordetails.

ToplaceaTradeOrderorforpricinginformation,pleasecontactIndependentPublishersGroup:IndependentPublishersGroup

OrderDepartment

814NorthFranklinStreetChicago,IL60610USAPhone:+1800-888-4741Fax:+1312-337-5985Email: orders@ipgbook.com (For orders only) For all other inquiries, please contact the PMI Book

ServiceCenter.PMIBookServiceCenterP.O.Box932683,Atlanta,GA31193-2683USAPhone:1-866-276-4764(withintheU.S.orCanada)or

+1-770-280-4129(globally)Fax:+1-770-280-4113Email:info@bookorders.pmi.org

PrintedintheUnitedStatesofAmerica.Nopartofthisworkmaybereproducedortransmittedinanyformorbyanymeans,electronic,manual,photocopying,recording,orbyanyinformationstorageandretrievalsystem,withoutpriorwrittenpermissionofthepublisher.

ThepaperusedinthisbookcomplieswiththePermanentPaperStandardissuedbytheNationalInformationStandardsOrganization(Z39.48—1984).

InformationStandardsOrganization(Z39.48—1984).

PMI,thePMIlogo,PMBOK,OPM3,PMP,CAPM,PgMP,PfMP,PMI-RMP,PMI-SP,PMI-ACP,PMI-PBA,PROJECTMANAGEMENTJOURNAL,PMNETWORK,PMITODAY,PULSEOFTHEPROFESSIONandthesloganMAKINGPROJECTMANAGEMENTINDISPENSABLEFORBUSINESSRESULTS.areallmarksofProjectManagementInstitute,Inc.ForacomprehensivelistofPMItrademarks,contactthePMILegalDepartment.Allothertrademarks,servicemarks,tradenames,tradedress,productnamesandlogosappearinghereinarethepropertyoftheirrespectiveowners.Anyrightsnotexpresslygrantedhereinarereserved.

SAFeisaregisteredmarkofScaledAgile,Inc.

AgileAllianceandtheAgileAlliancelogoaremarksofAgileAlliance.

ThisPracticeGuidewasjointlyfundedbyAgileAlliance®andwasdevelopedincollaborationwithmembersoftheAgileAlliance®.AgileAlliance®doesnotendorseanyagilemethodologyorcertification.

10987654321

NOTICE

The Project Management Institute, Inc. (PMI) standards and guidelinepublications, of which the document contained herein is one, are developedthrough a voluntary consensus standards development process. This processbrings together volunteers and/or seeks out the views of personswhohave aninterest in the topic covered by this publication. While PMI administers theprocess and establishes rules to promote fairness in the development ofconsensus, it does not write the document and it does not independently test,evaluate, or verify the accuracy or completeness of any information or thesoundness of any judgments contained in its standards and guidelinepublications.

PMIdisclaimsliabilityforanypersonalinjury,propertyorotherdamagesofanynaturewhatsoever,whetherspecial,indirect,consequentialorcompensatory,directly or indirectly resulting from the publication, use of application, orrelianceon thisdocument.PMIdisclaimsandmakesnoguarantyorwarranty,expressed or implied, as to the accuracy or completeness of any informationpublishedherein,anddisclaimsandmakesnowarranty that the information inthisdocumentwillfulfillanyofyourparticularpurposesorneeds.PMIdoesnotundertake to guarantee the performance of any individual manufacturer orseller'sproductsorservicesbyvirtueofthisstandardorguide.

Inpublishingandmakingthisdocumentavailable,PMIisnotundertakingtorenderprofessionalorotherservicesfororonbehalfofanypersonorentity,noris PMI undertaking to perform any duty owed by any person or entity tosomeone else. Anyone using this document should rely on his or her ownindependent judgment or, as appropriate, seek the advice of a competentprofessional in determining the exercise of reasonable care in any givencircumstances. Information and other standards on the topic covered by this

publicationmay be available from other sources,which the usermaywish toconsultforadditionalviewsorinformationnotcoveredbythispublication.

PMIhasnopower,nordoesitundertaketopoliceorenforcecompliancewiththe contents of this document. PMI does not certify, test, or inspect products,designs,orinstallationsforsafetyorhealthpurposes.Anycertificationorotherstatement of compliance with any health or safety-related information in thisdocumentshallnotbeattributabletoPMIandissolelytheresponsibilityofthecertifierormakerofthestatement.

PREFACE

TheProjectManagementInstituteandAgileAlliance®charteredthispracticeguidetocreateagreaterunderstandingofagileapproachesintheircommunities.Thevisionforthispracticeguideistoequipprojectteamswithtools,situationalguidelines, and an understanding of the available agile techniques andapproachestoenablebetterresults.

Project teams are using agile approaches in a variety of industries beyondsoftware development.Both organizations realize that expansion has created aneed for a common language, open mindedness, and the willingness to beflexible in how products and deliverables are brought to market. In addition,bothorganizationsrealizetherearemultiplewaystoachievesuccessfuldelivery.There are a broad range of tools, techniques, and frameworks; teams havechoicesforapproachesandpracticesthatfittheirprojectandtheorganizationalcultureinordertoachievethedesiredoutcome.

The Agile Practice Guide core committee members are from varyingbackgroundsandusevariousapproaches.Someof thecommitteemembersareconsultantsandsomeworkinsideorganizations.Allhaveworkedinagilewaysformanyyears.

TABLEOFCONTENTS

1.INTRODUCTION2.ANINTRODUCTIONTOAGILE

2.1DefinableWorkvs.High-UncertaintyWork2.2TheAgileManifestoandMindset2.3LeanandtheKanbanMethod2.4Uncertainty,Risk,andLifeCycleSelection

3.LIFECYCLESELECTION3.1CharacteristicsofProjectLifeCycles

3.1.1CharacteristicsofPredictiveLifeCycles3.1.2CharacteristicsofIterativeLifeCycles3.1.3CharacteristicsofIncrementalLifeCycles3.1.4CharacteristicsofAgileLifeCycles3.1.5AgileSuitabilityFilters3.1.6CharacteristicsofHybridLifeCycles3.1.7CombinedAgileandPredictiveApproaches3.1.8 Predominantly Predictive Approach with Some

AgileComponents3.1.9 A Largely Agile Approach with a Predictive

Component3.1.10HybridLifeCyclesasFit-For-Purpose3.1.11HybridLifeCyclesasTransitionStrategy

3.2MixingAgileApproaches

3.3ProjectFactorsThatInfluenceTailoring4. IMPLEMENTING AGILE: CREATING AN AGILEENVIRONMENT

4.1StartwithanAgileMindset4.2ServantLeadershipEmpowerstheTeam

4.2.1ServantLeaderResponsibilities4.2.2 Role of the Project Manager in an Agile

Environment4.2.3ProjectManagersUseServantLeadership

4.3TeamComposition4.3.1AgileTeams4.3.2AgileRoles4.3.3GeneralizingSpecialists4.3.4TeamStructures4.3.5DedicatedTeamMembers4.3.6TeamWorkspaces4.3.7OvercomingOrganizationalSilos

5. IMPLEMENTING AGILE: DELIVERING IN AN AGILEENVIRONMENT

5.1ChartertheProjectandtheTeam5.2CommonAgilePractices

5.2.1Retrospectives5.2.2BacklogPreparation5.2.3BacklogRefinement5.2.4DailyStandups5.2.5Demonstrations/Reviews5.2.6PlanningforIteration-BasedAgile5.2.7ExecutionPracticesthatHelpTeamsDeliverValue5.2.8 How Iterations and Increments Help Deliver

WorkingProduct5.3TroubleshootingAgileProjectChallenges5.4MeasurementsinAgileProjects

5.4.1AgileTeamsMeasureResults6. ORGANIZATIONAL CONSIDERATIONS FOR PROJECTAGILITY

6.1OrganizationalChangeManagement6.1.1DriversforChangeManagement6.1.2ReadinessforChange

6.2OrganizationalCulture6.2.1CreatinganEnvironmentofSafety6.2.2AssessingCulture

6.3ProcurementandContracts6.4BusinessPractices6.5MultiteamCoordinationandDependencies(Scaling)

6.5.1Frameworks6.5.2Considerations

6.6AgileandtheProjectManagementOffice(PMO)6.6.1AnAgilePMOisValue-Driven6.6.2AnAgilePMOisInvitation-Oriented6.6.3AnAgilePMOisMultidisciplinary

6.7OrganizationalStructure6.8EvolvingtheOrganization

7.ACALLTOACTIONANNEXA1PMBOK®GUIDEMAPPINGANNEXA2AGILEMANIFESTOMAPPINGANNEXA3OVERVIEWOFAGILEANDLEANFRAMEWORKSAPPENDIXX1CONTRIBUTORSANDREVIEWERSAPPENDIXX2

ATTRIBUTESTHATINFLUENCETAILORINGAPPENDIXX3AGILESUITABILITYFILTERTOOLSREFERENCESBIBLIOGRAPHYGLOSSARY

LISTOFTABLESANDFIGURES

Figure2-1. TheFourValuesoftheAgileManifestoFigure2-2. TheTwelvePrinciplesBehindtheAgileManifestoFigure2-3. TheRelationshipBetweentheAgileManifesto

Values,Principles,andCommonPracticesFigure2-4. AgileisaBlanketTermforManyApproachesFigure2-5. UncertaintyandComplexityModelInspiredbythe

StaceyComplexityModelFigure3-1. TheContinuumofLifeCyclesFigure3-2. PredictiveLifeCycleFigure3-3. IterativeLifeCycleFigure3-4. ALifeCycleofVarying-SizedIncrementsFigure3-5. Iteration-BasedandFlow-BasedAgileLifeCyclesFigure3-6. AgileDevelopmentFollowedbyaPredictive

RolloutFigure3-7. ACombinedAgileandPredictiveApproachUsed

SimultaneouslyFigure3-8. ALargelyPredictiveApproachwithAgile

Components

Figure3-9. ALargelyAgileApproachwithaPredictiveComponent

Figure5-1. BurndownChartforRemainingStoryPointsFigure5-2. BurnupChartforShowingStoryPointsCompletedFigure5-3. ExampleofaKanbanBoardFigure5-4. FeatureChartFigure5-5. ProductBacklogBurnupChartFigure5-6. EarnedValueinanAgileContextFigure5-7. CumulativeFlowDiagramofCompletedFeaturesFigure6-1. TheRelationshipBetweenChangeManagement

andAgileApproachesFigure6-2. ExampleofAssessingOrganizationalCultureFigure6-3. InitialRankedBacklogforChangesFigure6-4. UsingBacklogsandKanbanBoardstoOrganize

andTrackChangeWorkFigureA3-1. AgileApproachesPlottedbyBreadthandDetailFigureA3-2. KanbanBoardDemonstratingWorkinProgress

Limits,andaPullSystemtoOptimizetheFlowofWork

FigureA3-3. TheCrystalFamilyofMethodsFigureA3-4. Feature-DrivenDevelopmentProjectLifeCycleFigureA3-5. DSDMApproachtoConstraint-DrivenAgilityFigureA3-6. RepresentativesofScrumTeamsParticipatingin

SoSteamsFigureX3-1. ModelforSuitabilityofAgileApproachFigureX3-2. Buy-IntoApproachAssessment

FigureX3-3. TrustinTeamAssessmentFigureX3-4. AssessmentforDecision-MakingPowersofTeamFigureX3-5. TeamSizeAssessmentFigureX3-6. ExperienceLevelAssessmentFigureX3-7. AssessmentforAccesstotheCustomer/BusinessFigureX3-8. LikelihoodofChangeAssessmentFigureX3-9. AssessmentforCriticalityofProductorServiceFigureX3-10.

IncrementalDeliveryAssessment

FigureX3-11.

SuitabilityAssessmentRadarChart

FigureX3-12.

DrugStoreProject

FigureX3-13.

MilitaryMessagingExample

Table1-1. In-ScopeandOut-of-ScopeItemsTable3-1. CharacteristicsofFourCategoriesofLifeCyclesTable3-2. TailoringOptionstoImproveFitTable4-1. AttributesofSuccessfulAgileTeamsTable4-2. AgileTeamRolesTable5-1. AgilePainPointsandTroubleshootingPossibilitiesTableA1-1. ProjectManagementProcessGroupand

KnowledgeAreaMappingTableA1-2. ApplicationofAgileinPMBOK®GuideKnowledge

AreasTableA2-1. AgileManifestoValuesCoveredintheAgile

PracticeGuide

TableA2-2. AgilePracticeGuideMappingofPrinciplesBehindtheAgileManifesto

TableA3-1. ScrumEventsandArtifactsTableA3-2. ThePracticesofeXtremeProgrammingTableA3-3. DefiningPrinciplesandPropertiesoftheKanban

MethodTableA3-4. TheCoreValuesandCommonPropertiesof

CrystalTableA3-5. TheKeyElementsoftheAgileUnifiedProcessTableA3-6. ComparisonofLeSSandScrumTableX2-1. TailoringGuidelines

1

INTRODUCTIONWelcome to the Agile Practice Guide! This guide was developed as a

collaborative effort by the Project Management Institute (PMI) and AgileAlliance®.Themembersof thecorewriting teamwhodeveloped thispracticeguide included volunteers from both organizations, drawing on subjectmatterexpertisefromabroadrangeofcurrentpractitionersandleadersfromadiverserangeofbackgrounds,beliefs,andcultures.

Thispracticeguideprovidespracticalguidancegearedtowardprojectleadersand team members adapting to an agile approach in planning and executingprojects.Whileourcorewritingteamrecognizesthereisstaunchsupporttousepredictive approaches and conversely, passion around shifting to an agilemindset,values,andprinciples,thispracticeguidecoversapracticalapproachtoproject agility. This practice guide represents a bridge to understanding thepathway from a predictive approach to an agile approach. In fact, there aresimilaractivitiesbetweenthetwo,suchasplanning,thatarehandleddifferentlybutoccurinbothenvironments.

Our corewriting teamused an agilemindset to collaborate andmanage thedevelopmentofthisfirsteditionofthepracticeguide.Astechnologyandculturechanges,futureupdatesandrefinementstothepracticeguidewillreflectcurrentapproaches.

Ourcoreteamadoptedamoreinformal,relaxedwritingstyleforthispracticeguide than is typical forPMI standards.Theguide incorporatesnewelements,such as tips, sidebars, and case studies to better illustrate key points andconcepts.Our teamintendsfor thesechangestomakethispracticeguidemorereadableanduser-friendly.

Thispracticeguidegoesbeyondaddressing theuseofagile in thecomputersoftware development industry, because agile has expanded into non-software

development environments. Manufacturing, education, healthcare and otherindustriesarebecomingagiletovaryingdegreesandthisusebeyondsoftwareiswithinthescopeofthispracticeguide.

AGILE-BASEDLEARNING

Education is a prime and fertile ground to expand agile practices beyondsoftware development. Teachers in middle schools, high schools, anduniversitiesaroundtheworldarebeginningtouseagiletocreateacultureoflearning.Agiletechniquesareusedtoprovidefocusonprioritizingcompetingpriorities. Face-to-face interaction, meaningful learning, self-organizingteams, and incremental and/or iterative learning that exploit the imaginationare all agile principles that can change the mindset in the classroom andadvanceeducationalgoals(Briggs,2014).*

*Briggs,Sara.“AgileBasedLearning:WhatIsItandHowCanItChangeEducation?” Opencolleges.edu.au February 22, 2014, retrieved fromhttp://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/

SowhyanAgilePracticeGuideandwhynow?Projectteamshaveusedagiletechniques and approaches in various forms for at least several decades. TheAgileManifesto [1]1 expresseddefinitive values andprinciples of agile as theuse of agile gained substantial momentum (see Section 2.1). Today, projectleaders and teams find themselves in an environmentdisruptedbyexponentialadvances in technology and demands from customers for more immediatedelivery of value. Agile techniques and approaches effectively managedisruptive technologies. Inaddition, the firstprincipleofagileplacescustomersatisfactionasthehighestpriorityandiskeyindeliveringproductsandservicesthat delight customers (see Section 2.1). Rapid and transparent customerfeedback loops are readily availablewith thewidespread use of socialmedia.Therefore,inordertostaycompetitiveandrelevant,organizationscannolongerbe internally focused but rather need to focus outwardly to the customerexperience.

Disruptive technologiesare rapidlychanging theplaying fieldbydecreasingthebarrierstoentry.Morematureorganizationsareincreasinglypronetobeinghighly complex and potentially slow to innovate, and lag behind in deliveringnewsolutionstotheircustomers.Theseorganizationsfindthemselvescompeting

withsmallerorganizationsandstartupsthatareabletorapidlyproduceproductsthat fit customer needs. This speed of change will continue to drive largeorganizations to adopt an agilemindset in order to stay competitive and keeptheirexistingmarketshare.

DISRUPTIVETECHNOLOGY

Disruptive technology is especially enabled by the transition to cloudcomputing.Companies across the globe are leveraging themodel for quickand cheap access to computing resources and to gain entry into traditionalmarkets. Cloud computing requires a reduced upfront payment, but is paidovertimeviaasubscriptionservice,baseduponapay-as-you-goorpay-what-you-use model. Updated applications, infrastructure, and platforms arereleasedinto thecloudinan iterativeandincrementalfashion,keepingpacewithimprovementstotechnologyandevolvingcustomerdemand.

TheAgilePracticeGuide isproject-focusedandaddressesproject life cycleselection, implementing agile, and organizational considerations for agileprojects. Organizational change management (OCM) is essential forimplementing or transforming practices but, sinceOCM is a disciplinewithinitself, it is outside the scopeof this practiceguide.Those seekingguidance inOCMmayrefertoManagingChangeinOrganizations—APracticeGuide[2].

AdditionalitemsthatareinscopeandoutofscopeforthispracticeguidearelistedinTable1-1.

Table1-1.In-ScopeandOut-of-ScopeItems

InScope OutofScope

Implementingagileapproachesataprojectorteamlevel

Implementingagilethroughouttheorganizationorcreatingagileprograms

Coverageofmostpopularagileapproaches,aslistedinindustrysurveys

Coverageofnicheapproaches,company-specificmethods,orincompletelifecycletechniques

Suitabilityfactorstoconsiderwhenchoosinganagileapproachand/orpractice

Recommendingorendorsingaparticularapproach/practice

MappingagiletoPMBOK®GuideprocessesandKnowledgeAreas

ChangeormodificationofPMBOK®Guideprocessesand/orKnowledgeAreas

Discussionontheuseofagilebeyondsoftwaredevelopment

Removalofsoftwareindustryinfluenceonagileapproaches.(Notethatsoftwareisincludedin

development approaches.(Notethatsoftwareisincludedinthispracticeguideeventhoughtheuseofagileisgrowinginmanyotherindustriesbeyondsoftware.)

Guidance,techniques,andapproachestoconsiderwhenimplementingagileinprojectsororganizations

Prescriptivestep-by-stepinstructionsonhowtoimplementagileinprojectsororganizations

Definitionsofgenerallyacceptedterms Newtermsand/ordefinitions

This practice guide is for project teams who find themselves in the messymiddle-ground between predictive and agile approaches, who are trying toaddress rapid innovation and complexity, andwho are dedicated to the team'simprovement. This practice guide provides useful guidance for successfulprojectsthatdeliverbusinessvaluetomeetcustomerexpectationsandneeds.

Thispracticeguideisorganizedasfollows:

Section 2 An Introduction to Agile—This section includes the AgileManifesto mindset, values, and principles. It also covers the concepts ofdefinable and high-uncertainty work, and the correlation between lean, theKanbanMethod,andagileapproaches.

Section 3 Life Cycle Selection—This section introduces the various lifecycles discussed in this practice guide. This section also addresses suitabilityfilters,tailoringguidelines,andcommoncombinationsofapproaches.

Section 4 Implementing Agile: Creating an Agile Environment—Thissectiondiscussescriticalfactorstoconsiderwhencreatinganagileenvironmentsuchasservantleadershipandteamcomposition.

Section5ImplementingAgile:DeliveringinanAgileEnvironment—Thissection includes information on how to organize teams and common practicesteams canuse for deliveringvalueon a regular basis. It provides examples ofempiricalmeasurementsforteamsandforreportingstatus.

Section6OrganizationalConsiderationsforProjectAgility—Thissectionexploresorganizationalfactorsthat impacttheuseofagileapproaches,suchasculture,readiness,businesspractices,andtheroleofaPMO.

Section7ACalltoAction—Thecalltoactionrequestsinputforcontinuousimprovementofthispracticeguide.

The annexes, appendixes, references, bibliography, and glossary provideadditionalusefulinformationanddefinitions:

Annexes. Contain mandatory information that is too lengthy forinclusioninthemainbodyofthepracticeguide.

Appendixes.Containnonmandatoryinformationthatsupplementsthemainbodyofthispracticeguide.

References.Identifywheretolocatestandardsandotherpublicationsthatarecitedinthispracticeguide.

Bibliography. Lists additional publications by section that providedetailedinformationontopicscoveredinthispracticeguide.

Glossary.Presentsalistoftermsandtheirdefinitionsthatareusedinthispracticeguide.

1Thenumbersinbracketsrefertothelistofreferencesattheendofthispracticeguide.

2

ANINTRODUCTIONTOAGILE

2.1DEFINABLEWORKVS.HIGH-UNCERTAINTYWORKProjectworkrangesfromdefinableworktohigh-uncertaintywork.Definable

workprojectsarecharacterizedbyclearproceduresthathaveprovedsuccessfulonsimilarprojects in thepast.Theproductionofacar,electricalappliance,orhome after the design is complete are examples of definable work. Theproductiondomainandprocessesinvolvedareusuallywellunderstoodandtherearetypicallylowlevelsofexecutionuncertaintyandrisk.

New design, problem solving, and not-done-before work is exploratory. Itrequires subject matter experts to collaborate and solve problems to create asolution. Examples of people encountering high-uncertainty work includesoftware systems engineers, product designers, doctors, teachers, lawyers, andmanyproblem-solvingengineers.Asmoredefinableworkisautomated,projectteams are undertaking more high-uncertainty work projects that require thetechniquesdescribedinthispracticeguide.

High-uncertainty projects have high rates of change, complexity, and risk.Thesecharacteristicscanpresentproblemsfortraditionalpredictiveapproachesthataimtodeterminethebulkoftherequirementsupfrontandcontrolchangesthrough a change request process. Instead, agile approaches were created toexplore feasibility in short cycles and quickly adapt based on evaluation andfeedback.

2.2THEAGILEMANIFESTOANDMINDSET

Thought leaders in the software industry formalized the agilemovement in2001withthepublicationoftheManifestoforAgileSoftwareDevelopment(seeFigure2-1).

TwelveclarifyingprinciplesflowedfromthesevaluesasshowninFigure2-2.

Although originating in the software industry, these principles have sincespreadtomanyotherindustries.

Thisembodimentofmindset,values,andprinciplesdefineswhatconstitutesan agile approach. The various agile approaches in use today share commonrootswiththeagilemindset,value,andprinciples.ThisrelationshipisshowninFigure2-3.

AsshowninFigure2-3,themodel,inspiredbyAhmedSidky,articulatesagileas a mindset defined by the Agile Manifesto values, guided by the AgileManifesto principles, and enabled by various practices. It isworth noting thatwhile the term“agile”becamepopularizedafter theManifesto, theapproachesand techniques being used by project teams today existed before the AgileManifestobymanyyearsand,insomecases,decades.

Agileapproachesandagilemethodsareumbrellatermsthatcoveravarietyofframeworksandmethods.Figure2-4placesagileincontextandvisualizesitasablanketterm,referringtoanykindofapproach,technique,framework,method,orpracticethatfulfillsthevaluesandprinciplesoftheAgileManifesto.Figure2-4alsoshowsagileandtheKanbanMethodassubsetsoflean.Thisisbecausethey are named instances of lean thinking that share lean concepts such as:“focusonvalue,”“smallbatchsizes,”and“eliminationofwaste.”

Is agile an approach, amethod, a practice, a technique, or a framework?Anyorallofthesetermscouldapplydependingonthesituation.Thispracticeguide, uses the term “approach” unless one of the other terms is obviouslymorecorrect.

Ingeneral, thereare twostrategies to fulfillagilevaluesandprinciples.Thefirst is to adopt a formal agile approach, intentionally designed and proven toachieve desired results. Then take time to learn and understand the agileapproachesbeforechangingortailoringthem.Prematureandhaphazardtailoringcanminimizetheeffectsoftheapproachandthuslimitbenefits.(SeeAppendixX2forTailoringConsiderations).

Thesecondstrategyistoimplementchangestoprojectpracticesinamannerthatfitstheprojectcontexttoachieveprogressonacorevalueorprinciple.Usetimeboxestocreatefeatures,orspecifictechniquestoiterativelyrefinefeatures.Considerdividinguponelargeprojectintoseveralreleases,ifthatworksforthespecificprojectcontext.Implementchangesthatwillhelptheprojectsucceed—thechangesdonotneedtobepartoftheorganization'sformalpractices.Theendgoalisnottobeagileforitsownsake,butrathertodeliveracontinuousflowof

valuetocustomersandachievebetterbusinessoutcomes.

2.3LEANANDTHEKANBANMETHODOnewaytothinkabouttherelationshipbetweenlean,agile,andtheKanban

Method is to consider agile and the Kanban Method as descendants of leanthinking.Inotherwords,leanthinkingisasuperset,sharingattributeswithagileandKanban.

This sharedheritage isverysimilarand focusesondeliveringvalue, respectfor people, minimizing waste, being transparent, adapting to change, andcontinuouslyimproving.Projectteamssometimesfinditusefultoblendvariousmethods—whateverworksfortheorganizationorteamiswhatshouldbedoneregardless of its origin. The objective is the best outcome regardless of theapproachused.

The KanbanMethod is inspired by the original lean-manufacturing systemand used specifically for knowledgework. It emerged in themid-2000s as analternativetotheagilemethodsthatwereprevalentatthetime.

TheKanbanMethodislessprescriptivethansomeagileapproachesandlessdisruptive,asitistheoriginal“start-where-you-are”approach.ProjectteamscanbeginapplyingtheKanbanMethodwithrelativeeaseandprogresstowardotheragile approaches if that iswhat theydeemnecessaryor appropriate.Formoredetailson theKanbanMethod,seeAnnexA3onOverviewofAgileandLeanFrameworks.

CASE

There is and probably always will be a lot of discussion around theKanbanMethodandwhether itbelongs to the leanoragilemovement. Itwas conceived in and around lean manufacturing, but is widely used inagilesettings.

2.4UNCERTAINTY,RISK,ANDLIFECYCLESELECTION

SELECTIONSomeprojectshaveconsiderableuncertaintyaroundprojectrequirementsand

how to fulfill those requirements using current knowledge and technology.These uncertainties can contribute to high rates of change and projectcomplexity.ThesecharacteristicsareillustratedinFigure2-5.

Asprojectuncertaintyincreases,sotoodoestheriskofreworkandtheneedtouseadifferentapproach.Tomitigate the impactof these risks, teamsselectlifecycles that allow them to tackleprojectswithhighamountsofuncertaintyviasmallincrementsofwork.

Teamscanverifytheirworkwhentheyusesmallincrementsandcanchangewhattheydonext.Whenteamsdeliversmallincrements,theyarebetterabletounderstandthetruecustomerrequirementsfasterandmoreaccuratelythanwithastaticwrittenspecification.

Teamscanplanandmanageprojectswithclearandstable requirementsand

clear technical challengeswith little difficulty.However, as the uncertainty intheproject increases, the likelihoodof changes,wastedwork, and reworkalsoincreases,whichiscostlyandtimeconsuming.

Someteamshaveevolvedprojectlifecyclestouseiterativeandincrementalapproaches. Many teams discover that when they explore the requirementsiteratively and deliver more often incrementally, the teams adapt to changesmore easily. These iterative and incremental approaches reduce waste andreworkbecausetheteamsgainfeedback.Theseapproachesuse:

Veryshortfeedbackloops,

Frequentadaptationofprocess,

Reprioritization,

Regularlyupdatedplans,and

Frequentdelivery.

TIP

What do simple, complicated, and complex projects mean? Considerlarge projects, such as the Boston Big Dig construction project. On thesurface, the project seemed fairly straightforward: move the elevatedhighwayunderground.Therewashighagreementontherequirements(seethe Y axis in Figure 2-5). Therewas low uncertainty on how the projectwouldproceeduntiltheprojectstarted.And,asisthecaseformanylargeprojects,theprojectencounteredsurprisesalongtheway.

When a team works on a project where there is little opportunity forinterim deliverables or little opportunity for prototyping, the team mostlikelywilluseapredictive lifecycle tomanage it.The teamcanadapt towhat itdiscovers,butwillnotbeable touseagileapproaches tomanagethe iterative discovery of requirements or incremental deliverables forfeedback.

The Big Dig project was not simple by any means. However, manyprojectsthatstartoutinthelowerleftpartoftheStaceyComplexityModelhavenorealmeansofmovingtootherapproaches.Assesstheproject,bothin the requirements and the means of delivery, to determine the bestapproachforthelifecycleoftheproject.

Theseiterative,incremental,andagileapproachesworkwellforprojectsthatinvolvenewornoveltools,techniques,materials,orapplicationdomains.(RefertoSection3onLifeCycleSelection).Theyalsoworkwellforprojectsthat:

Requireresearchanddevelopment;

Havehighratesofchange;

Haveunclearorunknownrequirements,uncertainty,orrisk;or

Haveafinalgoalthatishardtodescribe.

Bybuildingasmallincrementandthentestingandreviewingit,theteamcanexplore uncertainty at a low cost in a short time, reduce risk, and maximizebusiness value delivery. This uncertainty may be centered on suitability andrequirements (is the right product being built?); technical feasibility andperformance(canthisproductbebuiltthisway?);orprocessandpeople(isthisan effective way for the team to work?). All three of these characteristics—product specification, production capability, and process suitability—typicallyhaveelementsofhighuncertainty.

However, iterative and incremental approaches have their limits ofapplicability.When both technology uncertainty and requirements uncertaintyareveryhigh(thetoprightofFigure2-5),theprojectmovesbeyondcomplextochaotic.Inorderfortheprojecttobecomereliablypossible,itneedsoneofthevariables(uncertaintyordisagreement)tobecontained.

3

LIFECYCLESELECTION

Projects come inmany shapes and there are a variety ofways to undertakethem.Projectteamsneedawarenessofthecharacteristicsandoptionsavailabletoselecttheapproachmostlikelytobesuccessfulforthesituation.

Thispracticeguidereferstofourtypesoflifecycles,definedasfollows:

Predictive life cycle.Amore traditional approach,with the bulk ofplanning occurring upfront, then executing in a single pass; asequentialprocess.

Iterativelifecycle.Anapproachthatallowsfeedbackforunfinishedworktoimproveandmodifythatwork.

Incremental life cycle. An approach that provides finisheddeliverablesthatthecustomermaybeabletouseimmediately.

Agilelifecycle.Anapproachthatisbothiterativeandincrementaltorefineworkitemsanddeliverfrequently.

WHATTOCALLNON-AGILEAPPROACHES?

There is no single term that is universally used to describe non-agileapproaches.Initially,thepracticeguideusedthetermplan-driventodescribetheemphasisonanupfrontplanandthenexecutionofthatplan.Somepeoplepreferthetermswaterfallorserial todescribethislifecycle.Intheend,wesettled on the term predictive since it is used in A Guide to the ProjectManagement Body of Knowledge (PMBOK® Guide) [3] and the SoftwareExtensiontothePMBOK®GuideFifthEdition[4].

Manyorganizationsdonotexperienceeitheroftheseextremesandinstead

occupysomemiddleground.That isnatural,butwestillneedawayto talkaboutbothendsofthespectrum.Ifagileisatoneend,wecalltheotherendpredictive.

3.1CHARACTERISTICSOFPROJECTLIFECYCLESTable 3-1 summarizes the characteristics of the four life cycle categories

coveredinthispracticeguide.

Itisimportanttonotethatallprojectshavethesecharacteristics—noprojectiscompletelydevoidofconsiderationsaroundrequirements,delivery,change,andgoals.Aproject's inherentcharacteristicsdeterminewhichlifecycleis thebestfitforthatproject.

Another way to understand how project life cycles vary is by using acontinuum ranging from predictive cycles on one end, to agile cycles on theotherend,withmoreiterativeorincrementalcyclesinthemiddle.

FigureX3-1ofAppendixX3ofthePMBOK®Guide–SixthEditiondisplaysthe continuum as a flat line. This view emphasizes the shifting of projectcharacteristics from one end to the other. Another way to visualize thecontinuumiswithatwo-dimensionalsquare,asshowninFigure3-1.

Nolifecyclecanbeperfectforallprojects.Instead,eachprojectfindsaspoton the continuum that provides an optimum balance of characteristics for itscontext.Specifically,

Predictive life cycles.Takeadvantageof things that areknownandproven. This reduced uncertainty and complexity allows teams tosegmentworkintoasequenceofpredictablegroupings.

Iterative life cycles. Allow feedback on partially completed orunfinishedworktoimproveandmodifythatwork.

Incremental life cycles. Provide finished deliverables that thecustomermaybeabletouseimmediately.

Agile life cycles. Leverage both the aspects of iterative andincremental characteristics. When teams use agile approaches, theyiterateovertheproducttocreatefinisheddeliverables.Theteamgainsearly feedback and provides customer visibility, confidence, and

control of the product. Because the team can release earlier, theprojectmayprovideanearlierreturnoninvestmentbecausetheteamdeliversthehighestvalueworkfirst.

PLANNINGISALWAYSTHERE

Akey thing to remember about life cycles is that eachof themshare theelementofplanning.Whatdifferentiatesalifecycleisnotwhetherplanningisdone,butratherhowmuchplanningisdoneandwhen.

Atthepredictiveendofthecontinuum,theplandrivesthework.Asmuchplanningasispossibleisperformedupfront.Requirementsareidentifiedinasmuch detail as possible. The team estimates when they can deliver whichdeliverablesandperformscomprehensiveprocurementactivities.

In iterative approaches, prototypes and proofs are also planned, but theoutputs are intended to modify the plans created in the beginning. Earlierreviewsofunfinishedworkhelpinformfutureprojectwork.

Meanwhile,incrementalinitiativesplantodeliversuccessivesubsetsoftheoverallproject.Teamsmayplan several successivedeliveries in advanceoronlyoneatatime.Thedeliveriesinformthefutureprojectwork.

Agile projects also plan. The key difference is that the team plans andreplans as more information becomes available from review of frequentdeliveries.Regardlessoftheprojectlifecycle,theprojectrequiresplanning.

3.1.1CHARACTERISTICSOFPREDICTIVELIFECYCLES

Predictive lifecyclesexpect to takeadvantageofhighcertaintyaround firmrequirements, a stable team, and low risk. As a result, project activities oftenexecuteinaserialmanner,asshowninFigure3-2.

In order to achieve this approach, the team requires detailed plans to knowwhat todeliverandhow.Theseprojects succeedwhenotherpotentialchangesare restricted (e.g., requirements changes; project teammembers changewhatthe team delivers). Team leaders aim to minimize change for the predictiveproject.

Whentheteamcreatesdetailedrequirementsandplansatthebeginningoftheproject, they can articulate the constraints. The team can then use those

constraintstomanageriskandcost.Astheteamprogressesthroughthedetailedplan,theymonitorandcontrolchangesthatmightaffectthescope,schedule,orbudget.

By emphasizing a departmentally efficient, serialized sequence of work,predictive projects do not typically deliver business value until the end of theproject. If thepredictiveproject encounters changesordisagreementswith therequirements, or if the technological solution is no longer straightforward, thepredictiveprojectwillincurunanticipatedcosts.

3.1.2CHARACTERISTICSOFITERATIVELIFECYCLES

Iterative life cycles improve the product or result through successiveprototypes or proofs of concept. Each new prototype yields new stakeholderfeedbackandteaminsights.Then,theteamincorporatesthenewinformationbyrepeating one or more project activities in the next cycle. Teams may usetimeboxing on a given iteration for a few weeks, gather insights, and thenreworktheactivitybasedonthoseinsights.Inthatway,iterationshelpidentifyandreduceuncertaintyintheproject.

Projectsbenefitfromiterativelifecycleswhencomplexityishigh,whentheproject incurs frequent changes, or when the scope is subject to differingstakeholders’ views of the desired final product. Iterative life cyclesmay takelongerbecausetheyareoptimizedforlearningratherthanspeedofdelivery.

Figure 3-3 illustrates some elements of an iterative project life cycle for asingleproductdelivery.

Haveyoueverbeeninvolvedonaprojectwheretherequirementsseemedto change daily and thought, “We will know the requirements when wedeliveraprototypethatthebusinessapproves.”Ifso,thiswasaprojectwhereagileapproachescouldhavehelped.Aprototypeencouragesfeedbackandabetter understanding of the requirements that can be incorporated into eachdeliverable.

3.1.3CHARACTERISTICSOFINCREMENTALLIFECYCLES

Someprojectsoptimizeforspeedofdelivery.Manybusinessesandinitiativescannotaffordtowaitforeverythingtobecompleted;inthesecases,customersarewillingtoreceiveasubsetoftheoverallsolution.Thisfrequentdeliveryofsmallerdeliverablesiscalledanincrementallifecycle(seeFigure3-4).

TIP

Areyouunsureofhowanewbusiness servicemightwork inpractice?Create a proof of concept with evaluation criteria to explore desiredoutcomes.Useiterativeapproacheswhenyoususpecttherequirementswillchangebasedoncustomerfeedback.

Incremental life cycles optimize work for delivering value to sponsors orcustomersmoreoftenthanasingle,finalproduct.Teamsplaninitialdeliverablesbefore beginning their work, and they beginworking on that first delivery assoon as possible. Some agile projects deliver value within days of projectinitiation.Otherscouldtakelonger,rangingfrom1weektoseveralweeks.

Astheprojectcontinues,theteammaydeviatefromtheoriginalvision.Theteam canmanage the deviations, because the team delivers value sooner. Thedegree of change and variation is less important than ensuring customers getvaluesoonerthanattheendoftheproject.

Completenessanddeliveryaresubjective.Theteammayneedfeedbackonaprototypeandmaythenchoosetodeliveraminimumviableproduct(MVP)to a subset of customers. The customers’ feedback helps the team to learnwhattheyneedtoprovideforsubsequentdeliveryofthefinalfinishedfeature.

Agile teams, as a key differentiator, deliver business value often.As theproductaddsabroadersetoffeaturesandabroaderrangeofconsumers,wesayitisdeliveredincrementally.

Providing a customer a single feature or a finished piece of work is anexampleoftheincrementalapproach.

Forexample,buildersmaywanttoshowafinishedroomorfloorofabuildingbeforetheycontinuewiththeremainderofthebuilding.Inthatcase,theymaycomplete a floor with fixtures, paint, and everything else intended for thefinished floorbeforeproceeding to thenext floor.The customer is able to seeand approve of the style, color, and other details, allowing adjustments to bemade before further investments of time and money are made. This reducespotentialreworkand/orcustomerdissatisfaction.

3.1.4CHARACTERISTICSOFAGILELIFECYCLES

In an agile environment, the team expects requirements to change. Theiterative and incremental approaches provide feedback to better plan the nextpart of the project. However, in agile projects, incremental delivery uncovershiddenormisunderstoodrequirements.Figure3-5illustratestwopossiblewaysto achieve incremental delivery so the project alignswith customer needs andcanbeadaptedasnecessary.

In iteration-based agile, the team works in iterations (timeboxes of equalduration)todelivercompletedfeatures.Theteamworksonthemost importantfeature, collaborating as a team to finish it. Then the teamworks on the nextmost important featureandfinishes it.The teammaydecide toworkona fewfeaturesatatime,buttheteamdoesnotaddressalloftheworkfortheiterationat once (i.e., does not address all of the requirements, followed by all of theanalyses,etc.).

In flow-based agile, the team pulls features from the backlog based on itscapacity to start work rather than on an iteration-based schedule. The teamdefines its workflowwith columns on a task board andmanages thework inprogressforeachcolumn.Eachfeaturemaytakeadifferentamountof timetofinish. Teams keepwork-in-progress sizes small to better identify issues earlyand reduce rework should changes be required. Without iterations to defineplanning and review points, the team and business stakeholders determine themostappropriatescheduleforplanning,productreviews,andretrospectives.

AgilelifecyclesarethosethatfulfilltheprinciplesoftheAgileManifesto.Inparticular,customersatisfactionincreaseswithearlyandcontinuousdeliveryofvaluable products.Moreover, an incremental deliverable that is functional andprovides value is the primarymeasure of progress. Agile life cycles combineboth iterative and incremental approaches in order to adapt to highdegrees ofchangeanddeliverprojectvaluemoreoften.

3.1.5AGILESUITABILITYFILTERS

Variousassessmentmodels exist tohelpdetermine the likely fit orgaps forusingagileapproaches.Thesemodelsassessproject andorganizational factorsassociated with adoption and suitability and then provide scores indicatingalignmentorpotentialriskareas.AppendixX3providesasynthesisofpopularassessmentmodelsforuseasanagilesuitabilityfilter.

EXAMPLEOFAHYBRIDLIFECYCLEPROJECT

Apharmaceuticalcompanythathadatime-consumingU.S.FoodandDrugAdministration (FDA) approval process tagged onto the end of itsdevelopment process and its entire life cycle looked like Figure 3-6.Whileprojectteamsundertookdrugtrialsinanagilefashion,theyhadtopresentthedrugstoanexternalgrouptoperformtheFDAapprovalprocess.Aconsultanthelped to integrate the FDA approval process portion into the agiledevelopmentprocesstocreateamorestreamlinedhybridapproach.

TheshortversionofthestoryisthatbecauseFDAapprovalisrequiredtobe completed at the end of the development process or repeated after anychange (this includesevenafter themostminorchange), theprocesshad toremainat theendasaseparatephase.Integrationusingthe iterativeprocesswas unsuccessful. However, the consultant created some useful quick-start

guidesandtestingprotocolsthatshortenedthefinalFDAapprovalprocess.

3.1.6CHARACTERISTICSOFHYBRIDLIFECYCLES

Itisnotnecessarytouseasingleapproachforanentireproject.Projectsoftencombine elements of different life cycles in order to achieve certain goals. Acombination of predictive, iterative, incremental, and/or agile approaches is ahybridapproach.

Figure3-6depictsthebasic,pureapproachestoprojecttypesthatcombinetoformahybridmodel.Theearlyprocessesutilizeanagiledevelopmentlifecycle,whichisthenfollowedbyapredictiverolloutphase.Thisapproachcanbeusedwhenthereisuncertainty,complexity,andriskinthedevelopmentportionoftheproject that would benefit from an agile approach, followed by a defined,repeatable rollout phase that is appropriate to undertake in a predictive way,perhapsbyadifferentteam.Anexampleofthisapproachisthedevelopmentofanewhigh-techproductfollowedbyrolloutandtrainingtothousandsofusers.

3.1.7COMBINEDAGILEANDPREDICTIVEAPPROACHES

Anotherapproachistouseacombinationofagileandpredictiveapproachesthroughoutthelifecycle.

InFigure3-7,acombinationofbothpredictiveandagileapproachesareusedinthesameproject.Perhapstheteamisincrementallytransitioningtoagileandusing someapproaches like short iterations,daily standups, and retrospectives,

butotheraspectsoftheprojectsuchasupfrontestimation,workassignment,andprogresstrackingarestillfollowingpredictiveapproaches.

Usingbothpredictiveandagileapproachesisacommonscenario.Itwouldbemisleadingtocalltheapproachagilesinceitclearlydoesnotfullyembodytheagilemindset, values, and principles.However, itwould also be inaccurate tocallitpredictivesinceitisahybridapproach.

3.1.8PREDOMINANTLYPREDICTIVEAPPROACHWITHSOMEAGILECOMPONENTS

Figure3-8showsasmallagileelementwithinachieflypredictiveproject.Inthis case, a portion of the projectwith uncertainty, complexity, or opportunityforscopecreepisbeingtackledinanagileway,buttheremainderoftheprojectis being managed using predictive approaches. An example of this approachwouldbeanengineeringfirmthatisbuildingafacilitywithanewcomponent.

While themajorityof theprojectmaybe routineandpredictable, likemanyother facility projects the organization has undertaken before, this projectincorporates a new roofingmaterial.The contractormayplan for some small-scale installation trials on the ground first to determine the best installationmethodandtouncover issuesearlywhile there isplentyof timetosolvethemandincrementallyimproveprocessesthroughexperimentationandadaptation.

3.1.9ALARGELYAGILEAPPROACHWITHAPREDICTIVECOMPONENT

Figure3-9depictsalargelyagileapproachwithapredictivecomponent.Thisapproach might be used when a particular element is non-negotiable or notexecutable using an agile approach. Examples include integrating an externalcomponentdevelopedbyadifferentvendorthatcannotorwillnotpartner inacollaborative or incremental way. A single integration is required after thecomponentisdelivered.

Agovernmentdepartmenthadacredit insuranceapplicationdevelopmentproject.Themulti-yearprojectwas to replace itsagingunderwritingsystemwithanew,moreresponsiveuserinterfaceandsystemintegrations.Thebulkoftheprojectwasundertakenusinganagileapproachwithcontinualbusinessinput.

The premium rate calculationswere handed down from theOrganisationfor Economic Co-operation and Development (OECD) as a 200-pagespecification.Thestepswereveryclearlyexplainedwithlittleopportunityforconfusion(orinterimresultconfirmationbythebusiness)andwerecodedupby a separate teamworking itsway through the calculation steps. The twoteamscollaboratedontheinputvariablesrequiredforthecalculationandhowto consume and display the output values, but beyond that, the calculationteamworkedinalargelypredictivemanner.

When the calculation team's portion was complete, the outputs from thepremium rate calculationsweredisplayedon the screens and in the reports.Thenthebusinessusersprovidedfeedbackontheappearanceanduseoftheinformation. The two teams ran concurrently, but had little need forinteraction. Having them physically close to each other made it easier tocheckinondevelopmentprogress,butlargelytheywereseparatesubprojects.

3.1.10HYBRIDLIFECYCLESASFIT-FOR-PURPOSE

Project teams may design a hybrid life cycle based on project risks. Forexample,acampusconstructionprojectmayhavemultiplebuildingstoimproveandbuild.Anincrementalapproachwouldfocusresourcesoncompletingsomebuildings earlier than others, accelerating the return on investment. Eachindividualdeliverymaybesufficientlywellknowntobenefitfromapredictivelifecycleforthatbuildingalone.

The goal of project management is to produce business value in the bestpossibleway given the current environment. It does notmatter if that way is

agileorpredictive.Thequestiontoaskis:“Howcanwebemostsuccessful?”

Isfeedbackneededastheteamproducesvalue?Ifso,incrementswillhelp.Isitnecessarytomanageriskas ideasareexplored?Ifso, iterationsoragilewillhelp.

When the organization cannot deliver intermediate value, agile approachesmaynotbeuseful.Thatisokay—agileforthesakeofagileisnotthegoal.Thepoint is to select a life cycleor a combinationof life cycles thatwork for theproject,therisks,andtheculture.

Agile is about customer-based delivery on a frequent basis. That deliverycreatesfeedbackfortheteam.Theteamusesthatfeedbacktoplanandreplanthenextchunkofwork.

3.1.11HYBRIDLIFECYCLESASTRANSITIONSTRATEGY

Many teams are not able to make the switch to agile ways of workingovernight. Agile techniques look and feel very different to those who areaccustomedtoandhavebeensuccessfulinapredictiveenvironment.Thelargertheorganizationandthemoremovingparts,thelongeritwilltaketotransition.Forthatreason,itmakessensetoplanagradualtransition.

A gradual transition involves adding more iterative techniques to improvelearning and alignment among teams and stakeholders. Later, consider addingmore incremental techniques to accelerate value and return on investment tosponsors. This combination of various approaches is considered a hybridapproach.

Trythesenewtechniquesonalessriskyprojectwithamedium-tolow-degreeof uncertainty. Then, when the organization is successful with a hybridapproach,trymorecomplexprojectsthatrequiremoreofthosetechniquestobeadded. This is a way to tailor the progressive hybrid transition to theorganization'ssituationandspecificrisksandthe team'sreadiness toadaptandembracethechanges.

3.2MIXINGAGILEAPPROACHESAgile teams rarely limit their practices to one agile approach. Each project

contexthasitsownpeculiarities,suchasthevariedmixofteammemberskills

and backgrounds; the various components of the product under development;and the age, scale, criticality, complexity, and regulatory constraints of theenvironmentinwhichtheworktakesplace.

Agile frameworks are not customized for the team. The teammay need totailor practices to deliver value on a regular basis.Often, teams practice theirownspecialblendofagile,eveniftheyuseaparticularframeworkasastartingpoint.

BLENDINGAPPROACHES

As an example of tailoring agile frameworks, one of the most commonblendsinwidespreaduseinvolvesacoordinateduseoftheScrumframework,theKanbanMethod,andelementsoftheeXtremeProgramming(XP)method.Scrumprovidesguidanceon theuseofaproductbacklog,aproductowner,scrum master, and a cross-functional development team, including sprintplanning, daily scrum, sprint review, and sprint retrospective sessions. Akanban board helps the team to further improve its effectiveness byvisualizing the flow of work, making impediments easily visible, andallowingflowtobemanagedbyadjustingworkinprocesslimits.Inaddition,XP-inspired engineering practices such as use of story cards, continuousintegration, refactoring, automated testing, and test-driven developmentfurtherincreasetheeffectivenessoftheagileteam.Insummary,theblendofpractices from these various sources produces a synergistic result of higherperformancethaneachindividualcomponentinisolation.

3.3PROJECTFACTORSTHATINFLUENCETAILORINGSometimes project attributes require tailoring an approach for a better fit.

Table3-2identifiessomeprojectfactorsandtailoringoptionstoconsider.

Table3-2.TailoringOptionstoImproveFit

ProjectFactor TailoringOptions

Demandpattern:steadyorsporadic Manyteamsfindthatusingacadence(intheformofaregulartimebox)helpsthemdemo,retrospect,andtakeinnewwork.Inaddition,someteamsneedmoreflexibilityintheir

someteamsneedmoreflexibilityintheiracceptanceofmorework.Teamscanuseflow-basedagilewithacadencetogetthebestofbothworlds.

Rateofprocessimprovementrequiredbythelevelofteamexperience

Retrospectmoreoftenandselectimprovements.

Theflowofworkisofteninterruptedbyvariousdelaysorimpediments

Considermakingworkvisibleusingkanbanboardsandexperimentingwithlimitsforthevariousareasoftheworkprocessinordertoimproveflow.

Thequalityoftheproductincrementsispoor Considerusingthevarioustest-drivendevelopmentpractices.Thismistake-proofingdisciplinemakesitdifficultfordefectstoremainundetected.

Morethanoneteamisneededtobuildaproduct Toscalefromonetoseveralagileteams,withminimaldisruption,firstlearnaboutagileprogrammanagementorformalscalingframeworks.Then,craftanapproachthatfitstheprojectcontext.

Theprojectteammembersareinexperiencedintheuseofagileapproaches

Considerstartingbytrainingteammembersinthefundamentalsoftheagilemindsetandprinciples.IftheteamdecidestouseaspecificapproachsuchasScrumorKanban,provideaworkshoponthatapproachsotheteammemberscanlearnhowtouseit.

For additional guidanceon factors that influence tailoring seeAppendixX2onAttributesthatInfluenceTailoring.

4

IMPLEMENTINGAGILE:CREATINGANAGILEENVIRONMENT

4.1STARTWITHANAGILEMINDSET

Managing a project using an agile approach requires that the project teamadopt an agile mindset. The answers to the following questions will help todevelopanimplementationstrategy:

Howcantheprojectteamactinanagilemanner?

What can the team deliver quickly and obtain early feedback tobenefitthenextdeliverycycle?

Howcantheteamactinatransparentmanner?

Whatworkcanbeavoidedinordertofocusonhigh-priorityitems?

Howcanaservant-leadershipapproachbenefittheachievementoftheteam'sgoals?

4.2 SERVANT LEADERSHIP EMPOWERS THETEAM

Agileapproachesemphasizeservant leadershipasaway toempower teams.Servant leadership is the practice of leading through service to the team, byfocusing on understanding and addressing the needs anddevelopment of teammembersinordertoenablethehighestpossibleteamperformance.

Theroleofaservantleaderistofacilitatetheteam'sdiscoveryanddefinitionof agile. Servant leaders practice and radiate agile. Servant leaders approach

projectworkinthisorder:

Purpose.Workwiththeteamtodefinethe“why”orpurposesotheycan engage and coalesce around the goal for the project. The entireteamoptimizesattheprojectlevel,notthepersonlevel.

People.Oncethepurposeisestablished,encouragetheteamtocreateanenvironmentwhereeveryonecansucceed.Askeachteammembertocontributeacrosstheprojectwork.

Process. Do not plan on following the “perfect” agile process, butinstead look for the results. When a cross-functional team deliversfinishedvalueoftenandreflectsontheproductandprocess,theteamsareagile.Itdoesnotmatterwhattheteamcallsitsprocess.

The following characteristics of servant leadership enable project leaders tobecomemoreagileandfacilitatetheteam'ssuccess:

Promotingself-awareness;

Listening;

Servingthoseontheteam;

Helpingpeoplegrow;

Coachingvs.controlling;

Promotingsafety,respect,andtrust;and

Promotingtheenergyandintelligenceofothers.

Servantleadershipisnotuniquetoagile.Butoncehavingpracticedit,servantleaders can usually see how well servant leadership integrates into the agilemindsetandvalue.

When leaders develop their servant leadership or facilitative skills, they aremore likely to become agile.As a result, servant leaders can help their teamscollaboratetodelivervaluefaster.

Successful agile teams embrace the growth mindset, where people believethey can learnnew skills.When the teamand the servant leadersbelieve theycanalllearn,everyonebecomesmorecapable.

4.2.1SERVANTLEADERRESPONSIBILITIES

Servant leaders manage relationships to build communication andcoordination within the team and across the organization. These relationshipshelp the leaders navigate the organization to support the team. This kind ofsupport helps to remove impediments and facilitates the team to streamline itsprocesses. Because servant leaders understand agile and practice a specificapproachtoagile,theycanassistinfulfillingtheteam'sneeds.

4.2.1.1SERVANTLEADERSFACILITATE

When project managers act as servant leaders, the emphasis shifts from“managing coordination” to “facilitating collaboration.” Facilitators helpeveryone do their best thinking and work. Facilitators encourage the team'sparticipation, understanding, and shared responsibility for the team's output.Facilitatorshelptheteamcreateacceptablesolutions.

Servant leaderspromotecollaborationandconversationwithin the teamandbetweenteams.Forexample,aservantleaderhelpstoexposeandcommunicatebottlenecksinsideandbetweenteams.Thentheteamsresolvethosebottlenecks.

Additionally, a facilitator encourages collaboration through interactivemeetings, informal dialog, and knowledge sharing. Servant leaders do this bybecoming impartial bridge-builders and coaches, rather than by makingdecisionsforwhichothersshouldberesponsible.

4.2.1.2SERVANTLEADERSREMOVEORGANIZATIONALIMPEDIMENTS

The first value of the Agile Manifesto is individuals and interactions overprocesses and tools.What better responsibility for a servant leader to take onthantotakeahardlookatprocessesthatareimpedingateam'sororganization'sagility and work to streamline them? For example, if a department requiresextensive documentation, the role of the servant leader could be toworkwiththatdepartmenttoreviewrequireddocumentation,assistwithcreatingasharedunderstandingofhowagiledeliverablesmeet those requirements,andevaluatethe amount of documentation required so teams are spending more timedeliveringavaluableproductinsteadofproducingexhaustivedocumentation.

Servant leaders shouldalso lookatotherprocesses thatare lengthy,causingbottlenecks and impeding a team's or organization's agility. Examples ofprocessesordepartmentsthatmayneedtobeaddressedincludefinance,change

control boards, or audits. Servant leaders can partner andworkwith others tochallengethemtoreviewtheirprocessestosupportagileteamsandleaders.Forexample,whatgoodisitfortheteamtodeliverworkingproductevery2weeksonlytohavetheproductfall intoaqueueorprocess thatcouldtake6ormoreweeks to releasedue to lengthy releaseprocesses?Far toomanyorganizationshave these “bottleneck” processes that prevent teams from quickly deliveringvaluable products or services. The servant leader has the ability to change orremovetheseorganizationalimpedimentstosupportdeliveryteams.

INTERPERSONALSKILLSVERSUSTECHNICALSKILLS

In addition to servant leadership, team members emphasize theirinterpersonal and emotional intelligence skills—not just technical skills.Everyone on the teamworks to exhibitmore initiative, integrity, emotionalintelligence,honesty,collaboration,humility,andwillingnesstocommunicateinvariouswayssothattheentireteamcanworktogetherwell.

Theteamneedstheseskillssotheycanrespondwelltochangesinprojectdirection and technical product changes. When everyone can adapt to theworkandtoeachother,theentireteamismorelikelytosucceed.

4.2.1.3SERVANTLEADERSPAVETHEWAYFOROTHERS’CONTRIBUTION

Inagile, the teammanages itsworkprocessanditsworkproduct.Thatself-management and self-organization applies to everyone serving and supportingthe organization and project. Servant leaders work to fulfill the needs of theteams,projects,andorganization.Servantleadersmayworkwithfacilitiesforateamspace,workwithmanagementtoenabletheteamtofocusononeprojectatatime,orworkwiththeproductownertodevelopstorieswiththeteam.Someservant leadersworkwithauditors to refine theprocessesneeded in regulatoryenvironments, and some servant leaders work with the finance department totransitiontheorganizationtoincrementalbudgeting.

Theservantleaderfocusesonpavingthewayfortheteamtodoitsbestwork.Theservantleaderinfluencesprojectsandencouragestheorganizationtothinkdifferently.

4.2.1.4CONSIDERTHESESERVANTLEADERRESPONSIBILITIES

RESPONSIBILITIES

Servant leaderscanhavemanypossible titles,butwhat ismost important iswhat they do.Here are some examples of the responsibilities a servant leadermayhave:

Educate stakeholders around why and how to be agile. Explain thebenefits of business value based on prioritization, greateraccountability and productivity of empowered teams, and improvedqualityfrommorefrequentreviews,etc.

Support the team through mentoring, encouragement, and support.Advocate for team members training and career development. Theoxymoronicquote“We lead teamsbystandingbehind them”speaksto the roleof the leader indeveloping their teammembers.Throughsupport, encouragement, and professional development, teammembers gain confidence, take on larger roles, and contribute athigher levels within their organizations. A key role of the servantleaderistonurtureandgrowteammembersthroughandbeyondtheircurrentroles,evenifthatmeanslosingthemfromtheteam.

Help the team with technical project management activities likequantitative risk analysis. Sometimes team members may not haveknowledge or experience in roles or functions. Servant leaderswhomay have more exposure or training in techniques can support theteambyprovidingtrainingorundertakingtheseactivities.

Celebrate team successes and support and bridge building activitieswithexternalgroups.Createupwardspiralsofappreciationandgoodwillforincreasedcollaboration.

4.2.2ROLEOFTHEPROJECTMANAGERINANAGILEENVIRONMENTThe role of the project manager in an agile project is somewhat of an

unknown, becausemany agile frameworks and approaches do not address theroleoftheprojectmanager.Someagilepractitionersthinktheroleofaprojectmanager is not needed, due to self-organizing teams taking on the formerresponsibilities of the projectmanager.However, pragmatic agile practitionersand organizations realize that project managers can add significant value in

manysituations.Thekeydifference is that their rolesand responsibilities looksomewhatdifferent.

TIP

Thevalueofprojectmanagersisnotintheirposition,butintheirabilitytomakeeveryoneelsebetter.

4.2.3PROJECTMANAGERSUSESERVANTLEADERSHIP

ThePMBOK®Guide – Sixth Edition, defines the project manager as “theperson assigned by the performing organization to lead the team that isresponsibleforachievingtheprojectobjectives.”

Manyprojectmanagersareaccustomedtobeingatthecenterofcoordinationfor the project, tracking and representing the team's status to the rest of theorganization. This approach was fine when projects were decomposed intosiloedfunctions.

However, inhigh-changeprojects, there ismorecomplexitythanonepersoncan manage. Instead, cross-functional teams coordinate their own work andcollaboratewiththebusinessrepresentative(theproductowner).

When working on an agile project, project managers shift from being thecentertoservingtheteamandthemanagement.Inanagileenvironment,projectmanagersareservant leaders,changing theiremphasis tocoachingpeoplewhowanthelp,fosteringgreatercollaborationontheteam,andaligningstakeholderneeds. As a servant leader, project managers encourage the distribution ofresponsibilitytotheteam:tothosepeoplewhohavetheknowledgetogetworkdone.

4.3TEAMCOMPOSITION

AcoretenetinboththevaluesandtheprinciplesoftheAgileManifestoistheimportance of individuals and interactions.Agile optimizes the flow of value,emphasizing rapid featuredelivery to thecustomer, rather thanonhowpeopleare“utilized.”

TIP

TIP

Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentandsupporttheyneedandtrustthemtogetthejobdone.

When teams think about how to optimize the flow of value, the followingbenefitsbecomeapparent:

Peoplearemorelikelytocollaborate.

Teamsfinishvaluableworkfaster.

Teamswastemuchlesstimebecausetheydonotmultitaskandhavetore-establishcontext.

4.3.1AGILETEAMSAgileteamsfocusonrapidproductdevelopmentsotheycanobtainfeedback.

Inpractice,themosteffectiveagileteamstendtorangeinsizefromthreetoninemembers.Ideally,agileteamsarecolocatedinateamspace.Teammembersare100% dedicated to the teams. Agile encourages self-managing teams, whereteam members decide who will perform the work within the next period'sdefined scope.Agile teams thrivewith servant leadership.The leaders supporttheteams’approachtotheirwork.

Cross-functional agile teams produce functional product incrementsfrequently. That is because the teams collectively own the work and togetherhaveallofthenecessaryskillstodelivercompletedwork.

Regardlessof theoverall agileapproach, themorea team limits itswork inprogress, themore likely itsmembers can collaborate to expeditework acrossthe board. Team members in successful agile teams work to collaborate invariousways(suchaspairing,swarming,andmobbing)sotheydonotfallintothe trapofmini-waterfalls insteadofcollaborativework.Mini-waterfallsoccurwhentheteamaddressesalloftherequirementsinagivenperiod,thenattemptsto do all of the design, then moves on to do all of the building. Using thisscenario,atsomepointinthebuildingorthetestingfollowingthebuilding,theteammay realize it had assumptions that are no longer valid. In this case, theteam wasted time in addressing all of the requirements. Instead, when teammembers collaborate to produce a small number of features across the board,

theylearnastheyproceedanddeliversmallerfinishedfeatures.

Agileprojectsbenefitfromprojectteamstructuresthatimprovecollaborationwithinandamongtheteams.Table4-1showshowcollaborativeteammembersboostproductivityandfacilitateinnovativeproblemsolving.

Table4-1.AttributesofSuccessfulAgileTeams

Attribute Goal

Dedicatedpeople IncreasedfocusandproductivitySmallteam,fewerthantenpeople

Cross-functionalteammembers

DevelopanddeliveroftenDeliverfinishedvalueasanindependentteamIntegratealltheworkactivitiestodeliverfinishedworkProvidefeedbackfrominsidetheteamandfromothers,suchastheproductowner

Colocationorabilitytomanageanylocationchallenges

BettercommunicationImprovedteamdynamicsKnowledgesharingReducedcostoflearningAbletocommittoworkingwitheachother

Mixedteamofgeneralistsandspecialists

SpecialistsprovidededicatedexpertiseandgeneralistsprovideflexibilityofwhodoeswhatTeambringstheirspecialistcapabilitiesandoftenbecomegeneralizingspecialists,withafocusspecialtyplusbreadthofexperienceacrossmultipleskills

Stableworkenvironment DependoneachothertodeliverAgreed-uponapproachtotheworkSimplifiedteamcostcalculations(runrate)Preservationandexpansionofintellectualcapital

4.3.2AGILEROLESInagile,threecommonrolesareused:

Cross-functionalteammembers,

Productowner,and

Teamfacilitator.

Table4-2describestheseteamroles.

Table4-2.AgileTeamRoles

Role Description

Cross-functionalteammember

Cross-functionalteamsconsistofteammemberswithalltheskillsnecessarytoproduceaworkingproduct.Insoftwaredevelopment,cross-functionalteamsaretypicallycomprisedofdesigners,developers,testers,andanyotherrequiredroles.Thecross-functionaldevelopmentteamsconsistofprofessionalswhodeliverpotentiallyreleasableproductonaregularcadence.Cross-functionalteamsarecriticalbecausetheycandeliverfinishedworkintheshortestpossibletime,withhigherquality,withoutexternaldependencies.

Productowner Theproductownerisresponsibleforguidingthedirectionoftheproduct.Productownersranktheworkbasedonitsbusinessvalue.Productownersworkwiththeirteamsdailybyprovidingproductfeedbackandsettingdirectiononthenextpieceoffunctionalitytobedeveloped/delivered.Thatmeanstheworkissmall,oftensmallenoughtobedescribedononeindexcard.

Theproductownerworkswithstakeholders,customers,andtheteamstodefinetheproductdirection.Typically,productownershaveabusinessbackgroundandbringdeepsubjectmatterexpertisetothedecisions.Sometimes,theproductownerrequestshelpfrompeoplewithdeepdomainexpertise,suchasarchitects,ordeepcustomerexpertise,suchasproductmanagers.Productownersneedtrainingonhowtoorganizeandmanagetheflowofworkthroughtheteam.

Inagile,theproductownerscreatethebacklogforandwiththeteam.Thebackloghelpstheteamsseehowtodeliverthehighestvaluewithoutcreatingwaste.

Acriticalsuccessfactorforagileteamsisstrongproductownership.Withoutattentiontothehighestvalueforthecustomer,theagileteammaycreatefeaturesthatarenotappreciated,orotherwiseinsufficientlyvaluable,thereforewastingeffort.

Teamfacilitator Thethirdroletypicallyseenonagileteamsisofateamfacilitator,aservantleader.Thisrolemaybecalledaprojectmanager,scrummaster,projectteamlead,teamcoach,orteamfacilitator.

Allagileteamsneedservantleadershipontheteam.Peopleneedtimetobuildtheirservantleadershipskillsoffacilitation,coaching,andimpedimentremoval.

Initially,manyorganizationsinviteexternalagilecoachestohelpthemwhentheirinternalcoachingcapabilityisnotyetfullydeveloped.

Externalcoacheshavetheadvantageofexperience,butthedisadvantageofweakrelationshipsintheclientorganization.Internalcoaches,ontheotherhand,havestrongrelationshipsintheirorganization,butmaylackthebreadthofexperiencethatwouldmake

organization,butmaylackthebreadthofexperiencethatwouldmakethemhighlyeffective.

“I-SHAPEDPEOPLEANDT-SHAPEDPEOPLE”

Some people have deep specializations in one domain, but rarelycontribute outside of that domain. These people are known in agilecommunities as “I-shaped people” since, like the letter “I,” they havedepth,butnotmuchbreadth.Bycontrast“T-shapedpeople”supplementtheir expertise inoneareawith supporting,but less-developed skills inassociatedareasandgoodcollaborationskills.Asanexample,apersonwhocantestsomeareasoftheproductanddevelopdifferentareasoftheproductisconsideredtobeaT-shapedperson.

A T-shaped person has a defined, recognized specialization andprimaryrole,buthastheskills,versatility,andaptitudeforcollaborationto help other people when and where necessary. This collaborationreduceshand-offsandtheconstraintsofonlyonepersonbeingabletodothejob.

4.3.3GENERALIZINGSPECIALISTS

Agile teams are cross-functional, but the people often do not start off thatway. However, many successful agile teams are made up of generalizingspecialists,or“T-shaped”people.

This means team members have both a focus specialty plus a breadth ofexperienceacrossmultipleskills,ratherthanasinglespecialization.Agileteammemberswork todevelopsuchcharacteristicsdue to intensecollaborationandself-organization to swarmandgetworkdonequickly,which requires them toroutinelyhelpeachother.

A single person's throughput is not relevant. Focusing on a single person'sthroughputmayevenbeharmfulifitcreatesabottleneckfortherestoftheteam.The goal is for the team to optimize the delivery of finished work to getfeedback.

If the customer desires great results, such as rapid feature delivery withexcellent quality, the teamcannot be structured justwith specialist roles in an

attempttomaximizeresourceefficiency.Theteam'sobjectiveisflowefficiency,optimizingthethroughputoftheentireteam.Smallbatchsizespromoteworkingtogetherasateam.Theproductowner'sjobistomakesuretheteamworksonthehighest-valuework.

4.3.4TEAMSTRUCTURES

Teams have adopted agile principles and practices across many industries.Theyorganizepeopleintocross-functionalteamstoiterativelydevelopworkingproducts.

CASE

The core team assembled to write this practice guide had variedbackgrounds—somerepresentedPMIandsomerepresentedAgileAlliance.Theywereself-organizingandworkedinincrementstocompletethework.PMIassembledagroupofsubjectmatterexpertstoinspectthework,andthisallowedtheteamtoincorporatefeedbackandimprovetheproductasitwasdeveloped.Howeverthecoreteamwasnotrepresentativeofatypicalagile team because its members’ time was not 100% dedicated to thisendeavor.

Some organizations have been able to create colocated, cross-functionalteams; others have a different situation. Instead of having all team memberscolocated, some organizations have distributed or dispersed teams.Distributedteamshave cross-functional teams in different locations.Dispersed teamsmayhaveeachteammemberworkinginacompletelydifferentlocation,eitherinanoffice or fromhome.While these arrangements are not ideal due to increasedcommunicationcosts,theymaystillbeworkable.

Inonelarge,U.S.-basedfinancialinstitutiontherewasaprogramwithasetof teamswhere the teammemberswerebasedon theEastCoastoftheUnitedStatesandseverallocationsthroughoutIndia.Whentheteamfirst started, itwasone largedispersed team(UX,analysts,developers,

andtesters)doinga“followthesun”2developmentpracticewheresomeworkingtimeoverlappedacrosstheteammemberstodowarmhand-offswith the work. Teammembers conducted daily standups together andusedwebcamstoincludeallteammembers.Keyroles(analysts,productowners,UXdesigners,anddevelopmentleads)intheU.S.wouldcomein early to answer anyquestions from their India-based teammembersandhelptoresolveimpediments.

Astheproductstartedgettinglarger,andmorefundingcamethrough,theydecidedtobreakintofivesmallerteams.Todothis,theydecidedtobuild colocated, distributed teams in various locations. Theymade thedecision to build cross-functional, colocated teams in each of theselocationsconsistingofdevelopersandtesters.

Theyalsohadacoresetofanalysts,basedinthetwoU.S.locations,whoworkedwiththeirU.S.-basedproductmanagerandproductownersandthenworkedwitheachoftheteams,respectively.Althoughtheyhadsome structure in place where they conducted product reviews as anentire program, most of the other activities were conducted at a teamlevel,basedonwhatworkedbest foreach team, toallow them toself-organize.

4.3.5DEDICATEDTEAMMEMBERSWhat happenswhen the teammembers’ time is not 100% dedicated to the

team?While this condition is not ideal, unfortunately, it sometimes cannot beavoided.

Thekeyproblemwithhavingsomeoneinvestonlyacapacityof25%or50%ontheteamisthattheywillmultitaskandtaskswitch.Multitaskingreducesthethroughputoftheteam'sworkandimpactstheteam'sabilitytopredictdeliveryconsistently.

TIP

Multitasking slows the progress of the entire team, because teammembers waste time context switching and/or waiting for each other tofinishotherwork.Whenpeopleare100%dedicatedtotheteam,theteam

hasthefastestpossiblethroughput.

People experience productivity losses somewhere between 20% and 40%whentaskswitching.Thelossincreasesexponentiallywiththenumberoftasks.

When a personmultitasks between two projects, that person is not 50% oneachproject.Instead,duetothecostoftaskswitching,thepersonissomewherebetween20%and40%oneachproject.

Peoplearemorelikelytomakemistakeswhentheymultitask.Task-switchingconsumesworkingmemoryandpeoplearelesslikelytoremembertheircontextwhentheymultitask.

When everyone on the team is 100% allocated to one project, they cancontinuouslycollaborateasateam,makingeveryone'sworkmoreeffective.

CASE

Sincecoreteammembersdevelopingthispracticeguidecannotdedicate100% of their capacity to the team's efforts, their throughput issubstantially lower thanwhat itmightbe if theycouldafford tocollocateand invest their attention full-time to the project. However, while it iseconomically viable to collaborate, even if dispersed and operating at afractionoftheirfullcapacity,itisnotfeasibletocolocateandfocusatfullcapacity.Therefore,theteamidentifiedtheirdispersionasapotentialrisk.Theteamtracksandmonitorstheprogressoftheirworkthroughtheuseofcollaborative tools and adjusts assignments based on individual capacityaccordingly.

SeeTableA1-2onProjectManagementProcessGroupandKnowledgeAreaMappingformoretipsonteamsinagileenvironments,specificallytheprocessesintheProjectResourceManagementKnowledgeArea.

TIP

Notallteamshavealltherolesthattheyneed.Forexample,someteams

need support from database administrators or research analysts.When ateam has temporarily assigned specialists, it is important to ensure thateveryonehasthesamesetofexpectations.Isthisspecialist100%allocatedtotheteamandforhowlong?Setexpectationswitheveryone(thespecialistand the team) to clarify the level of commitment so the teamcandeliver.Part-timeassignmentscreaterisksfortheproject.

4.3.6TEAMWORKSPACES

Teamsneedaspaceinwhichtheycanworktogether,tounderstandtheirstateasateam,andtocollaborate.Someagileteamsallworkinoneroomtogether.Someteamshaveateamworkspacefortheirstandupsandcharts,andworkontheirownincubiclesoroffices.

Whilecompaniesaremovingtowardopen,collaborativeworkenvironments,organizations also need to create quiet spaces for workers who needuninterruptedtimetothinkandwork.Therefore,companiesaredesigningtheiroffices to balance common and social areas (sometimes called “caves andcommon”)withquietareasorprivatespaceswhereindividualscanworkwithoutbeinginterrupted.

Whenteamshavegeographicallydistributedmembers,theteamdecideshowmuchoftheirworkplaceisvirtualandhowmuchisphysical.Technologysuchas document sharing, video conferencing, and other virtual collaboration toolshelppeoplecollaborateremotely.

Geographically distributed teams need virtual workspaces. In addition,considergettingtheteamtogetherinpersonatregularintervalssotheteamcanbuildtrustandlearnhowtoworktogether.

Sometechniquestoconsiderformanagingcommunicationindispersedteamsarefishbowlwindowsandremotepairing:

Createafishbowlwindowbysettinguplong-livedvideoconferencinglinks between the various locations in which the team is dispersed.Peoplestartthelinkatthebeginningofaworkday,andcloseitattheend.Inthisway,peoplecanseeandengagespontaneouslywitheachother, reducing the collaboration lag otherwise inherent in thegeographicalseparation.

Set up remote pairing by using virtual conferencing tools to share

screens, including voice and video links. As long as the time zonedifferences are accounted for, thismay prove almost as effective asface-to-facepairing.

TIP

Form teams by bringing people with different skills from differentfunctionstogether.Educatemanagersandleadersabouttheagilemindsetandengagethemearlyintheagiletransformation.

4.3.7OVERCOMINGORGANIZATIONALSILOS

Thebestplacetostartwhenformingagileteamsisbybuildingafoundationaltrustandasafeworkenvironmenttoensurethatallteammembershaveanequalvoice and can be heard and considered. This, along with building the agilemindset is theunderlyingsuccess factor—allotherchallengesandriskscanbemitigated.

Often, siloed organizations create impediments for forming cross-functionalagile teams. The team members needed to build the cross-functional teamstypically report to different managers and have different metrics by whichmanagersmeasuretheirperformance.Managersneedtofocusonflowefficiency(andteam-basedmetrics)ratherthanresourceefficiency.

To overcome organizational silos,workwith the variousmanagers of theseteammembers and have them dedicate the necessary individuals to the cross-functional team. This not only creates team synergy but also allows theorganization to see how leveraging its people will optimize the project orproductbeingbuilt.

For more information about teams see Appendix X2 on Attributes thatInfluenceTailoring.

TIP

Asanagileprojectleader,firstfocusonhowyoucancreateateamthatiscross-functionaland100%dedicatedtooneteam.Evenif itmeansjustgettingkeyteammembers,suchasthedevelopersandtesters,toworkand

communicatetogetheronadailybasis,thatisastepintherightdirectiontowardagility.

2Afollow-the-sundevelopmentprocessisonewhereworkishandedoffattheendofeverydayfromonesitetothenext,manytimezonesawayinordertospeedupproductdevelopment.

5

IMPLEMENTINGAGILE:DELIVERINGINANAGILEENVIRONMENT

5.1CHARTERTHEPROJECTANDTHETEAM

Every project needs a project charter so the project team knows why thisproject matters, where the team is headed and what the project objective is.However,theprojectcharteritselfmaynotbeenoughfortheteam.Agileteamsrequireteamnormsandanunderstandingofhowtoworktogether.Inthatcase,theteammightneedateamcharter.

The chartering process helps the team learn how to work together andcoalescearoundtheproject.

At a minimum, for an agile project, the team needs the project vision orpurposeandaclearsetofworkingagreements.Anagileprojectcharteranswersthesequestions:

Whyarewedoingthisproject?Thisistheprojectvision.

Whobenefitsandhow?Thismaybepartoftheprojectvisionand/orprojectpurpose.

Whatdoesdonemeanfortheproject?Thesearetheproject'sreleasecriteria.

Howarewegoingtoworktogether?Thisexplainstheintendedflowofwork.

Aservantleadermayfacilitatethecharteringprocess.Ateamcancoalescebyworking together, and the project charter is a great way to start working. Inaddition, teammembersmaywant to collaborate to understand how theywillworktogether.

Teams do not need a formal process for chartering as long as the teamsunderstand how towork together. Some teams benefit from a team charteringprocess.Herearesomecharteringideasforteammemberstouseasabasisfortheirsocialcontract:

Teamvalues,suchassustainablepaceandcorehours;

Working agreements, such as what “ready” means so the team cantakeinwork;what“done”meanssotheteamcanjudgecompletenessconsistently; respecting the timebox; or the use of work-in-processlimits;

Groundrules,suchasonepersontalkinginameeting;and

Groupnorms,suchashowtheteamtreatsmeetingtimes.

The servant leader together with the team may decide to address otherbehaviors.

Rememberthattheteam'ssocialcontract—itsteamcharter—ishowtheteammembers interactwitheachother.Thegoalof the teamcharter is tocreate anagileenvironmentinwhichteammemberscanworktothebestoftheirabilityasateam.

5.2COMMONAGILEPRACTICES

Sections5.2.1through5.2.8describeafewofthemostcommonagileprojectpractices.

5.2.1RETROSPECTIVESThesinglemost importantpractice is the retrospectivebecause it allows the

teamtolearnabout,improve,andadaptitsprocess.

Retrospectiveshelptheteamlearnfromitspreviousworkontheproductandits process. One of the principles behind the Agile Manifesto is: “At regularintervals, the team reflects on how to becomemore effective, then tunes andadjustsitsbehavioraccordingly.”

Many teams use iterations—especially 2-week iterations—because theiterationpromptsademonstrationanda retrospectiveat theend.However, theteamdoesnotneediterationsinordertoretrospect.Teammembersmaydecide

toretrospectatthesekeytimes:

When the team completes a release or ships something. It does nothavetobeamonumental increment.Itcanbeanyrelease,nomatterhowsmall.

When more than a few weeks have passed since the previousretrospective.

Whentheteamappearstobestuckandcompletedworkisnotflowingthroughtheteam.

Whentheteamreachesanyothermilestone.

Teams benefit from allocating enough time to learn, either from an interimretrospectiveor an end-of-the-project retrospective.Teamsneed to learn abouttheir work product and work process. For example, some teams have troublefinishing work. When teams plan enough time, they can structure theirretrospectivetogatherdata,processthatdata,anddecidewhattotrylaterasanexperiment.

First and foremost, a retrospective isnot aboutblame; the retrospective is atimefortheteamtolearnfrompreviousworkandmakesmallimprovements.

The retrospective is about looking at the qualitative (people's feelings) andquantitative (measurements) data, then using that data to find root causes,designingcountermeasures,anddevelopingactionplans.Theprojectteammayendupwithmanyactionitemstoremoveimpediments.

Considerlimitingthenumberofactionitemstotheteam'scapacitytoaddressimprovement in theupcoming iterationorworkperiod.Trying to improve toomanythingsatonceandnotfinishinganyofthemismuchworsethanplanningto complete fewer items and successfully completing all of them.Then,whentimeallows,theteamcanworkonthenextimprovementopportunityonthelist.Whentheteamselectstheimprovements,decidehowtomeasuretheoutcomes.Then, in the next time period, measure the outcomes to validate success orfailureofeachimprovement.

A facilitator from the team leads them through an activity to rank theimportanceofeachimprovementitem.Oncetheimprovementitemsarerankedby the team, the teamchooses theappropriatenumber toworkon for thenextiteration(oraddsworktotheflowifflow-based).

5.2.2BACKLOGPREPARATIONThebacklogistheorderedlistofallthework,presentedinstoryform,fora

team.Thereisnoneedtocreateallofthestoriesfortheentireprojectbeforethework starts—only enough tounderstand the first release inbroadbrushstrokesandthensufficientitemsforthenextiteration.

Product owners (or a product owner value team that includes the productmanager and all relevant product owners for that area of the product,) mightproduce a product roadmap to show the anticipated sequence of deliverablesover time. The product owner replans the roadmap based on what the teamproduces. (SeeAppendixX3onAgileSuitabilityFilterTools for examplesofroadmaps.)

5.2.3BACKLOGREFINEMENTIn iteration-based agile, the product owner often works with the team to

preparesomestoriesfor theupcomingiterationduringoneormoresessionsinthemiddle of the iteration.The purpose of thesemeetings is to refine enoughstoriessotheteamunderstandswhatthestoriesareandhowlargethestoriesareinrelationtoeachother.

There is no consensus on how long the refinement should be. There is acontinuumof:

Just-in-timerefinementforflow-basedagile.Theteamtakesthenextcardofftheto-docolumnanddiscussesit.

Many iteration-basedagile teamsusea timeboxed1-hourdiscussionmidway through a 2-week iteration. (The team selects an iterationdurationthatprovidesthemfrequent-enoughfeedback.)

Multiple refinement discussions for iteration-based agile teams.Teams can use this when they are new to the product, the productarea,ortheproblemdomain.

TIP

Consider using impact mapping to see how the product fits together.Undernormalcircumstances,theproductownerleadsthiswork.Aservant

leader can facilitate any necessary meetings as a way of serving theproject.

Refinementmeetings allow the product owner to present story ideas to theteamandfortheteamtolearnaboutthepotentialchallengesorproblemsinthestories. If theproductowner isunsureof thedependencies, theproductownercanrequesttheteamtospikethefeatureinordertounderstandtherisks.

There aremanyways for theproductowner to conductbacklogpreparationandrefinementmeetings,includingforexample:

Encourage the team to work as triads of developer, tester, businessanalyst/productownertodiscussandwritethestory.

Presenttheoverallstoryconcepttotheteam.Theteamdiscussesandrefinesitintoasmanystoriesasrequired.

Work with the team to find various ways to explore and write thestoriestogether,makingsureallofthestoriesaresmallenoughsotheteam can produce a steady flow of completed work. Considerbecomingabletocompleteastoryatleastonceaday.

Teamsoftenhaveagoalofspendingnotmorethan1hourperweekrefiningstoriesforthenextbatchofwork.Teamswanttomaximizethetimespentdoingworkasopposedtoplanningwork.Iftheteamneedstospendmorethan1hourperweekrefiningstories,theproductownercouldbeoverpreparing,ortheteammaybelackingsomecriticalskillsneededtoevaluateandrefinethework.

5.2.4DAILYSTANDUPSTeams use standups to microcommit to each other, uncover problems, and

ensuretheworkflowssmoothlythroughtheteam.

Timebox the standup to no longer than 15 minutes. The team “walks” theKanbanortaskboardinsomeway,andanyonefromtheteamcanfacilitatethestandup.

Initeration-basedagile,everyoneanswersthefollowingquestionsinaround-robinfashion:

WhatdidIcompletesincethelaststandup?

WhatamIplanningtocompletebetweennowandthenextstandup?

Whataremyimpediments(orrisksorproblems)?

Questionslikethesegenerateanswersthatallowtheteamtoself-organizeandholdeachotheraccountableforcompletingtheworktheycommittedtothedaybeforeandthroughouttheiteration.

Flow-basedagilehasadifferentapproachtostandups,focusingontheteam'sthroughput.Theteamassessestheboardfromrighttoleft.Thequestionsare:

Whatdoweneedtodotoadvancethispieceofwork?

Isanyoneworkingonanythingthatisnotontheboard?

Whatdoweneedtofinishasateam?

Arethereanybottlenecksorblockerstotheflowofwork?

One of the antipatterns typically seen in standups is they become statusmeetings. Teams who have traditionally worked in a predictive environmentmaytendtofallintothisantipatternsincetheyareusedtoprovidingastatus.

Anotherantipatterntypicallyseeninstandupsisthattheteambeginstosolveproblemsastheybecomeapparent.Standupsareforrealizingthereareproblems—notforsolvingthem.Addtheissuestoaparkinglot,andthencreateanothermeeting,whichmightberightafterthestandup,andsolveproblemsthere.

Teamsrun theirownstandups.Whenrunwell, standupscanbeveryuseful,provided the nature of the team'swork requires intense collaboration.Make aconsciousdecisionaboutwhentheteamneeds,orcaneffectivelyuse,standups.

TIP

Encourageanyteammembertofacilitatethestandupinsteadofaprojectmanager or leader to ensure it does not turn into a status meeting, butinstead is used as a time for the team to self-organize and makecommitmentstoeachother.

5.2.5DEMONSTRATIONS/REVIEWS

As the team completes the features usually in the form of user stories, theteamperiodicallydemonstratestheworkingproduct.Theproductownerseesthedemonstrationandacceptsordeclinesstories.

Initeration-basedagile,theteamdemonstratesallcompletedworkitemsattheendoftheiteration.Inflow-basedagile,theteamdemonstratescompletedworkwhenitistimetodoso,usuallywhenenoughfeatureshaveaccumulatedintoaset that is coherent. Teams, including the product owner, need feedback todecidehowearlytoaskforproductfeedback.

As a general guideline, demonstrate whatever the team has as a workingproductatleastonceevery2weeks.Thatfrequencyisenoughformostteams,soteammembers can get feedback that prevents them from heading in a wrongdirection.That is also frequent enough so that the teamscankeep theproductdevelopmentcleanenoughtobuildacompleteproductasoftenastheywantorneedto.

Afundamentalpartofwhatmakesaprojectagileisthefrequentdeliveryofaworkingproduct.Ateamthatdoesnotdemonstrateorreleasecannotlearnfastenough and is likely not adopting agile techniques. The team may requireadditionalcoachingtoenablefrequentdelivery.

5.2.6PLANNINGFORITERATION-BASEDAGILEEach team's capacity is different. Each product owner's typical story size is

different.Teamsconsidertheirstorysizesotheydonottrytocommittomorestoriesthanthereisteamcapacitytocompletewithinoneiteration.

When people are unavailable (e.g., holidays, vacations, or anything thatpreventspeople fromparticipating in thenext setofwork), theproductownerunderstands that the team has reduced capacity. The teamwill not be able tofinishthesameamountofworkasitfinishedintheprevioustimeperiod.Whenteams have a reduced capacity, they will only plan for work that meets thatcapacity.

Teamsestimatewhattheycancomplete,whichisameasureofcapacity(seeSection4.10forexamples).Teamscannotpredictwith100%certaintywhattheycandeliver, as they cannot know theunexpected.Whenproduct ownersmakethe stories smaller and teams see progress in the form of a finished product,teamslearnwhattheyareabletodoforthefuture.

Agile teamsdonot plan just once in one single chunk. Instead, agile teamsplanalittle,deliver,learn,andthenreplanalittlemoreinanongoingcycle.

TIP

Draw the team's attention to the antipattern and help the team todiscoverhowtoimproveitsstandups.

5.2.7EXECUTIONPRACTICESTHATHELPTEAMSDELIVERVALUEIftheteamdoesnotpayattentiontoquality,itwillsoonbecomeimpossibleto

releaseanythingrapidly.

The following technical practices, many of which come from eXtremeProgramming,mayhelptheteamtodeliverattheirmaximumspeed:

Continuousintegration.Performfrequentincorporationofworkintothewhole,nomattertheproduct,andthenretesttodeterminethattheentireproductstillworksasintended.

Test at all levels. Employ system-level testing for end-to-endinformation and unit testing for the building blocks. In between,understandifthereisaneedforintegrationtestingandwhere.Teamsfindsmoketestinghelpfulasafirstlookatwhethertheworkproductisanygood.Teamshavefoundthatdecidingwhentorunregressiontestsandwhichoneshelps themmaintainproductqualitywithgoodbuild performance. Agile teams have a strong preference forautomated tests so they can build and maintain a momentum ofdelivery.

Acceptance Test-Driven Development (ATDD). In ATDD, theentire team gets together and discusses the acceptance criteria for aworkproduct.Thentheteamcreatesthetests,whichallowstheteamtowritejustenoughcodeandautomatedteststomeetthecriteria.Fornon-software projects, consider how to test the work as the teamcompleteschunksofvalue.

Test-Driven Development (TDD) and Behavior-Driven

Development(BDD).Writingautomatedtestsbeforewriting/creatingthe product actually helps people design and mistake-proof theproduct. For non-software projects, consider how to “test-drive” theteam's designs. Hardware and mechanical projects often usesimulationsforinterimtestsoftheirdesigns.

Spikes (timeboxedresearchorexperiments).Spikesareuseful forlearning and may be used in circumstances such as: estimation,acceptancecriteriadefinition, andunderstanding the flowofauser'sactionthroughtheproduct.Spikesarehelpfulwhentheteamneedstolearnsomecriticaltechnicalorfunctionalelement.

5.2.8HOWITERATIONSANDINCREMENTSHELPDELIVERWORKINGPRODUCTIterations help a team create a cadence for delivery and many kinds of

feedback. Teams produce increments of value for delivery and feedback. Thefirstpartofthisdeliveryisademonstration.Teamsreceivefeedbackabouthowtheproductlooksandoperatesthroughademo.Teammembersretrospecttoseehowtheycaninspectandadapttheirprocesstosucceed.

Demonstrations or reviews are a necessary part of the agile project flow.Schedulethedemonstrationasappropriatefortheteam'sdeliverycadence.

5.3 TROUBLESHOOTING AGILE PROJECTCHALLENGES

Agile approacheswere born out of the need to solve issues associatedwithhigh rates of change, uncertainty, and complexity on projects. Due to theseorigins,theycontainavarietyoftoolsandtechniquesfordealingwithissuesthatpresentproblemsinpredictiveapproaches.RefertoTable5-1.

TIP

Teamsshoulddemooftenforfeedbackandtoshowprogress.Encouragethe PMO and other interested parties to watch demonstrations so thepeopledecidingontheprojectportfoliocanseetheactualprogress.

Table5-1.AgilePainPointsandTroubleshootingPossibilities

PainPoint TroubleshootingPossibilities

Unclearpurposeormissionfortheteam Agilecharteringforpurpose–vision,mission,andmissiontests

Unclearworkingagreementsfortheteam Agilecharteringforalignment–values,principles,andworkingagreements

Unclearteamcontext Agilecharteringforcontext–boundaries,committedassets,andprospectiveanalysis

Unclearrequirements Helpsponsorsandstakeholderscraftaproductvision.Considerbuildingaproductroadmapusingspecificationbyexample,userstorymapping,andimpactmapping.Bringtheteamandproductownertogethertoclarifytheexpectationsandvalueofarequirement.Progressivelydecomposeroadmapintobacklogofsmaller,concreterequirements.

Pooruserexperience Userexperiencedesignpracticesincludedinthedevelopmentteaminvolveusersearlyandoften.

Inaccurateestimation Reducestorysizebysplittingstories.Userelativeestimationwiththeentireteamtoestimate.Consideragilemodelingorspikingtounderstandwhatthestoryis.

Unclearworkassignmentsorworkprogress Helptheteamlearnthattheyself-managetheirwork.Considerkanbanboardstoseetheflowofwork.Consideradailystanduptowalktheboardandseewhatworkiswhere.

Teamstruggleswithobstacles Aservantleadercanhelpcleartheseobstacles.Iftheteamdoesn'tknowtheoptionstheyhave,consideracoach.Sometimes,theteamneedstoescalatestoriestheteamorservantleaderhasnotbeenabletoremove.

Workdelays/overrunsduetoInsufficientlyrefinedproductbacklogitems

Productownerandteamworkshopstoriestogether.Createadefinitionofreadyforthestories.Considersplittingstoriestousesmallerstories.

Defects Considerthetechnicalpracticesthatworkfortheenvironment.Somepossibilitiesare:pairwork,collectiveproductownership,pervasivetesting(test-drivenandautomatedtestingapproaches)andarobustdefinitionofdone.

Workisnotcomplete Teamdefinesdefinitionofdoneforstories

Workisnotcomplete Teamdefinesdefinitionofdoneforstoriesincludingacceptancecriteria.Alsoaddreleasecriteriaforprojects.

Technicaldebt(degradedcodequality) Refactoring,agilemodeling,pervasivetesting,automatedcodequalityanalysis,definitionofdone

Toomuchproductcomplexity Forsoftwareandnon-softwareencouragetheteamalwaystobethinking“Whatisthesimplestthingthatwouldwork?”andapplytheagileprincipleof“Simplicity--theartofmaximizingtheamountofworknotdone”.Thesehelpreducecomplexity.

Slowornoimprovementintheteamworkprocess Capturenomorethanthreeitemstoimproveateachretrospective.Asktheservantleadertohelptheteamlearnhowtointegratethoseitems.

Toomuchupfrontworkleadingtorework Insteadofmuchupfrontwork,considerteamspikestolearn.Inaddition,measuretheWIPduringthebeginningoftheprojectandseewhattheteam'soptionsaretodelivervalueinsteadofdesigns.Shorteniterationsandcreatearobustdefinitionofdone.

Falsestarts,wastedefforts Asktheproductownertobecomeanintegralpartoftheteam.

Inefficientlyorderedproductbacklogitems Rankwithvalueincludingcostofdelaydividedbyduration(CD3)andothervaluemodels

Rush/waitunevenflowofwork Plantotheteam'scapacityandnotmore.Askpeopletostopmultitaskingandbededicatedtooneteam.Asktheteamtoworkaspairs,aswarm,ormobtoevenoutthecapabilitiesacrosstheentireteam.

Impossiblestakeholderdemands Servantleadershiptoworkwiththisstakeholder(andpossiblyproductowner).

Unexpectedorunforeseendelays Asktheteamtocheckinmoreoften,usekanbanboardstoseetheflowofworkandworkinprogresslimitstounderstandtheimpactofthedemandsontheteamorproduct.Alsotrackimpedimentsandimpedimentremovalonanimpedimentboard.

Siloedteams,insteadofcross-functionalteams Askthepeoplewhoarepartofprojectstoself-organizeascross-functionalteams.Useservantleadershipskillstohelpthemanagersunderstandwhyagileneedscross-functionalteams.

5.4MEASUREMENTSINAGILEPROJECTS

Transitioningtoagilemeansusingdifferentmeasurements.Usingagilemeanslooking at new metrics that matter to the team and to management. Thesemetricsmatterbecausetheyfocusoncustomervalue.

Oneproblemwithstatusreporting is the team'sability topredictcompletionortousetrafficlightstatustodescribetheproject.Forinstance,projectleadersdescribetheprojectas“90%done.”Atthatpointtheteamtriestointegratethepiecesintoaproduct.Theteamdiscoversmissingrequirementsorsurprises,orfindsthattheproductdoesn'tintegratethewaytheythoughtitwould.

Theprojectisonlypartwaydone,andthetrafficlightstatusreportingdoesnotreflecttherealstate.Toooften,theprojectteamrealizesitwillneedjustasmuchtimetocomplete theremainderof theproject.For toomanyprojects, the teamrealizestheyare—atmost—10%donebecauseofissuestheteamdiscovered.

The problemwith predictivemeasurements is that they often do not reflectreality. It often happens that a project status light is green up until 1 monthbefore the release date; this is sometimes referred to as a watermelon project(greenontheoutside,redontheinside).Oftentimesprojectstatuslightsturnredwithseeminglynowarnings,becausethereisnoempiricaldataabouttheprojectuntil1monthbeforethereleasedate.

Metrics for agile projects contain meaningful information that provide ahistoricaltrackrecord,becauseagileprojectsdelivervalue(finishedwork)onaregular basis. Project teams can use such data for improved forecasts anddecisionmaking.

Surrogatemeasurements suchaspercentdoneare lessuseful thanempiricalmeasurementssuchasfinishedfeatures.SeeSection4.10formoreinformationonvaluemanagement.Agilehelps teams seeproblemsand issues so the teamcandiagnoseandaddressthem.

In addition to quantitative measures, the team can consider collectingqualitativemeasures.Someofthesequalitativemeasuresfocusonpracticestheteamhaschosenandassesshowwelltheteamusesthosepractices,forexample,the business satisfaction with delivered features, the morale of the team; andanythingelsetheteamwantstotrackasaqualitativemeasure.

5.4.1AGILETEAMSMEASURERESULTS

5.4.1AGILETEAMSMEASURERESULTSAgile favors empirical and value-based measurements instead of predictive

measurements. Agile measures what the team delivers, not what the teampredictsitwilldeliver.

AteamthatisaccustomedtohavingprojectbaselinesandestimatesofearnedvalueandROImightbepuzzledaboutworkingonaprojectandnotmanagingtoa baseline. Agile is based on working products of demonstrable value tocustomers.

Baselinesareoftenanartifactofattemptedprediction.Inagile,theteamlimitsitsestimationtothenextfewweeksatmost.Inagile,ifthereislowvariabilityinthe team's work and if the team members are not multitasking, the team'scapacitycanbecomestable.Thisallowsbetterpredictionforthenextcoupleofweeks.

Aftertheteamcompletesworkiniterationorflow,theteamcanreplan.Agiledoesnotcreatetheabilitytodomorework.However,thereisevidencethatthesmallerthechunkofwork,themorelikelypeoplearetodeliverit.

Softwareproductdevelopment, likeotherknowledgework,isaboutlearning—learning while delivering value. Hardware development and mechanicaldevelopmentaresimilarinthedesignpartsoftheproject.Learningtakesplacebyexperimenting,deliveringsmallincrementsofvalue,andgettingfeedbackonwhathasbeenaccomplishedthusfar.Manyotherproductdevelopmentprojectsincorporatelearningalso.

Sponsors usuallywant to knowwhen the projectwill be done.Once theteam establishes a reliable velocity (average stories or story points periteration)ortheaveragecycletime,theteamcanpredicthowmuchlongertheprojectwilltake.

Asanexample, if the teamaverages50storypointsper iteration,andtheteam estimates there are about another 500 points remaining, the teamestimates ithasabout10 iterations remaining.As theproductowner refinesthestoriesremainingandastheteamrefinesitsestimates,theprojectestimatecouldgoupordown,buttheteamcanprovideanestimate.

If the teamaveragesacycle timeof threedaysperstoryandthereare30remaining stories, the team would have 90 business days remaining,approximately4to5months.

Reflect the estimate variabilitywith hurricane-style charts, or some othervariabilitymeasurethatthesponsorswillunderstand.

Becauselearningissuchalargepartoftheproject,theteamneedstobalanceuncertaintyandprovidevalue to thecustomers.The teamplans thenext smallpart of the project. The team reports empirical data and replans further smallincrementstomanagetheprojectuncertainty.

Someiteration-basedprojectsuseburndownchartstoseewheretheprojectisgoingover time.Figure5-1showsanexampleofaburndownchartwhere theteamplannedtodeliver37storypoints.Storypointsratetherelativework,risk,andcomplexityofarequirementorstory.Manyagileteamsusestorypointstoestimateeffort.Thedottedburndownlineistheplan.InFigure5-1,theteamcanseebyDay3thattheyareatriskforthatdelivery.

Someprojectteamspreferburnupcharts.ThesamedatausedinFigure5-1isshowninFigure5-2inaburnupchart.

Burnupchartsshowtheworkcompleted.ThetwochartsinFigures5-1and5-2arebasedonthesamedata,butdisplayedin twodifferentways.Teamsmaypreferhowtoseetheirdata.

When a team sees what it has not yet completed as it works through aniteration, the team may become dispirited and possibly rush to complete theworkwithoutmeetingtheacceptancecriteria.However,theteamcouldhaveanynumber of good reasons for not completing work as it expected. Burndownsshowtheeffectofteammembersmultitasking,storiesthataretoolarge,orteammembersoutoftheoffice.

Especiallywith teams new to agile, the burnupwill show changes in scopeduringthe iteration.Burnupsallowteamstoseewhat theyhaveaccomplished,whichhelpstheteamproceedtothenextpieceofwork.

Whether teams use burndown or burnup charts, they see what they havecompletedastheiterationprogresses.Attheendoftheiteration,theymightbasetheirnextmeasureofcapacity(howmanystoriesorstorypoints)onwhattheycompletedinthisiteration.Thatallowstheproductowneralongwiththeteamtoreplanwhattheteamismorelikelytosucceedindeliveringinthenextiteration.

Velocity,thesumofthestorypointsizesforthefeaturesactuallycompleted

in this iteration, allows the team to plan its next capacitymore accurately bylookingatitshistoricalperformance.

Flow-basedagileteamsusedifferentmeasurements:leadtime(thetotaltimeittakestodeliveranitem,measuredfromthetimeitisaddedtotheboardtothemomentitiscompleted),cycletime(thetimerequiredtoprocessanitem),andresponse time (the time that an itemwaits until work starts). Teamsmeasurecycletimetoseebottlenecksanddelays,notnecessarilyinsidetheteam.

TIP

Teamsmight discover it can take four to eight iterations to achieve astable velocity. The teamsneed the feedback fromeach iteration to learnabouthowtheyworkandhowtoimprove.

Leadtimeisusefultounderstandcycletimefromthefirstlookataparticularfeature to the lengthof time it took to release it to the customer.Thework inprogress(WIP)limitsatthetopofeachcolumn,showninboxeshere,allowstheteamtoseehowtopullworkacrosstheboard.WhentheteamhasmetitsWIPlimits,theteamcannotpullworkfromtheleftintothenextcolumn.Instead,theteamworksfromtheright-mostfullcolumnandasks,“Whatdowedoasateamtomovethisworkintothenextcolumn?”

Eachfeatureisunique,soitscycletimeisunique.However,aproductownermightnoticethatsmallerfeatureshavesmallercycletimes.Theproductownerwantstoseethroughput,sotheproductownercreatessmallerfeaturesorworkswiththeteamtodoso.

Burnups, burndowns (capacity measures) and lead time, and cycle time(predictabilitymeasures)areusefulforin-the-momentmeasurements.Theyhelpateamunderstandhowmuchmoreworktheyhaveandwhethertheteammightfinishontime.

Measuring story points is not the same as measuring completed stories orfeatures. Some teams attempt to measure story points without completing theactual feature or story.When teams measure only story points, they measurecapacity,notfinishedwork,whichviolatestheprincipleof“theprimarymeasureofprogressisworkingsoftware”(or,otherproductifnotsoftware).

Eachteamhasitsowncapacity.Whenateamusesstorypoints,beawarethatthenumberofstorypointsateamcancompleteinagiventimeisuniquetothatteam.

TIP

Whenteamsdependonexternalpeopleorgroups,measurecycletimetoseehowlongittakesfortheteamtocompletethework.Measureleadtimetoseetheexternaldependenciesaftertheteamcompletesitswork.Teamscanalsomeasurethereactiontime,thetimefromreadytothefirstcolumn,toseehowlongittakesthem—onaverage—torespondtonewrequests.

When teams provide their own units of measure, teams are better able toassessandestimateanddelivertheirwork.Thedownsideofrelativeestimationisthatthereisnowaytocompareteamsoraddvelocityacrossteams.

The team canmeasure completedwork in a feature burnup/burndown chartand in a product backlog burnup chart. These charts provide trends ofcompletionovertime,asshowninFigure5-4.

Featureburnup/burndownchartsmayshowthatrequirementsgrewduringtheproject.Thefeaturescompletelineshowsthat theteamcompletesfeaturesataregular pace. The total features line shows how the project's total featureschangedovertime.Thefeaturesremainingburndownlineshowsthattherateoffeature completion varies. Every time features are added to the project, theburndownlinechanges.

Earnedvalue in agile isbasedon finished features, as shown inFigure5-5.The product backlog burnup chart shows completed work compared to totalexpectedworkatintervalmilestonesoriterations.

Ateamcanonly finishonestoryata time.Tocompletea large feature thatcontains several stories, the teamwill have remaining stories to complete andmaynotcompletethatentirefeatureuntilseveralmoretimeperiodshavepassed.TheteamcanshowitscompletedvaluewithaproductbacklogburnupchartasshowninFigure5-5.

If a team needs tomeasure earned value, it can consider using this burnupchart in Figure 5-6 as an example: Note that the left Y axis represents storypointsasscope,andtherightYaxisrepresentstheprojectspend.

Traditional EVM metrics like schedule performance index (SPI) and costperformanceindex(CPI)canbeeasilytranslatedintoagileterms.Forexample,if the team planned to complete 30 story points in an iteration, but onlycompleted25thentheSPIis25/30or0.83(theteamisworkingatonly83%oftherateplanned).Likewise,CPIistheearnedvalue(completedfeaturesvalue)todatedividedby theactualcosts todateor,asshowninFigure5-6,$2.2M/$2.8M=0.79.Thismeansa resultofonly79centson thedollarcompared toplan(butofcoursethisassumesthatthepredictionisstillcorrect.)

A cumulative flow diagram, illustrated in Figure 5-7, shows the work inprogressacrossaboard.Ifa teamhasmanystorieswaitingfortest, thetestingbandwillswell.Workaccumulationcanbeseenataglance.

Teamshave troublewithaccumulatingwork: the teamhaswork inprogressinstead ofwork completed.When teams have a lot ofwork in progress, theydelaytheiroverallfeaturedelivery.Thelongerittakesforateamtodeliver,themorepressureateamwillhaveforyetmorefeaturesinthesameperiodoftime.

Adaptthiscumulativeflowtotheprojecttaskboard.

6

ORGANIZATIONALCONSIDERATIONSFORPROJECTAGILITY

Every project exists in an organizational context. Cultures, structures, andpoliciescaninfluenceboththedirectionandtheoutcomeofanyproject.Thesedynamicscanchallengeprojectleaders.

While project leaders may not have the ability to change organizationaldynamicsastheyseefit,theyareexpectedtonavigatethosedynamicsskillfully.

Thissectionexploresthewaytheorganizationandinsomecircumstances,theprojectcontext, influencesprojects.Leaderscanexploreoptionsforchange, toincreaseprojectsuccess.

Projectagilityismoreeffectiveandsustainedastheorganizationadjuststosupportit.

6.1ORGANIZATIONALCHANGEMANAGEMENTOrganizational change management covers the skills and techniques for

influencingchangesthatsupportagility.

ThePMIpublication,ManagingChangeinOrganizations:APracticeGuide[2], describes a comprehensive and holistic approach for successfullyintroducingmeaningfulchange.Therecommendationsofferedthereinclude:

Modelsfordescribingchangedynamics,

Frameworkforachievingchange,and

Applicationofchangemanagementpracticesattheproject,program,andportfoliolevels.

Sections 6.1.1 and 6.1.2 explore the considerations of change managementspecifictoanagilecontext.

Figure6-1showstherelationshipbetweenthesetwotopics.

6.1.1DRIVERSFORCHANGEMANAGEMENT

Allprojectsareaboutchange.However,therearetwokeyfactorsthatfurthermotivatetheuseofchangemanagementpracticesinanagilecontext:

Changes associated with accelerated delivery. Agile approachesemphasize delivering project outputs early and often. However, the

receivingorganizationmaynotbefullypreparedtoincorporatethoseoutputs at an increased pace. Accelerating delivery will test theorganization's ability to accommodate that delivery. Successfullydiscovering and delivering a project's features is not enough. If theorganization resists the project's output, then the targeted return oninvestment is delayed. Customer acceptance of and alignment withprojectoutputsbecomesevenmoreprevalentinanagileenvironment.

Changes associated with agile approaches. Organizations justbeginning to use agile approaches also experience high degrees ofchange. Higher degrees of collaborationmay require more frequenthandoffsbetweenteams,departments,orvendors.Decomposingworkinto iterative prototypes involves rework that could be viewednegatively. Leaders should consider changemanagement techniquestoaddressthehurdlesoftransitioningtotheuseofagileapproaches.

6.1.2READINESSFORCHANGEOrganizations beginning to use agile approaches should understand the

relative compatibility of those methods with their current approaches. Someorganizationswillhavecharacteristics thatmoreeasilysupportagileprinciplesof cross-department collaboration, continuous learning, and evolving internalprocesses.Examplesofthesechange-friendlycharacteristicsinclude:

Executivemanagement'swillingnesstochange;

Organization's willingness to shift the way it views, reviews, andassessesemployees;

Centralization or decentralization of project, program, and portfoliomanagementfunctions;

Focus on short-term budgeting and metrics versus long-term goals;and

Talentmanagementmaturityandcapabilities.

Conversely,thereareotherinstitutionalcharacteristicsthatmayberoadblocksto achieving the changes associated with organizational agility. Examples oftheseinclude:

Work is decomposed into departmental silos, creating dependenciesthat prevent accelerateddelivery insteadofbuilding cross-functional

teamswithguidancefromcentersofcompetencies.

Procurement strategies are based on short-term pricing strategies,ratherthanlong-termcompetencies.

Leadersarerewardedforlocalefficienciesratherthanend-to-endflowof project delivery or optimizing the whole (in regard to theorganization).

Employees are specialized contributors with limited tools orincentives to diversify their skills instead of building T-shapedspecialists.

Decentralized portfolios pull employees simultaneously onto toomanyprojectsatonceinsteadofkeepingthemfocusedononeprojectatatime.

The degree towhich an organization iswilling to review andmodify thesepractices will determine how quickly and effectively agile approaches can beadopted.However, in response to these organizational impediments to agility,projectleaderscantryvariousapproachestoaccelerateaculturalcompatibilityfor:

Visibleandactiveexecutivesponsorship,

Change management practices, including communication andcoaching,

Progressivelypacing theadoptionofagilepracticesonaproject-by-projectbasis

Incrementalintroductionofagilepracticestotheteam;and

Leading by example by using agile techniques and practices wherepossible.

6.2ORGANIZATIONALCULTUREAnorganization's culture is itsDNA—its core identity.Culturewill always

influence the use of agile approaches. Organizational culture runs along acontinuum, fromhighlypredictiveplans to leanstartupwhereeverything isanexperiment.Althoughagile approaches fitwellwith the lean startup culture, ahighly predictive organization can encourage empirical measurements, smallexperiments,andlearningsotheycanmovetowardagility.

“Cultureeatsstrategyforbreakfast”—PeterDrucker

Thisstatementstressestheimportanceofpeople'scommitmentandpassionforacause.Nomatterwhatstrategyorplanyouimplementwithyourteam,itssuccessisgoingtobegovernedbythepeopleimplementingtheplan.Ifthepeople who are driving the strategy aren't passionate about the change, orworse, are apathetic about their job and their organization, then you standlittlechanceofimplementingthechange.

6.2.1CREATINGANENVIRONMENTOFSAFETYOrganizational culture isdifficult to change,but themost important cultural

norminanorganizationwillingtotryanynewmethodortechniqueisenablingasafeworkenvironment.

Only in a safe, honest, and transparent environment can teammembers andleaders truly reflect on their successes to ensure their projects continue toadvance,orapplylessonslearnedonfailedprojectssotheydonotfallbackintothesamepatterns.

6.2.2ASSESSINGCULTUREEveryprojectfindsitselfintensionwithcompetingaspirations.Howcanthe

team go fast without compromising quality? How can the team preserveflexibilitywhilealsohittingafirmdate?Most importantly,howdoes the teamsatisfyandmeettherequirementsofthecustomer?

Project leaders may feel their job is to meet every expectation of everystakeholder; but, when compelled to make a choice, there is often a prioritydepending on the culture and requirements of the organization's businessenvironment.Forexample,amobiletelecomprojecthasagreaterbiasforspeed,where a government program may have a greater bias for generalization andstability.

To navigate these dynamics, project leaders should take the time to assesswhereemphasisismostoftenappliedintheorganization.Figure6-2illustrateswhatanassessmentmightlooklike.Inthisexample,aprojectleaderinitiatesa

conversation about organizational priorities with stakeholders, teammembers,and senior management. Those priorities are then recorded as positions on asliding scale between two extremes. The results are then used to find agiletechniquesthatbestfitwiththosepriorities.

Several models exist for assessing such dynamics; however, the model ormethodused isnot that important. It ismorecritical thatproject leaders investthe effort to understand the forces that shape their context.Understanding theorganizationandtheindustryrequirementsthatanorganizationneedstosatisfyallowsforchoosingtherightconversations, theright tradeoffs,and,especially,therighttechniques.

6.3PROCUREMENTANDCONTRACTSAs mentioned earlier in this practice guide, the Agile Manifesto values

“customercollaborationover contractnegotiation.”Manyproject failures stemfrombreakdownsinthecustomer–supplierrelationship.Projectsincurmoreriskwhenthoseinvolvedinthecontracttaketheperspectiveofwinnersvs.losers.Acollaborative approach is one that pursues a shared-risk-reward relationship,

where all sides win. Some contracting techniques that can formalize thisdynamicincludethefollowing:

Multi-tieredstructure.Ratherthanformalizinganentirecontractingrelationship in a single document, project parties can achieve moreflexibility by describing different aspects in different documents.Mostly fixed items (e.g., warranties, arbitration) can be locked in amaster agreement.Meanwhile, all parties list other items subject tochange (e.g., services rates, product descriptions) in a schedule ofservices. The contract can reference them in the master servicesagreement.Finally,moredynamicitemssuchasscope,schedule,andbudgetcanbeformalizedinalightweightstatementofwork.Isolatingthe more changing elements of a contract into a single documentsimplifiesmodificationsandthusflexibility.

Emphasizevaluedelivered.Manyvendorrelationshipsaregovernedbyfixedmilestonesor“phasegates”focusedonintermediateartifacts,rather than a full deliverable of incremental business value. Often,these controls limit the use of feedback to improve the product.Instead, milestones and payment terms can be structured based onvalue-drivendeliverablesinordertoenhancetheproject'sagility.

Fixed-priceincrements.Ratherthanlockanentireprojectscopeandbudget into a single agreement, a project can decompose the scopeinto fixed-price microdeliverables, such as user stories. For thecustomer, this givesmore control overhow themoney is spent.Forthesupplier,itlimitsthefinancialriskofover-commitmenttoasinglefeatureordeliverable.

Not-to-exceed time andmaterials. Customers incur unwanted riskfroma traditional timeandmaterials approach.Onealternative is tolimittheoverallbudgettoafixedamount.Thisallowsthecustomertoincorporatenew ideasand innovations into theprojectnotoriginallyplanned.When customers want to incorporate new ideas, they willhavetomanagetoagivencapacity,replacingoriginalworkwithnewwork.Workshouldbecloselymonitoredashoursallocatedreachtheirlimit. Also, additional contingency hours could be planned into themaximumbudgetifconsideredhelpful.

Graduated time and materials. Another alternative is a sharedfinancial riskapproach. Inagile, thequalitycriteriaarepartofwhat

donemeans. Therefore, the supplier can be rewardedwith a higherhourly rate when delivery is earlier than the contracted deadline.Conversely, the supplier would suffer a rate reduction for latedelivery.

Earlycancellationoption.Whenanagilesupplierdeliverssufficientvaluewithonlyhalfofthescopecompleted,thecustomershouldnotbeboundtopaytheremaininghalfifthecustomernolongerneedsit.Instead,acontractcanofferthecustomertobuytheremainderoftheproject for a cancellation fee. The customer limits budget exposureand the supplier earns positive revenue for services no longerrequired.

Dynamic scope option. For those contracts with a fixed budget, asuppliermayofferthecustomertheoptiontovarytheprojectscopeatspecifiedpointsintheproject.Thecustomercanadjustfeaturestofitthe capacity. Then the customer can leverage innovationopportunities,whilelimitingthesupplier'sriskofovercommitment.

Team augmentation. Arguably the most collaborative contractingapproachistoembedthesupplier'sservicesdirectlyintothecustomerorganization.Fundingteamsinsteadofaspecificscopepreservesthecustomer'sstrategicdiscretiononwhatworkshouldactuallybedone.

Favor full-service suppliers. In order to diversify risk, customersmayseekamultisupplierstrategy.However,thetemptationwillbetocontracttheworksuchthateachsupplierdoesonlyonething,whichcreates aweb of dependencies before any usable service or productemerges.Instead,placeanemphasisonengagementsthatdeliverfullvalue(asintheideaofcompletedindependentfeaturesets).

TIP

CultureversusStructure

Somepeopleinsistneworganizationalstructuresbeinstalledbeforeanycultural shift can begin. Others maintain the opposite—those neworganizational structures are only superficial adjustments until thecollective culturemoves in ameaningful direction. In reality, one cannot

progress without the other. Project leaders wanting to achieve agilityshould consider the current and future states of both of these aspects intheirorganization.

It is possible to create agile contracts. Agile is built on a synergy ofcollaboration and trust. The supplier can help by delivering value early andoften.Thecustomercanhelpbyprovidingtimelyfeedback.

6.4BUSINESSPRACTICESThewillingnessandabilitytocreatenewcompetenceswithinanorganization

whentheneedarisesisamarkoforganizationalagility.Thesedonothavetobeearth-shatteringchangesandcouldbe lessdisruptive inanorganization that isfocused on agility and the results it provides. Transparency and opencollaborationareabsolutelykey.

As cross-functional teams deliver value, the teams and individuals mightencounterproblemswithvarioussupportfunctionsintheorganization.

Asteamdeliversvalueonaregularbasis,financedepartmentsmayhavetheopportunity tocapitalize theproductdifferently. If the teamhascontractswithother organizations, procurement departments may need to change thosecontracts to help the other organizations deliver value frequently andsynchronizewiththeteam.

Once teams start to work in a cohesive and cooperative manner, they willchallengeinternalmanagementpolicies.Humanresourcesmaynoticeindividualincentivesmake less sense, andmanagersmay struggle with the performanceappraisalsofself-organizingemployees.Ineachcase,theseareopportunitiestoreviewthedegreetowhichexistingpracticessupportagilewaysofworking.

Asorganizations progress to greater agility, therewill be obvious needs foradditional business units to change the way they interact and perform theirresponsibilities.Thechangesthathavebenefitedotherareasoftheorganizationshouldnowbeembracedso theeffectivenessof theentireorganizationcanberealized.

6.5MULTITEAMCOORDINATIONANDDEPENDENCIES(SCALING)

DEPENDENCIES(SCALING)Manyprojectsincurdependencies,evenwhentheyarenotmanagedwithina

givenprogram.Forthisreason,itisnecessarytohaveanunderstandingofhowagileworkswithinanexistingprogramandportfoliomanagementcontext.

6.5.1FRAMEWORKSThe guidance of the most widespread agile methods such as Scrum and

eXtreme Programming focus on the activities of a single, small, usuallycolocated,cross-functionalteam.Whilethisisveryusefulforeffortsthatrequireasingleteam,itmayprovideinsufficientguidanceforinitiativesthatrequirethecollaborationofmultipleagileteamsinaprogramorportfolio.

A range of frameworks (such as the ScaledAgile Framework, Large ScaleScrum, and Disciplined Agile) and approaches (e.g., Scrum of Scrums) haveemergedtocatertojustsuchcircumstances.MoredetailsonthesecanbefoundinAnnexA3.

6.5.2CONSIDERATIONSThereismorethanonewaytoscalework.Theteammightneedtoscalethe

work of several agile projects into a single agile program. Alternatively, theorganization can design a structure that supports agile approaches across theentireportfolio.

Forexample,itishelpfultostartsmallandlearnasrapidlyaspossiblewhatworks well in the organizational context. Teams can achieve successfuloutcomes even when everything is not completely transformed into an agileapproach.

Regardlessoftheapproach,acriticalsuccessfactoristhehealthyagileteam.Ifusinganagileapproachforasingleteamisnotsuccessful,donottrytoscaleuptousingitmorebroadly;instead,addresstheorganizationalimpedimentsthatpreventteamsfromworkinginanagileway.

Thegoalof large-scaleagileprojects is tocoordinate theeffortsofdifferentteamstobringvaluetocustomers.Thereismorethanonewaytodothat.Teamsmayuseaformalframeworkorapplyagilethinkingtoadjustexistingprogrammanagementpractices.

6.6AGILEANDTHEPROJECTMANAGEMENTOFFICE(PMO)The PMO exists to shepherd business value throughout the organization. It

might do this by helping projects achieve their goals. Sometimes, the PMOeducates teams(orarrangesfor training)andsupportsprojects.Sometimes, thePMOadvisesmanagementabouttherelativebusinessvalueforagivenprojectorsetofprojects.

Becauseagilecreatesculturalchange,overtime,theorganizationmightneedto change, including the PMO. For example, managers make decisions aboutwhichprojectstofundandwhen,andteamsdecidewhattheyneedfortrainingoradvice.

6.6.1ANAGILEPMOISVALUE-DRIVENAnyprojectshoulddeliver therightvalue, to therightaudience,at theright

time.ThePMO'sobjective is to facilitateandenable thisgoal.Anagile-basedPMOapproachisbasedonacustomer-collaborationmindsetandispresentinallPMO programs. Inmany cases, this means the PMO operates as if it were aconsulting business, tailoring its efforts tomeet specific needs requested by agiven project. Some projectsmay need tools and templates,while othersmaybenefit from executive coaching. The PMO should strive to deliver what isneededandkeepthepulseonitscustomerstoensurethatitknowsandisabletoadapt to theirneeds.This intrapreneurapproachfocuseson thePMOactivitiesthatareperceivedasthemostvaluabletotheprojectsitsupports.

6.6.2ANAGILEPMOISINVITATION-ORIENTEDIn order to accelerate progress on a value-based charter, a PMO may be

tempted to mandate certain solutions or approaches, for example, to makeeveryonedoitthesamewaytogetsomequickwins.However,amoredeliberateperspective incorporates thedesire foremployeeengagement.This is achievedby inviting only those interested to engage with PMO services. Higherengagement with PMO practices makes it easier for those practices to be“sticky.”IfthePMOisdeliveringvaluetoitsclients,itismorelikelythatclientswillrequestitsservicesandadoptitspractices.

6.6.3ANAGILEPMOISMULTIDISCIPLINARYInordertosupportproject-specificneeds,thePMOneedstobeconversantin

several competencies beyond project management itself, because differentprojects require distinct capabilities. For instance, one project may needorganizational design to address staffing challengeswhile anothermay requireorganizational change management techniques for stakeholder engagement oruniquebusinessmodelstosupportcustomergoals.

SomeorganizationshavebeentransformingtheirPMOsintoagilecentersofexcellencethatprovidesuchservicesas:

Developingandimplementingstandards.Providetemplatesforuserstories, testcases,cumulativeflowdiagrams,etc.Provideagile toolsandeducatesupportinggroupsoniterativedevelopmentconcepts.

Developingpersonnelthroughtrainingandmentoring.Coordinateagiletrainingcourses,coaches,andmentorstohelppeopletransitionto an agilemindset and upgrade their skills. Encourage and supportpeopletoattendlocalagileevents.

Multiproject management. Coordinate between agile teams bycommunicating between projects. Consider sharing items such asprogress, issues, and retrospective findings and improvementexperiments. Help manage major customer releases at the programlevelandinvestmentthemesattheportfoliolevelusinganappropriateframework.

Facilitatingorganizationallearning.Gatherprojectvelocityprofilesandcapture,store,andindexretrospectivefindings.

Managing stakeholders. Provide product owner training, guidanceon acceptance testing, and how to evaluate and give feedback onsystems.Champion the importanceofsubjectmatterexperts (SMEs)toprojects.

Recruiting, selecting, and evaluating team leaders. Developguidelinesforinterviewingagilepractitioners.

Executing specialized tasks for projects. Train and provideretrospective facilitators, create agreements with agile projecttroubleshooters,andprovidementorsandcoaches.

6.7ORGANIZATIONALSTRUCTURE

6.7ORGANIZATIONALSTRUCTUREThestructureofanorganizationstronglyinfluencesitsabilitytopivottonew

informationorshiftingmarketneeds.Hereisalistingofkeycharacteristics:

Geography. Geographically distributed and dispersed projectorganizationsmayfindseveralchallengesimpedingtheirworkonanyproject.Projectleadersandregionalmanagersmayhavealternativeoreven competing goals. Additionally, cultural differences, languagebarriers,andlowervisibilitycanslowdownproductivity.Fortunately,the use of agile approaches can encourage more collaboration andconfidence than would otherwise exist. Project leaders in thesecontexts should encourage dialog at the team and executive level totailortechniquesforthecontextandtomanageexpectationsabouttheeffortrequiredtodoso.

Functionalized structures. Some organizations are structured on aspectrum ranging from highly projectized to matrixed to highlyfunctionalized.Projectswithhighlyfunctionalizedstructuresmayfindgeneralresistancetocollaborationacrossitsorganization.

Sizeofprojectdeliverable.Reducingthesizeofaprojectdeliverablewill motivate more frequent handoffs across departments, and thusmore frequent interactions and a faster flow of value across theorganization.

Allocation of people to projects. Another approach is to ask for asingle person from each department to be temporarily, yet fullyallocated,tothehighestpriorityproject.

Procurement-heavy organizations. Some organizations choose toimplementprojectsprimarilythroughvendors.Althoughprojectgoalsmay be clear, vendors have a responsibility to look after their ownfinancialviability.Moreover,oncevendorscompletetheirobligationsandleavetheengagement,theassociatedprojectknowledgegoeswiththem. This limits the internal competencies needed for sustainedflexibility and speed. Agile techniques such as retrospectives andfollow up on possible improvement areas when the vendor is stillengagedcanhelpmitigatelossofproductknowledge.

6.8EVOLVINGTHEORGANIZATION

6.8EVOLVINGTHEORGANIZATIONWhenaddressinganindividualchallengeareaorimplementinganewhybrid

or agile approach, it is recommended to undertake thework incrementally. Acommonpracticeistotreatthechangeprocessasanagileprojectwithitsownbacklogofchangesthatcouldbeintroducedandprioritizedbytheteam,basedonperceivedvalueorotherconsiderations.Eachofthechangescanbetreatedasanexperiment,whichistestedforashortperiodoftimetodeterminesuitabilityas-isortheneedforfurtherrefinement/consideration.

Usekanbanboardstotrackprogress,showingthenewapproachesalreadyinuse as “done,” thosebeing tried as “inprogress,” and those stillwaiting tobeintroducedas“todo.”SeeFigure6-3fortheinitialboardwitharankedbacklog.Figure6-4showsanexampleofwhataboardmighthaveasworkprogresses.

Usingthesetoolstoorganizeandmanagethechangeimplementationprovidesvisibility into progress and also models the approaches being implemented.Rollingoutchangesinatransparentandappealingwayimprovesthelikelihoodoftheirsuccess.

7

ACALLTOACTIONTheadoptionofagileanditsapproachesformanagingprojectshasincreased

dramatically since the AgileManifesto was first published in 2001. Adoptionandthedesiretooperatewithanagilemindsetisnolongerlimitedtoacertainsized organization or those specializing only in information technology. Themindsetappliesuniversallyandtheapproachesaresuccessfulinmanysettings.

Today,thedemandfor“beingagile”ishigherthanever.Thedebateoverthebestpathtoagilitycontinuestokeeptheconversationandinnovationevolving.Onetruthremainsconstant—inspection,adaptation,andtransparencyarecriticaltosuccessfullydeliveringvalue.

Youmaynot seeeverythingyouexpected to see in thispracticeguide.Ourcoreteamrealizesyoumaydisagreewithsomeelementsorapproacheswedidchoosetopresent—andpassionatelyso.Wecallonyourpassiontocontinuetheconversationand improve thenext iterationof thispracticeguide.This isyourjourney—learn,experiment,gainfeedback,andexperimentagain.Thenhelpusretrospect;giveusfeedbackontheguidanceandcontributetofutureeditionsofthispracticeguide.Afterall,inspectionwithoutadaptationiswastedeffort.

Lastly,wewanttoencourageyoutobeengagedinthebroadercommunitiesofprojectmanagementandagiletofurtherconversationsonthesetopics.Lookfor representatives from both PMI and Agile Alliance® at conferences andmeetings and engage them in discussion. Use social media and blog yourthoughtsandopinions.

Youcanprovidefeedbackandengageinconversationregardingthecontentsof this practice guide at the blog called “Agile in Practice” athttps://www.projectmanagement.com/blogs/347350/Agile-in-Practice.

ANNEXA1PMBOK®GUIDEMAPPINGTableA1-1illustratesthemappingofProjectManagementProcessGroupsto

theKnowledgeAreasdefinedinthePMBOK®Guide–SixthEdition.

Thisannexdescribeshowhybridandagileapproachesaddress theattributesdescribedinthePMBOK®GuideKnowledgeAreas(seeTableA1-2).Itcoverswhat stays the sameandwhatmaybedifferent alongwith someguidelines toconsiderforincreasingthelikelihoodofsuccess.

TableA1-2.ApplicationofAgileinPMBOK®GuideKnowledgeAreas

PMBOK®GuideKnowledgeArea

ApplicationinanAgileWorkProcess

Section4ProjectIntegrationManagement

Iterativeandagileapproachespromotetheengagementofteammembersaslocaldomainexpertsinintegrationmanagement.Theteammembersdeterminehowplansandcomponentsshouldintegrate.

TheexpectationsoftheprojectmanagerasnotedintheKeyConceptsforIntegrationManagementsectionsinthePMBOK®Guidedonotchangeinanadaptiveenvironment,butcontrolofthedetailedproductplanninganddeliveryis

delegatedtotheteam.Theprojectmanager'sfocusisonbuildingacollaborativedecision-makingenvironmentandensuringtheteamhastheabilitytorespondtochanges.Thiscollaborativeapproachcanbefurtherenhancedwhenteammemberspossessabroadskillbaseratherthananarrowspecialization.

Section5ProjectScopeManagement

Inprojectswithevolvingrequirements,highrisk,orsignificantuncertainty,thescopeisoftennotunderstoodatthebeginningoftheprojectoritevolvesduringtheproject.Agilemethodsdeliberatelyspendlesstimetryingtodefineandagreeonscopeintheearlystageoftheprojectandspendmoretimeestablishingtheprocessforitsongoingdiscoveryandrefinement.Manyenvironmentswithemergingrequirementsfindthatthereisoftenagapbetweentherealbusinessrequirementsandthebusinessrequirementsthatwereoriginallystated.Therefore,agilemethodspurposefullybuildandreviewprototypesandreleaseversionsinordertorefinetherequirements.Asaresult,scopeisdefinedandredefinedthroughouttheproject.Inagileapproaches,therequirementsconstitutethebacklog.

Section6ProjectScheduleManagement

Adaptiveapproachesuseshortcyclestoundertakework,reviewtheresults,andadaptasnecessary.Thesecyclesproviderapidfeedbackontheapproachesandsuitabilityofdeliverables,andgenerallymanifestasiterativeschedulingandon-demand,pull-basedscheduling,asdiscussedintheKeyTrendsandEmergingPracticessectionforProjectScheduleManagementinthePMBOK®Guide.

Inlargeorganizations,theremaybeamixtureofsmallprojectsandlargeinitiativesrequiringlong-termroadmapstomanagethedevelopmentoftheseprogramsusingscalingfactors(e.g.,teamsize,geographicaldistribution,regulatorycompliance,organizationalcomplexity,andtechnicalcomplexity).Toaddressthefulldeliverylifecycleforlarger,enterprise-widesystems,arangeoftechniquesutilizingapredictiveapproach,adaptiveapproach,orahybridofboth,mayneedtobeadopted.Theorganizationmayneedtocombinepracticesfromseveralcoremethods,oradoptamethodthathasalreadydoneso,andadoptafewprinciplesandpracticesofmoretraditionaltechniques.

Theroleoftheprojectmanagerdoesnotchangebasedonmanagingprojectsusingapredictivedevelopmentlifecycleormanagingprojectsinadaptiveenvironments.However,tobesuccessfulinusingadaptiveapproaches,theprojectmanagerwillneedtobefamiliarwiththetoolsandtechniquestounderstandhowtoapplythemeffectively.

Projectswithhighdegreesofuncertaintyorthosewherethe

Section7ProjectCostManagement

Projectswithhighdegreesofuncertaintyorthosewherethescopeisnotyetfullydefinedmaynotbenefitfromdetailedcostcalculationsduetofrequentchanges.Instead,lightweightestimationmethodscanbeusedtogenerateafast,high-levelforecastofprojectlaborcosts,whichcanthenbeeasilyadjustedaschangesarise.Detailedestimatesarereservedforshort-termplanninghorizonsinajust-in-timefashion.

Incaseswherehigh-variabilityprojectsarealsosubjecttostrictbudgets,thescopeandschedulearemoreoftenadjustedtostaywithincostconstraints.

Section8ProjectQualityManagement

Inordertonavigatechanges,agilemethodscallforfrequentqualityandreviewstepsbuiltinthroughouttheprojectratherthantowardtheendoftheproject.

Recurringretrospectivesregularlycheckontheeffectivenessofthequalityprocesses.Theylookfortherootcauseofissuesthensuggesttrialsofnewapproachestoimprovequality.Subsequentretrospectivesevaluateanytrialprocessestodetermineiftheyareworkingandshouldbecontinuedornewadjustingorshouldbedroppedfromuse.

Inordertofacilitatefrequent,incrementaldelivery,agilemethodsfocusonsmallbatchesofwork,incorporatingasmanyelementsofprojectdeliverablesaspossible.Smallbatchsystemsaimtouncoverinconsistenciesandqualityissuesearlierintheprojectlifecyclewhentheoverallcostsofchangearelower.

Section9ProjectResourceManagement

Projectswithhighvariabilitybenefitfromteamstructuresthatmaximizefocusandcollaboration,suchasself-organizingteamswithgeneralizingspecialists.

Collaborationisintendedtoboostproductivityandfacilitateinnovativeproblemsolving.Collaborativeteamsmayfacilitateacceleratedintegrationofdistinctworkactivities,improvecommunication,increaseknowledgesharing,andprovideflexibilityofworkassignmentsinadditiontootheradvantages.

Althoughthebenefitsofcollaborationalsoapplytootherprojectenvironments,collaborativeteamsareoftencriticaltothesuccessofprojectswithahighdegreeofvariabilityandrapidchanges,becausethereislesstimeforcentralizedtaskinganddecisionmaking.

Planningforphysicalandhumanresourcesismuchlesspredictableinprojectswithhighvariability.Intheseenvironments,agreementsforfastsupplyandleanmethodsarecriticaltocontrollingcostsandachievingtheschedule.

Projectenvironmentssubjecttovariouselementsof

Section10ProjectCommunicationsManagement

Projectenvironmentssubjecttovariouselementsofambiguityandchangehaveaninherentneedtocommunicateevolvingandemergingdetailsmorefrequentlyandquickly.Thismotivatesstreamliningteammemberaccesstoinformation,frequentteamcheckpoints,andcolocatingteammembersasmuchaspossible.

Inaddition,postingprojectartifactsinatransparentfashion,andholdingregularstakeholderreviewsareintendedtopromotecommunicationwithmanagementandstakeholders.

Section11ProjectRiskManagement

High-variabilityenvironments,bydefinition,incurmoreuncertaintyandrisk.Toaddressthis,projectsmanagedusingadaptiveapproachesmakeuseoffrequentreviewsofincrementalworkproductsandcross-functionalprojectteamstoaccelerateknowledgesharingandensurethatriskisunderstoodandmanaged.Riskisconsideredwhenselectingthecontentofeachiteration,andriskswillalsobeidentified,analyzed,andmanagedduringeachiteration.

Additionally,therequirementsarekeptasalivingdocumentthatisupdatedregularly,andworkmaybereprioritizedastheprojectprogresses,basedonanimprovedunderstandingofcurrentriskexposure.

Section12ProjectProcurementManagement

Inagileenvironments,specificsellersmaybeusedtoextendtheteam.Thiscollaborativeworkingrelationshipcanleadtoasharedriskprocurementmodelwhereboththebuyerandthesellershareintheriskandrewardsassociatedwithaproject.

Largerprojectsmayuseanadaptiveapproachforsomedeliverablesandamorestableapproachforotherparts.Inthesecases,agoverningagreementsuchasamasterservicesagreement(MSA)maybeusedfortheoverallengagement,withtheadaptiveworkbeingplacedinanappendixorsupplement.Thisallowschangestooccurontheadaptivescopewithoutimpactingtheoverallcontract.

Section13ProjectStakeholderManagement

Projectsexperiencingahighdegreeofchangerequireactiveengagementandparticipationwithprojectstakeholders.Tofacilitatetimely,productivediscussionanddecisionmaking,adaptiveteamsengagewithstakeholdersdirectlyratherthangoingthroughlayersofmanagement.Oftentheclient,user,anddeveloperexchangeinformationinadynamicco-creativeprocessthatleadstomorestakeholderinvolvementandhighersatisfaction.Regularinteractionswiththestakeholdercommunitythroughouttheprojectmitigaterisk,buildtrust,andsupportadjustmentsearlierintheprojectcycle,thusreducingcostsandincreasingthelikelihoodofsuccessfortheproject.

Inordertoacceleratethesharingofinformationwithinandacrosstheorganization,agilemethodspromoteaggressivetransparency.Theintentofinvitinganystakeholderstoprojectmeetingsandreviewsorpostingprojectartifactsinpublicspacesistosurfaceasquicklyaspossibleanymisalignment,dependency,orotherissuerelatedtothechangingproject.

ANNEXA2AGILEMANIFESTOMAPPINGThisannexdescribeshowtheelementsoftheAgileManifestoarecoveredin

theAgilePracticeGuide.

TableA2-1.AgileManifestoValuesCoveredintheAgilePracticeGuide

Value AgilePracticeGuideCoveragebySectionandTitle

Individualsandinteractionsoverprocessesandtools

4.2 ServantLeadershipEmpowerstheTeam4.3 TeamComposition5.1 ChartertheProjectandtheTeam5.2.4 DailyStandups6.2 OrganizationalCulture

Workingsoftwareovercomprehensivedocumentation

5.2.2 BacklogPreparation5.2.3 BacklogRefinement5.2.5 Demonstrations/Reviews5.2.7 ExecutionPracticesthatHelpTeamsDeliverValue

Customercollaborationovercontractnegotiation

4.3 TeamComposition5.4 MeasurementsinAgileProjects6.2 OrganizationalCulture6.3 ProcurementandContracts6.7 OrganizationalStructure

Respondingtochangeoverfollowingaplan

5.2.1 Retrospectives5.2.3 BacklogRefinement5.2.5 Demonstrations/Reviews

TableA2-2.AgilePracticeGuideMappingofPrinciplesBehindtheAgileManifesto

Principle AgilePracticeGuideCoverage

Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuousdeliveryofvaluablesoftware.

3.1 CharacteristicsofProjectLifeCycles5.2.7 ExecutionPracticesthatHelpTeamsDeliverValue

Welcomechangingrequirements,evenlateindevelopment.Agileprocessesharnesschangeforthecustomer'scompetitiveadvantage.

5.2.3 BacklogRefinement

Deliverworkingsoftwarefrequently,fromacoupleofweekstoacoupleofmonths,withapreferencetotheshortertimescale.

5.2 CommonAgilePractices

Businesspeopleanddevelopersmustworktogetherdailythroughouttheproject.

4.2 ServantLeadershipEmpowerstheTeam5.2.2 BacklogPreparation5.2.3 BacklogRefinement

Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentandsupporttheyneed,andtrustthemtogetthejobdone.

4.3 TeamComposition5.1 ChartertheProjectandtheTeam5.2.1 Retrospectives

Themostefficientandeffectivemethodofconveyinginformationtoandwithinadevelopmentteamisface-to-faceconversation.

4.3.4 TeamStructures5.2.4 DailyStandups

Workingsoftwareistheprimarymeasureofprogress.

5.2.7 ExecutionPracticesthatHelpTeamsDeliverValue5.2.8 HowIterationsandIncrementsHelpDelivery

WorkingProduct

Agileprocessespromotesustainabledevelopment.Thesponsors,developers,andusersshouldbeabletomaintainaconstantpaceindefinitely.

5.1 ChartertheProjectandtheTeam

Continuousattentiontotechnicalexcellenceandgooddesignenhancesagility.

5.2 CommonAgilePractices

Simplicity–theartofmaximizingtheamountofworknotdoneisessential.

5.2.2 BacklogPreparation5.2.3 BacklogRefinement

Thebestarchitectures,requirements,anddesignsemergefromself-organizingteams.

4.3 TeamComposition

Atregularintervals,theteamreflects

Atregularintervals,theteamreflectsonhowtobecomemoreeffective,thentunesandadjustsitsbehavioraccordingly.

5.2.1 Retrospectives

ANNEXA3OVERVIEWOFAGILEANDLEANFRAMEWORKSThis annex describes some of the commonly used agile approaches. These

approachescanbeusedasisorcombinedtoadapttowhatworksbestforagivenenvironment or situation. It is not necessary to use any of these; an agileapproach can be developed from scratch as long as it adheres to themindset,values,andprinciplesoftheAgileManifesto.Iftheagileprinciplesarefollowedto deliver value at a sustainable pace, and the developed approach promotescollaborationwith the customer, a specific approach is not required.A link tomore information regarding each approach can be found in the Bibliographysectionofthisguide.

A3.1SELECTIONCRITERIAFORTHEAGILEPRACTICEGUIDETherearetoomanyagileapproachesandtechniquestobeexplicitlyincluded

inthispracticeguide.FigureA3-1depictsasampleofagileapproachesbasedontheirdepthofguidanceandbreadthoftheirlifecycles.Thespecificapproachesselectedfordiscussionarepopularexamplesthatare:

Designed forholisticuse.Someagile approaches are centeredonasingle project activity, such as estimation or reflecting. The listedexamples includeonly themoreholisticagile frameworks.Somearemore full-featured thanothers,butallof theselectedapproachesarethoseintendedtoguideabroadsetofprojectactivities.

Formalizedforcommonuse.Someagileframeworksareproprietaryin nature and designed for specific use by a single organization orwithin a single context.The frameworks described inSectionsA3.2throughA3.14focusonthoseintendedforcommonuseinavarietyofcontexts.

Popular in modern use. Some agile frameworks are holisticallydesigned and well formalized, but are simply not commonly beingused in most projects or organizations. The agile frameworksdescribedinthisannexhavebeenadoptedbyasignificantnumberofindustries,asmeasuredbyacollectionofrecentindustrysurveys.

A3.2SCRUMScrum is a single-team process framework used to manage product

development. The framework consists of Scrum roles, events, artifacts, and

rules,andusesaniterativeapproachtodeliverworkingproduct.Scrumisrunontimeboxes of 1month or lesswith consistent durations called sprintswhere apotentiallyreleasableincrementofproductisproduced.TableA3-1listsScrumeventsandartifactsutilizedforprojectexecution.

TheScrumteamconsistsofaproductowner,development team,andscrummaster.

The product owner is responsible for maximizing the value of theproduct.

The development team is a cross-functional, self-organizing teamconsistingofteammemberswhohaveeverythingtheyneedwithintheteamtodeliverworkingproductwithoutdependingonothersoutsideoftheteam.

The scrum master is responsible for ensuring the Scrum process isupheldandworks toensure theScrum teamadheres to thepracticesandrulesaswellascoachestheteamonremovingimpediments.

TableA3-1.ScrumEventsandArtifacts

Events Artifacts

Sprint ProductbacklogSprintplanning SprintbacklogDailyscrum IncrementsSprintreview Sprintretrospective

A3.3EXTREMEPROGRAMMINGeXtreme Programming (XP) is a software development method based on

frequentcycles.Thenameisbasedonthephilosophyofdistillingagivenbestpractice to its purest, simplest form, and applying that practice continuouslythroughouttheproject.

XP is most known for popularizing a holistic set of practices intended toimprove the resultsof softwareprojects.Themethodwas first formalizedasasetoftwelveprimarypractices,butthengraduallyevolvedtoadoptseveralother

corollarypractices.ThesearelistedinTableA3-2.

TableA3-2.ThePracticesofeXtremeProgramming

XPPracticeArea Primary Secondary

Organizational •Sittogether •Realcustomerinvolvement •Wholeteam •Teamcontinuity •Informativeworkspace •Sustainablepace

Technical •Pairprogramming •Sharedcode/collectiveownership •Test-firstprogramming •Documentationfromcodeandtests •Incrementaldesign •Refactoring

Planning •Userstories •Rootcauseanalysis •Weeklycycle •Shrinkingteams •Quarterlycycle •Payperuse •Slack •Negotiatedscopecontract •Dailystandups

Integration •10-minutebuild •Singlecodebase •Continuousintegration •Incrementaldeployment •Test-first •Dailydeployment

This evolutionwas the result of designing and adopting techniques throughthefilterofcorevalues(communication,simplicity,feedback,courage,respect),and informed by key principles (humanity, economics, mutual benefit, self-similarity, improvement, diversity, reflection, flow, opportunity, redundancy,failure,quality,babysteps,acceptedresponsibility).

A3.4KANBANMETHODKanban in leanmanufacturing is a system for scheduling inventory control

and replenishment.Thisprocessof “just-in-time” inventory replenishmentwasoriginallyseeningrocerystoreswhenshelveswererestockedbasedonthegapsin the shelves and not supplier inventory. Inspired by these just-in-timeinventory systems, Taiichi Ohno developed Kanban and it was applied at themainToyotamanufacturingfacilityin1953.

Theword kanban is literally translated as “visual sign” or “card.” Physicalkanbanboardswithcardsenableandpromotethevisualizationandflowofthe

work through the system for everyone to see. This information radiator (largedisplay)ismadeupofcolumnsthatrepresentthestatestheworkneedstoflowthroughinordertogettodone.Thesimplestofboardscouldhavethreecolumns(i.e., todo,doing,anddone),but it isadaptable towhateverstatesaredeemedneededbytheteamutilizingit.

TheKanbanMethodisutilizedandapplicableinmanysettingsandallowsfora continuous flowofwork and value to the customer.TheKanbanMethod isless prescriptive than some agile approaches and thus less disruptive to beginimplementingas it is theoriginal“startwhereyouare”method.OrganizationscanbeginapplyingKanbanMethodswithrelativeeaseandprogresstowardfullyimplementingthemethodifthatiswhattheydeemnecessaryorappropriate.

Unlikemostagileapproaches,theKanbanMethoddoesnotprescribetheuseof timeboxed iterations. Iterationscanbeusedwithin theKanbanMethod,butthe principle of pulling single items through the process continuously andlimiting work in progress to optimize flow should always remain intact. TheKanbanMethodmaybebestusedwhenateamororganizationisinneedofthefollowingconditions:

Flexibility. Teams are typically not bound by timeboxes and willworkonthehighestpriorityiteminthebacklogofwork.

Focusoncontinuousdelivery.Teamsare focusedon flowingworkthrough the system tocompletionandnotbeginningnewworkuntilworkinprogressiscompleted.

Increased productivity and quality. Productivity and quality areincreasedbylimitingworkinprogress.

Increased efficiency. Checking each task for value adding or non-value-addedactivitiesandremovingthenon-valueaddingactivities.

Teammember focus. Limitedwork in progress allows the team tofocusonthecurrentwork.

Variability in the workload.When there is unpredictability in theway thatworkarrives,and itbecomes impossible for teams tomakepredictablecommitments;evenforshortperiodsoftime.

Reductionofwaste.Transparencymakeswastevisible so it canberemoved.

TheKanbanMethod is derived from lean thinking principles. The defining

principlesandthecorepropertiesoftheKanbanMethodarelistedinTableA3-3.

The Kanban Method is a holistic framework for incremental, evolutionaryprocessandsystemschangefororganizations.Themethodusesa“pullsystem”tomove thework through theprocess.When the teamcompletes an item, theteamcanpullanitemintothatstep.

TableA3-3.DefiningPrinciplesandPropertiesoftheKanbanMethod

DefiningPrinciples CoreProperties

StartwithcurrentstateAgree to pursue incremental, evolutionarychangeRespect the current process, roles,responsibilities, and titles Encourage acts ofleadershipatalllevels

VisualizetheworkflowLimitworkinprogressManageflowMakeprocesspoliciesexplicitImplementfeedbackloops

Improvecollaboratively

Kanbanboards,suchastheoneshowninFigureA3-2,arealow-tech,high-touchtechnologythatmayseemoverlysimplisticatfirst,butthoseusingthemsoonrealizetheirpower.Utilizingpoliciesforentryandexittocolumns,aswellas constraints such as limiting work in process, kanban boards provide clearinsight toworkflow, bottlenecks, blockers, and overall status.Additionally theboardactsasaninformationradiatortoanyonewhoseesit,providingup-to-dateinformationonthestatusoftheworkoftheteam.

IntheKanbanMethod,itismoreimportanttocompleteworkthanitistostartnewwork. There is no value derived fromwork that is not completed so theteamworks together to implement and adhere to the work in progress (WIP)limitsandgeteachpieceofworkthroughthesystemto“done.”

A3.5CRYSTALMETHODSCrystal isa familyofmethodologies.Crystalmethodologiesaredesigned to

scale, and provide a selection of methodology rigor based on project size(numberofpeopleinvolvedintheproject)andthecriticalityoftheproject.

CrystalMethodologyrealizesthateachprojectmayrequireaslightlytailoredset of policies, practices, and processes in order to meet the project's uniquecharacteristics. The family of methodologies use different colors based on“weight” todeterminewhichmethodology touse.Theuseof thewordcrystalcomes from thegemstonewhere thevarious “faces” representunderlyingcoreprinciples and values. The faces are a representation of techniques, tools,standards,androleslistedinTableA3-4.

TableA3-4.TheCoreValuesandCommonPropertiesofCrystal

CoreValues CommonPropertiesA

People FrequentdeliveryInteraction ReflectiveimprovementCommunity CloseorosmoticcommunicationSkills PersonalsafetyTalents Focus

Talents FocusCommunications Easyaccesstoexpertusers Technicalenvironmentwithautomatedtests,

configurationmanagement,andfrequentintegration

AThemorethesepropertiesareinaproject,themorelikelyitistosucceed.

A3.6SCRUMBANScrumbanisanagileapproachoriginallydesignedasawaytotransitionfrom

ScrumtoKanban.Asadditionalagileframeworksandmethodologiesemerged,itbecameanevolvinghybridframeworkinandofitselfwhereteamsuseScrumasaframeworkandKanbanforprocessimprovement.

InScrumban,theworkisorganizedintosmall“sprints”andleveragestheuseofkanbanboards tovisualizeandmonitor thework.Thestoriesareplacedonthe kanban board and the team manages its work by using work-in-progresslimits.Dailymeetingsareheld tomaintain thecollaborationbetween the teamand to remove impediments.Aplanning trigger is set inplace for the team toknowwhentoplannext,typicallywhenthework-in-progresslevelislowerthana predetermined limit. There are no predefined roles in Scrumban—the teamretainstheircurrentroles.

A3.7FEATURE-DRIVENDEVELOPMENTFeature-DrivenDevelopment(FDD)wasdevelopedtomeetthespecificneeds

ofalargesoftwaredevelopmentproject.Featuresrelatetoasmallbusinessvaluecapability.

TherearesixprimaryrolesonaFeature-DrivenDevelopmentprojectwhereindividualscantakeononeormoreofthefollowingroles:

Projectmanager,

Chiefarchitect,

Developmentmanager,

Chiefprogrammer,

Classowner,and/or

Domainexpert.

AFeature-DrivenDevelopmentprojectisorganizedaroundfiveprocessesoractivities,whichareperformediteratively:

Developanoverallmodel,

Buildafeatureslist,

Planbyfeature,

Designbyfeature,and

Buildbyfeatures.

The life cycle flow and interaction of these five processes is illustrated inFigureA3-4.

Feature-DrivenDevelopmentactivitiesaresupportedbyacoresetofsoftwareengineeringbestpractices:

Domainobjectmodeling,

Developingbyfeature,

Individualclassownership,

Featureteams,

Inspections,

Configurationmanagement,

Regularbuilds,and

Visibilityofprogressandresults.

A3.8DYNAMICSYSTEMSDEVELOPMENTMETHODDynamicSystemsDevelopmentMethod(DSDM)isanagileprojectdelivery

framework initially designed to add more rigor to existing iterative methodspopularinthe1990s.Itwasdevelopedasanoncommercialcollaborationamongindustryleaders.

DSDM is known best for its emphasis on constraint-driven delivery. Theframeworkwillsetcost,quality,andtimeattheoutset,andthenuseformalizedprioritizationofscopetomeetthoseconstraintsasshowninFigureA3-5.

EightprinciplesguidetheuseoftheDSDMframework:

Focusonthebusinessneed.

Deliverontime.

Collaborate.

Nevercompromisequality.

Buildincrementallyfromfirmfoundations.

Developiteratively.

Communicatecontinuouslyandclearly.

Demonstratecontrol(useappropriatetechniques).

A3.9AGILEUNIFIEDPROCESSTheAgileUnified Process (AgileUP) is an offshoot of theUnified Process

(UP) for software projects. It features more accelerated cycles and lessheavyweight processes than its Unified Process predecessor. The intent is toperformmore iterativecyclesacrosssevenkeydisciplines,and incorporate theassociatedfeedbackbefore formaldelivery.Thedisciplinesalongwithguiding

principlesarelistedinTableA3-5.

TableA3-5.TheKeyElementsoftheAgileUnifiedProcess

DisciplineswithinaRelease PrinciplesGuidingtheDisciplines

Model Theteamknowswhatit'sdoingImplementation SimplicityTest AgilityDeployment Focusonhigh-valueactivitiesConfigurationmanagement ToolindependenceProjectmanagement TailoringtofitEnvironment Situationallyspecific

A3.10SCALINGFRAMEWORKS

A3.10.1SCRUMOFSCRUMSScrum of Scrums (SoS), also known as “meta Scrum,” is a technique used

whentwoormoreScrumteamsconsistingofthreetoninememberseachneedtocoordinatetheirworkinsteadofonelargeScrumteam.Arepresentativefromeach team attends ameetingwith the other team representative(s), potentiallydaily but typically two to three times aweek.The dailymeeting is conductedsimilartothedailystandupinScrumwheretherepresentativereportscompletedwork, next set of work, any current impediments, and potential upcomingimpedimentsthatmightblocktheotherteam(s).Thegoalistoensuretheteamsarecoordinatingworkandremovingimpediments tooptimizetheefficiencyofalltheteams.

LargeprojectswithseveralteamsmayresultinconductingaScrumofScrumof Scrums,which follows the same pattern as SoSwith a representative fromeachSoSreportingintoalargergroupofrepresentativesasshowninFigureA3-6.

A3.11SCALEDAGILEFRAMEWORKThe Scaled Agile Framework (SAFe®) focuses on providing a knowledge

baseofpatternsforscalingdevelopmentworkacrossalllevelsoftheenterprise.

SAFe®isfocusedonthefollowingprinciples:

Takeaneconomicview.

Applysystemsthinking.

Assumevariability;preserveoptions.

Buildincrementallywithfast,integratedlearningcycles.

Basemilestonesonobjectiveevaluationofworkingsystems.

Visualizeandlimitworkinprogress,reducebatchsizes,andmanagequeuelengths.

Applycadence;synchronizewithcross-domainplanning.

Unlocktheintrinsicmotivationofknowledgeworkers.

Decentralizedecisionmaking.

SAFe® focuses on detailing practices, roles, and activities at the portfolio,program,andteamlevelswithanemphasisonorganizingtheenterprisearoundvaluestreamsthatfocusonprovidingcontinuousvaluetothecustomer.

A3.12LARGESCALESCRUM(LeSS)LargeScaleScrum(LeSS)isaframeworkfororganizingseveraldevelopment

teamstowardacommongoalextendingtheScrummethodshowninFigureA3-6.Thecoreorganizingprincipleistoretainasmuchaspossibleoftheelementsof the conventional single-team Scrum model. This helps minimize anyextensionstothemodelthatmightcreateunnecessaryconfusionorcomplexity.TableA3-6showsacomparisonofLeSSandScrum.

TableA3-6.ComparisonofLeSSandScrum

SimilaritiesofLeSSandScrum LeSSTechniquesAddedtoScrum

OnesingleproductbacklogOnedefinitionofdoneforallteamsOnepotentially shippableproduct incrementattheendofeachsprintOneproductownerComplete,cross-functionalteams

Onesprint

Sprint planning is more formally divided intotwopartsofwhatandhowOrganiccross-teamcoordinationOverallcross-teamrefinementOverall retrospective focused on cross-teamimprovements

InordertoextendScrumwithoutlosingitsessence,LeSSpromotestheuseofcertain discerning principles, such as systems thinking, whole product focus,transparency,andothers.

A3.13ENTERPRISESCRUMEnterpriseScrum is a frameworkdesigned to apply theScrummethodon a

more holistic organizational level rather than a single product developmenteffort.Specifically,theframeworkadvisesorganizationleadersto:

ExtendtheuseofScrumacrossallaspectsoftheorganization;

Generalize the Scrum techniques to apply easily at those variousaspects;and

ScaletheScrummethodwithsupplementaltechniquesasnecessary.

The intent is to use agile approaches beyond project execution by enablingdisruptiveinnovation.

A3.14DISCIPLINEDAGILE(DA)DisciplinedAgile(DA)isaprocessdecisionframeworkthatintegratesseveral

agile best practices into a comprehensivemodel. DAwas designed to offer abalancebetweenthosepopularmethodsdeemedtobeeithertoonarrowinfocus(e.g., Scrum) or too prescriptive in detail (e.g., AgileUP). To achieve thatbalance,itblendsvariousagiletechniquesaccordingtothefollowingprinciples:

People-first.Enumeratingrolesandorganizationelementsatvariouslevels.

Learning-oriented.Encouragingcollaborativeimprovement.

Fulldeliverylifecycle.Promotingseveralfit-for-purposelifecycles.

Goal-driven.Tailoringprocessestoachievespecificoutcomes.

Enterprise awareness. Offering guidance on cross-departmentalgovernance.

Scalable.Coveringmultipledimensionsofprogramcomplexity.

APPENDIXX1CONTRIBUTORSANDREVIEWERS

X1.1AGILEPRACTICEGUIDECORECOMMITTEEThe following individuals were members of the project Core Committee

responsiblefordraftingtheguide,includingreviewandadjudicationofreviewerrecommendations.

X1.1.1REPRESENTINGTHEPROJECTMANAGEMENTINSTITUTE:MikeGriffiths,PMP,PMI-ACP,(CommitteeChair)JesseFewell,CST,PMI-ACP

HoriaSlușanschi,PhD,CSMStephenMatola,BA,PMP

X1.1.2REPRESENTINGAGILEALLIANCE:JohannaRothman,MS(CommitteeViceChair)BeckyHartman,PMI-ACP,CSP

BetsyKauffman,ICP-ACC,PMI-ACP

X1.2AGILEPRACTICEGUIDESUBJECTMATTEREXPERTREVIEWERS

The following individualswere invitedsubjectmatterexpertswho reviewedthedraftandprovidedrecommendationsthroughtheSMEReview.

JoeAstolfi,PMP,PSMMariaCristinaBarbero,PMI-ACP,PMPMichelBiedermann,PhD,PMI-ACPZachBonakerRobertBulger,PfMP,CSMSueBurkShikaCarter,PMP,PMI-ACPLaurenClark,PMP,CSMLindaMCook,CSM,CSPOPamelaCorbin-Jones,PMI-ACP,CSMJeffCovertAlbertoDominguez,MSc,PMPScottP.Duncan,CSM,ICP-ACCSallyElatta,PMI-ACP,EBACFrankR.Hendriks,PMP,PMI-ACPDerekHuetherRonJeffriesFredKoosPhilippeB.Kruchten,PhD,PEngSteveMayner,SPCT4,PMPMichaelS.McCalla,PMI-ACP,CSPDonB.McClure,PMP,PMI-ACPAnthonyC.Mersino,PMI-ACP,CSPKennethE.Nidiffer,PhD,PMPMichaelC.Nollet,PMP,PMI-ACPLauraPaton,MBA,PMPYvanPetit,PhD,PMPDwaynePhillips,PhD,PMPPiyushPrakash,PMP,Prince2DavePrior,PMP,CSTDanielRawsthorne,PhD,PMPAnnetteD.Reilly,PMP,PhDStephanReindl,PMI-ACP,PMPReedD.Shell,PMP,CSPCindyShelton,PMP,PMI-ACPTeresaShortLisaK.Sieverts,PMP,PMI-ACPChristopherM.Simonek,PMP,CSM

ChristopherM.Simonek,PMP,CSMRobert“Sellers”Smith,PMP,PMI-ACPRamSrinivasan,PMP,CSTChrisStevens,PhDKarenStrichartz,PMP,PMI-ACPRahulSudame,PMI-ACPJoannaL.Vahlsing,PMPErikL.vanDaalenAnnetteVendelbo,PMP,PMI-ACPDaveViolette,MPM,PMPAntonVishnyak,PMI-ACP,CSMChuckWalrad,MA,MS

X1.3FORMATFOCUSGROUPThe following individuals assisting in thedevelopmentofnewcontent style

andformattingelementsfortheAgilePracticeGuide.

GoranBanjanin,PgMP,PMPAndrewCraigCătălin-TeodorDogaru,PhD,PMPJorgeEspinoza,PMPJenniferM.Forrest,CSM,PMPHelenFotos,PMP,PMI-ACPDaveHatter,PMP,PMI-ACPChristopherHealy,PMPMikeHoffmann,MBA,PMPChadiKahwaji,PMPRajaramanKannan,PMP,MACSCPAmitKhannaPMP,PMI–ACPArielKirshbom,PMI-ACP,CSPBernardoMarques,PMPNouraSaad,PMI-ACP,CSPOKurtSchuler,PMPDemetriusL.Williams,MBA,PMPLizaWoodMelodyYale,CSP,SPC4

X1.4PMISTANDARDSMEMBERADVISORYGROUP(MAG)ThefollowingindividualsaremembersofthePMIStandardsMemberAdvisoryGroup,whoprovideddirectiontoandfinalapprovalonbehalfofPMIfortheAgilePracticeGuide.

MariaCristinaBarbero,PMI-ACP,PMPBrianGrafsgaard,PMP,PgMPHagitLandman,PMP,PMI-SPYvanPetitPhD,PMPChrisStevens,PhDDaveViolette,MPM,PMPJohnZlockie,MBA,PMP,PMIStandardsManager

X1.5AGILEALLIANCE®BOARDThefollowingindividualsaremembersofAgileAllianceBoardofDirectors,

whoprovideddirectiontoandfinalapprovalonbehalfofAgileAlliancefortheAgilePracticeGuide.

JuanBandaPhilBrock(ManagingDirector)LindaCookStephanieDavisEllenGrovePaulHammond(Chair)VictorHugoGermanoRebeccaParsons(Secretary)CraigSmithDeclanWhelan

X1.6PMISUPPORTSTAFFANDACADEMICRESEARCHSUPPORTThe following individuals worked to support the core committee in the

developmentandapprovalof thedraft, in supportof theFormatFocusGroup,andinPMImarketingefforts.

MelissaM.Abel,MarketingCommunicationsSpecialistKarlF.Best,

MelissaM.Abel,MarketingCommunicationsSpecialistKarlF.Best,PMP,CStd,StandardsSpecialistAliciaC.Burke,MBA,CSM,ProductManager,CredentialsEdivandroC.Conforto,PhD,PMIConsultantonAgileResearchDaveGarrett,CSPO,VicePresident,TransformationEricaGrenfell,AdministrativeAssistanttoVP,OrganizationRelationsM.ElaineLazar,MA,MA,AStd,ProjectSpecialistAndrewLevin,PMP,ProjectManagerTimE.Ogline,UserExperienceDesignerStephenA.Townsend,DirectorofNetworkProgramsMichaelZarro,PhD,UXResearcherX1.7PMIPRODUCTIONSTAFFDonnGreenberg,Manager,PublicationsKimShinners,PublicationsProductionAssociateRobertaStorer,ProductEditorBarbaraWalsh,ProductionSupervisor

APPENDIXX2ATTRIBUTESTHATINFLUENCETAILORING

X2.1INTRODUCTIONThisappendixprovideshigh-levelguidanceonwhenandhowto tailoragile

approaches. It can be used to determine circumstances that might warrantchangingorintroducingnewtechniques,andthenofferssomerecommendationstoconsider.

X2.2FIRSTSOMECAUTIONSTailoring is an advanced topic that should be undertaken by experienced

practitioners who have been successful using agile approaches as originallydescribedinmultipleenvironmentsbeforetheyconsidertailoringthem.Inotherwords,gainexperienceandbesuccessfulwithoneapproachbeforeattemptingtotailortheapproach.

The Shu-Ha-Ri model of skills acquisition describes progression fromobeying the rules (Shu守,means toobeyandprotect), throughconsciouslymovingawayfromtherules(Ha破,meanstochangeordigress),andfinallythrough steadypractice and improvement findingan individualpath (Ri離,means to separate or leave).We need to start and practice at the Shu levelbeforewe are ready tomove to theHa level to tailor the process or theRi

leveltoinventanewcustomprocess.

Acommonresponsewhenstrugglingtoadoptanagilepracticeistoconsiderwhethertodoitornot.Astatementlike“Retrospectiveswereunpopularsowedecided to drop them” illustrates this issue and indicates amore fundamentalproblemon the team that is unlikely to be addressed by tailoring themethod.Thesituationwillbemadeworsebyomittingtheretrospectiveactivitythataimstoimprovetheprocess.

Finally,tailoringshouldbeundertakenincollaborationwiththeteammatesorwhoever the change is likely to impact. People need to be engaged in thethinking and decision-making process about changing processes in order forthem to commit and buy-in to the changes in order to have a successfultransition. Omitting people from tailoring a process is likely to result inresistanceandresentmenttothechange,evenifitmakesgoodsensetechnically.Often,experiencedcoachesorleaderscanhelptoengagepeopleeffectively.

X2.3HOWTOUSETHISAPPENDIXTo benefit from the guidance listed in this appendix, we recommend first

successfully using the agile approaches as designed.Then review the tailoringguidelines in Table X2-1 that match the situation and read the associatedrecommendations.Next, discuss the changewith thepeople itwill impact andagreeonacourseofaction.

As discussed inSection 5, a goodway to evaluate a change is try it for aniterationor twofirstbeforeadopting itpermanently.Or,consideraflow-basedapproachtotrytodeliverseveralfeatures.Then,reflectwitharetrospectiveandreassess.

When people know they can experiment and provide feedback on theexperiment, they are more likely to try something new. Having tried it for atimeboxedperiod,theteamshouldreviewitseffectivenessataretrospectivetodetermine whether it should be continued as-is, modified to improve it, ordroppedfromuse.

Finally,successfullyadopted,tailoredapproachescanbeinstitutionalizedintothestandardprocessesusedforprojectsthatsharethesecharacteristics.Itisalso

recommendedthatguidelinesfromSection5befollowedthatdescribeadopting(ortailoring)newapproaches.

X2.4TAILORINGRECOMMENDATIONSListed below are some good practices to consider before tailoring an

approach.

X2.4.1BEWAREOFTAKINGTHINGSAWAYMany of the agile practices act as self-supporting pairs. For instance,

colocation and frequent business conversations allow for lightweightrequirementssincegaps inunderstandingcanbefilledquickly.Likewise,XP'sruthless testing allows for courageous refactoring as one practice supports theother. Removing something without understanding or addressing itscounterbalancedpracticewilllikelycreatemoreproblemsthanitsolves.

X2.4.2USETHETAILORINGGUIDELINESTABLEUsing Table X2-1, find the circumstances that match a given situation and

consider recommendations for tailoring. Discuss any changes with those whowillbeimpactedbythechangeandplanashorttrialfirst,alongwithanhonestfollow-upreviewbeforecommittingtothechange.

TableX2-1.TailoringGuidelines

Situation TailoringRecommendation

Verylargeprojectteams Restructurelargeprojectsasmultiplesmallerprojects.Tryatechnologytrialprojectfirstandthenanimplementationproject.

Considermorefrequentreleasesoffewerfeatureseach,whichallowsforthecreationofsmallerprojectteams.

Considerreducingtheteamdowntoitscriticalcoremembers.Oftentoomanypeoplehinderaprocess,nothelpit.Reducingateamsizecanreducechurnaswellascosts.

Breaklargeteamsintomultiplesmallerteamsanduseprogrammanagementtosynchronizeandcoordinate.

Useagileandleanprogrammanagementtoorganizethe

Useagileandleanprogrammanagementtoorganizethelargereffort.

ConsiderascaledagileorleanframeworksuchasDA,SAFe®,orLeSS.Eachofferssomeusefulideas,andeachcarriesimplementationrisksandprocessweight/cost.

Dispersedteams Manyprojectshave(some)dispersedteammembers.Toolslikeinstantmessaging,videoconferencing,andelectronicteamboardshelpbridgemanyofthecommunicationgaps.

Whenteamsarelikelytoremainstable,setupface-to-facemeetingsassoonaspossibletomakefutureremoteconversationsmoreeffective.Peoplewhohavemetface-to-facearemorelikelytoenterunfiltereddebatebecauseofhighertrust.

Whenconductingmeetingswithremoteparticipantswherethereisalossoffacialandbody-languagecues,considerround-robincheck-instoensureparticipationandcheckconsensusfordecisions.

Also,considertheuseofiteration-basedagileapproaches.Whenteammembersaremanytimezonesapart,considerusingwhole-projectinteractionslessfrequently,whileencouragingmorepersonalmeetings(twoorthreepeopleatatime)morefrequently.

Somesafetycriticalproductsmayrequireadditionaldocumentationandconformancechecksbeyondwhatagileprocessessuggestout-of-the-box

Agileapproachescanstillbeusedintheseenvironments,buttheyneedtohavetheappropriateadditionallayersofconformancereview,documentation,andcertificationthatisrequiredbythedomain.Inthatcase,documentationcouldbepartofwhattheteamdeliversalongwithfinishedfeatures.Featuresmaynotbedoneuntilthedocumentationiscompleted.

Considerusingahybridapproach(multipleagileapproaches)togetthebenefitsofimprovedcollaborationandcommunicationbroughtbyagilewiththeaddedrigorrequiredbytheproductenvironment.Aircraftflightsystemdevelopersanddrugcompaniesuseagileapproachescoupledwiththeirownadditionalprocessestoleveragethebenefitsandretainappropriatecontrols.

Stablerequirementsandexecutionprocess

Isagilereallyneeded?Ifuncertaintyinrequirementsislow,lowratesofchange,orminimalexecutionrisk,thefullsuiteofagileapproachesmaynotbeneeded.Whileanyprojectbenefitsfromincreasedcollaborationandtransparency;someoftheiterativebuildandreviewcyclesmightbeoverkill.

Ifbuild/feedbackcyclesdonotroutinelyuncoverorrefinerequirements,considerextendingtheirdurationstominimizethecostimpactofreviewtime.

minimizethecostimpactofreviewtime.

Iftheprojecthashighratesofchangeduringdesignanddevelopment,butrollingitouttocustomersisadefinedandrepeatableprocess,hybridapproachesthatusetheappropriatelifecyclemodelforeachprojectphasemaymakemoresense.

Teamsareinfunctionalsilosinsidefunctionalorganizations

Agileisbuiltontheideaofcross-functionalteams.Consideraskingpeopletocreatecross-functionalteamsthemselves,withoutmanagementinvolvementandseewhathappens.

Ifthecompensationsystemisorganizedtorecognizeandrewardfunctionalareas,considerchangingthatfirst.Peoplemightnotactintheinterestoftheproductortheteamuntilitaffectstheircompensationinsomeway.

Transparencycancausefear Agilecreatesacultureoftransparency:peopleshowandsharetheirworkthroughoutdevelopment.Thissharingofinterimdeliverablesandbeingopenandhonestaboutsuccesses,failures,andcurrentstateistransparency.Transparencyrequirescourage.

Leadbyexampleanddemonstratetransparencyindecision-makingprocessesbyusingastatusboardorwhiteboard.

Manyoftheteammembershavelittletechnicaldomainknowledge

Agileapproachesencourageandmakeuseofself-directingteamstomakelocaldecisionsaboutworkitems,suchastasksequencingandwhichapproachtousewhensolvingaproblem.Whenthemajorityofteammembersareinexperienced,consensus-basedapproachesmayleadtoproblemsandrework.So,fortheseteams,additionalhelp“assigning”and“directing”maybenecessaryuntiltheteamgainsthenecessaryskills.Inotherwords,donotjustdeclarethatagilewillbeusedandletaninexperiencedteamtrytofigureeverythingoutbecausetheyareempoweredandself-directing.Considerbuildingcentersofcompetenciestohelpprovideguidanceandbuilddomainknowledge.

Lackofexecutivebuy-in Whenexecutivebuy-inismissing,teamswillencounteraclashbetweentheagilemindsetandapproachesandthemorepredictivemindsetandapproaches.

Findcommonground,areasforimprovementbasedontheorganization'sneeds,andthenuseexperimentsandretrospectivestoprogress.

Considereducation/trainingforexecutives.Considerexplainingagileintermsofleanthinking:shortcycles,smallbatchsizes,frequentreviews,andretrospectiveswithsmallimprovements.

Agiletermsandlanguagedonotfitthe Modifythetermssopeoplewillunderstandandagreetothe

Agiletermsandlanguagedonotfittheorganizationalculture

Modifythetermssopeoplewillunderstandandagreetotheactivities,ifnottheagilelanguage.Bespecificaboutwhateachtermmeans.

Forexample,Iftheorganizationfindstheword“game”unprofessional,don'tusetermssuchas“planninggame.”Instead,considerusingtheterm“planningworkshop.”

APPENDIXX3AGILESUITABILITYFILTERTOOLS

X3.1INTRODUCTIONAgileliteraturecontainsmanyagilesuitabilityfiltertoolstohelpassessunder

what circumstances an agile approach is appropriate to use. In 1994, theDynamic Systems DevelopmentMethod (DSDM) developed an Agile ProjectSuitabilityQuestionnaireandanOrganizationalSuitabilityQuestionnairetohelpgaugelikelyfitandpotentialproblemareas.

TheCrystal family of approaches also employed suitability criteria, rankingprojects by team size and the criticality of the product or service beingdeveloped.Crystalrecommendsthatsmaller,lesscriticalprojectsbeundertakenwith lighter controls and simpler approaches. Large, mission or life criticalprojectswererecommendedtousemorerigorandvalidation.

Since the development of these approaches, there have been many moremodelscreatedtohelpdeterminewhereandwhentoemployagileapproaches.Boehm andTurner adopted some of the elements fromDSDMandCrystal todevelop a popular assessment model to help determine if projects should beundertakenwithagileormoretraditionalapproaches.

Basedonthesepreviousmodelsandexpandedtoconsiderthemiddlegroundofhybridapproaches,thefollowingmodelisproposed.Itrepresentsasynthesisof several suitability filter attributes to help organizations assess and discusswhether projects should be undertaken using predictive, hybrid, or agileapproaches.

X3.2OVERVIEWOFTHEMODEL

X3.2OVERVIEWOFTHEMODELOrganizationalandprojectattributesareassessedunderthreemaincategories:

Culture. Is there a supportive environment with buy-in for theapproachandtrustintheteam?

Team.Istheteamofasuitablesizetobesuccessfulinadoptingagile,doitsmembershavethenecessaryexperienceandaccesstobusinessrepresentativestobesuccessful?

Project. Are there high rates of change? Is incremental deliverypossible?Howcriticalistheproject?

Questionsineachofthesecategoriesareansweredandtheresultsplottedonaradarchart.Clustersofvaluesaroundthecenterofthechartindicateagoodfitforagileapproaches.Resultsaround theoutside indicateapredictiveapproachmay be more suitable. Values in the middle portion (between agile andpredictive)indicateahybridapproachcouldworkwell.AnexampleisshowninFigureX3-1.

X3.3INSTRUCTIONSFORUSE

X3.3.1COMPLETETHEQUESTIONNAIREASAGROUPForsmallprojects,thisgroupmaysimplybethesponsor,technicallead,anda

customer. For large projects, this may include representatives from thesponsoring group, project execution team, impacted business group(s), projectgovernancegroup(s),andcustomercommunity.Theideaisthatjustasnosinglestakeholder shouldestimateorplanaprojectbecauseof representingonlyone

viewpoint andhavingpersonal bias; so too shouldno single person assess thesuitability of an approach since any one personwill also have a limited viewwithabias.

Instead, the value of the tool is the conversation it encourages with theinvestedpartiesoftheproject.Eveniftheresultspointtoahybridapproach,butthe stakeholders want to proceed with a largely agile or predictive approach,follow thestakeholderconsensus.This tool isahigh-leveldiagnosticonly, thefinaldecisionshouldrestandbesupportedbythepeopleinvolved.

X3.3.2SCORETHEQUESTIONSFROM1TO10Asagroup,discussandagree(orcompromise)onascorethatmostaccurately

reflects the subjective evaluation of the question.While definitive options areonly provided for the start, middle, and end points of the answer spectrumrepresentingscoresof1,5,and10,itisfine(anddesirable)tousescoressuchas2for“almosta1,butnotquite,”or7 for“somewherebetweena5anda10.”Again,theassessmentisadiscussiontool—viewswillbesubjectiveandshadesofgrayaretobeexpected.

When the group cannot agree on a score, discuss the issues openly andhonestly.Beforesuggestingcompromises(i.e.,usingaveragescoresormarkingPMO scores with a blue “X” and the development team with a green “O”),considerhowsuccessfulistheprojectlikelytobewhentheparticipantscannotagree on completing a simple assessment?When discussing the issues, if thedifferencesofopinioncanbeidentified—thengreat,itisworking;nowcometoan agreement. Likewise, if the assessment indicates a predictive approach buteveryone wants to try an agile approach (or vice versa) that is fine too, justunderstand the issues and discuss how the impacts of the approach will behandled.

X3.3.3INTERPRETTHERESULTSMark theanswers fromthequestionsonablanksuitabilityassessmentchart

and connect the points. Results clustered around the center in the agile zoneindicateagoodfitforapurelyagileapproach.

Resultspredominantlyinthehybridzoneindicatesomecombinationofagileandpredictiveapproachesmightworkbest.However,itisalsopossiblethatan

agileapproachwithsomeadditionalriskreductionstepssuchasextraeducationand training or extra validation and documentation rigor in the case of highcriticalityprojectsmay suffice.Alternatively, apredictive approachwith someproof-of-conceptworkorextraprocessescouldalsowork.

Resultspredominantly in thepredictivezone indicateagoodfit forapurelypredictiveapproach.AsmentionedinSectionX3.3.2(ScoretheQuestionsstep),this diagnostic tool is aimed at starting meaningful conversations with theimpacted parties about the most appropriate approach to use. If the approachsuggestedbythetoolisnotacceptableitisallowedtouseadifferentapproach.Usetheresultsasinputstotheriskmanagementprocess,sincethetoolindicatesmismatchesthatwillneedtobemanaged.

X3.4SUITABILITYFILTERQUESTIONS

X3.4.1CATEGORY:CULTURE

X3.4.1.1BUY-INTOAPPROACHIsthereseniorsponsorunderstandingandsupportforusinganagileapproach

forthisproject?SeeFigureX3-2.

X3.4.1.2TRUSTINTEAMConsidering the sponsors and the business representatives who will be

workingwiththeteam.Dothesestakeholdershaveconfidencethattheteamcan

transform their vision and needs into a successful product or service—withongoingsupportandfeedbackgoingbothdirections?SeeFigureX3-3.

X3.4.1.3DECISION-MAKINGPOWERSOFTEAMWilltheteambegivenautonomytomaketheirownlocaldecisionsabouthow

toundertakework?SeeFigureX3-4.

X3.4.2CATEGORY:TEAM

X3.4.2.1TEAMSIZEWhatisthesizeofthecoreteam?Usethisscale:1-9=1,10-20=2,21-30=

3,31-45=4,46-60=5,61-80=6,81-110=7,111-150=8,151–200=9,201+=10.SeeFigureX3-5.

X3.4.2.2EXPERIENCELEVELSConsideringtheexperienceandskilllevelsofthecoreteamroles.Whileitis

normaltohaveamixofexperiencedandinexperiencedpeopleinroles,foragileprojectstogosmoothly;itiseasierwheneachrolehasatleastoneexperiencedmember.SeeFigureX3-6.

X3.4.2.3ACCESSTOTHECUSTOMER/BUSINESSWill the team have daily access to at least one business/customer

representativetoaskquestionsandgetfeedback?SeeFigureX3-7.

X3.4.3CATEGORY:PROJECT

X3.4.3.1LIKELIHOODOFCHANGEWhatpercentageof requirementsare likely tochangeorbediscoveredona

monthlybasis?SeeFigureX3-8.

X3.4.3.2CRITICALITYOFPRODUCTORSERVICETohelpdetermine likely levelsofadditionalverificationanddocumentation

rigorthatmayberequired,assessthecriticalityoftheproductorservicebeingbuilt.Usinganassessmentthatconsiderslossduetopossibleimpactofdefects,determinewhatafailurecouldresultin.SeeFigureX3-9.

X3.4.3.3INCREMENTALDELIVERYCan the product or service be built and evaluated in portions? Also, will

businessorcustomerrepresentativesbeavailabletoprovidetimelyfeedbackonincrementsdelivered?SeeFigureX3-10.

X3.5SUITABILITYASSESSMENTCHARTFigureX3-11istheradarchartusedforthesuitabilityassessment.

X3.5.1CASESTUDIESTo illustratehow the radar chartworks,here are twoexamplesofusing the

model to score very different types of projects. The first is an example of anonlinedrugstoreproject(seeFigureX3-12)andthesecond(FigureX3-13)isanexampleofamilitarymessagingsystem.Thesetwocasestudiesillustratesomeofthevariancesseenonprojects.Centralclusteringindicatesagoodfitforagileapproaches, peripheral scores indicate predictive approaches might be moresuitable.Someprojectsarecenteredaroundthemiddlebutthenspikeoutononeortwoaxes.Theseprojectsmaybebestsolvedwithahybridapproach.

X3.5.1.1DRUGSTOREEXAMPLEThe project was to develop an online drug store to sell cheaper Canadian

prescription drugs to (primarily) U.S. customers. The sale of these drugs is acontentioussubjectinCanadaaswellastheU.S.andasaresulttheindustryischaracterized by swift regulation changes and fierce competition. The projectfacedextremelyvolatilerequirementswithmajorchangesweekonweek.Itusedvery short (2-day) iterations and weekly releases to tackle the high rates ofchange.

As shown in Figure X3-12, high levels of buy-in and trust are evident forthosewhoworkedinanempoweredway.Thevisualnatureofthewebsitemadeit easy to shownew incrementsof functionality,but the systemcriticalitywas

fairlyhighwithessential fundsfor thepharmacyatstake.Asmentioned, therewere very high rates of change, but the small experienced teamhandled themwell and had easy access to a knowledgeable business representative. Theapproachwasverysuccessfulandextremelyagile.

X3.5.1.2MILITARYMESSAGINGSYSTEMEXAMPLEContrastthefirstexamplewithalargeprojecttodevelopmilitarymessaging

systemthathadalreadybeenrunningfor5yearswhentheassessmentwasmade.SeeFigureX3-13.

Buy-inforanagileapproachwaslackingbecauseanagileapproachwasnot

being considered. Trust in the vendors was mixed but generally respected.Decision making was not local, but instead made by architecture andrequirements committees. While elements of the design could be testedincrementallyinalaboratory,theycouldnotbegatheredtogetherforanendtoend demonstration of functionality. Many lives were potentially at risk, socriticality was very high. Requirements were locked down because changesimpactedsomanysubcontractororganizations.

Theprojectwaslargewithmorethan300peoplefromonevendoralone,buteach role had many experienced practitioners. Finally, access to thebusiness/customerwasnotpossible,butcontractanalystswereavailable toaskspecificationquestionstoandtheyusuallyrepliedoraskedclarifyingquestionswithin10days.Partsoftheprojectcouldhavebeencarvedoffandrunasagileprojects,butattheheartoftheinitiativewasasinglelargeproject.

X3.6SUMMARYAgilesuitabilityfiltersareuseful toolsfor identifyingpotentialfitsandgaps

for agile approaches. They should not be used as definitive inclusion orexclusiongates,butinsteadastopicsforobjectivediscussionwithallinterestedparties.

REFERENCES

[1] Manifesto for Agile Software Development. (2001). Retrieved fromhttp://agilemanifesto.org/

[2] ProjectManagementInstitute.2013.ManagingChangeinOrganizations:APracticeGuide.NewtownSquare,PA:Author.

[3] ProjectManagementInstitute.2017.AGuidetotheProjectManagementBodyofKnowledge(PMBOK®Guide)–SixthEdition.NewtownSquare,PA:Author.

[4] ProjectManagementInstitute.2013.SoftwareExtensiontothePMBOK®GuideFifthEdition.NewtownSquare,PA:Author.

BIBLIOGRAPHY

The following are suggested additional reading materials, subdivided bysectionand/ortopic:

SECTION2—ANINTRODUCTIONTOAGILEBriggs,Sara.“AgileBasedLearning:WhatIsItandHowCanItChangeEducation?” Opencolleges.edu.au February 22, 2014, retrieved fromhttp://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/.

Manifesto for Agile Software Development, 2001,http://agilemanifesto.org/.

Peha,Steve.“AgileSchools:HowTechnologySavesEducation(JustNottheWayWeThought itWould).” InfoQ. June 28, 2011, retrieved fromhttps://www.infoq.com/articles/agile-schools-education.

Principles behind the Agile Manifesto, 2001,http://agilemanifesto.org/principles.html.

Rothman, Johanna.2007.Manage It!YourGuide toModern,PragmaticProjectManagement.Raleigh:PragmaticBookshelf.

Sidky, Ahmed (Keynote). 2015.https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz.

Stacey Complexity Model. 2016. http://www.scrum-tips.com/2016/02/17/stacey-complexity-model/.

SECTION3—LIFECYCLESELECTION“AgileModeling(AM)HomePage:EffectivePracticesforModelingandDocumentation,”AgileModeling,(n.d.),http://www.agilemodeling.com/

Anderson, David, and Andy Carmichael. 2016. Essential KanbanCondensed.Seattle:BlueHolePress.

Anderson, David. 2010. Kanban: Successful Evolutionary Change forYourTechnologyBusiness.Seattle:BlueHolePress.

Benson, Jim, and Tonianne DeMaria Barry. 2011. Personal Kanban:MappingWork|NavigatingLife.Seattle:ModusCooperandiPress.

Burrows,Mike. 2014.Kanban from the Inside:Understand theKanbanMethod, connect it to what you already know, introduce it with impact.Seattle:BlueHolePress.

DomainDrivenDesignCommunity.2016.http://dddcommunity.org/.

Gothelf,Jeff,andJoshSeiden.2016.LeanUX:DesigningGreatProductswithAgileTeams.Sebastopol:O'ReillyMedia.

Hammarberg, Marcus, and Joakim Sunden. 2014. Kanban in Action.ShelterIsland:ManningPublications.

“Kanban,”Wikipedia,lastmodifiedMay4,2017,retrievedonNovember22,2016fromhttps://en.wikipedia.org/wiki/Kanban.

“Kanban(development),”Wikipedia,lastmodifiedMay4,2017,retrievedon November 29, 2016 fromhttps://en.wikipedia.org/wiki/Kanban_(development).

Larsen, Diana, and Ainsley Nies. 2016. Liftoff: Start and SustainSuccessfulAgileTeams.Raleigh:PragmaticBookshelf.

“Learning Kanban,” Leankit, (n.d.), https://leankit.com/learn/learning-kanban/.

Leopold, Klaus, and Siegrfried Kaltenecker. 2015. Kanban ChangeLeadership: Creating a Culture of Continuous Improvement. Hoboken:Wiley.

“Make a big impact with software products and projects!” ImpactMapping,(n.d.),https://www.impactmapping.org/.

Patton,Jeff,andPeterEconomy.2014.UserStoryMapping:DiscovertheWholeStory,BuildtheRightProduct.Sebastopol:O'ReillyMedia.

Reinertsen,Donald.2009.ThePrinciplesofProductDevelopmentFlow:SecondGenerationLeanProductDevelopment.RedondoBeach:CeleritasPublishing.

Rothman, Johanna. “Dispersed vs. Distributed Teams,” Rothman

Consulting Group, Inc., October 25, 2010,http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Schwaber,Ken, and Jeff Sutherland. “The ScrumGuide™,” Scrum.org,July 2016, http://www.scrumguides.org/scrumguide.html andhttp://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Skarin,Mattias. 2015.Real-World Kanban: Do Less, AccomplishMorewithLeanThinking.Raleigh:PragmaticBookshelf.

“The High Cost of Multitasking: 40% of Productivity Lost by TaskSwitching,” Wrike.com, September 24, 2015,https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

Wells, Don. “Extreme Programming: A Gentle Introduction,” ExtremeProgramming,October8,2013,http://www.extremeprogramming.org/.

SECTION4—IMPLEMENTINGAGILE:Amabile, Teresa, and Steven Kramer. 2011. The Progress Principle:Using Small Wins to Ignite Joy, Engagement, and Creativity at Work.Boston:HarvardBusinessReviewPress.

“Early Warning Signs of Project Trouble—Cheat Sheet, 2017,https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf.

Dweck, Carol. 2006. Mindset: The New Psychology of Success. NewYork:PenguinRandomHouse.

Kaner,Sam.Facilitator'sGuidetoParticipatoryDecision-Making.3rded.2014.SanFrancisco:Jossey-Bass.

Keith,Kent.TheCaseforServantLeadership.2008.Westfield:GreenleafCenterforServantLeadership.

Rothman,Johanna.2016.AgileandLeanProgramManagement:ScalingCollaboration Across the Organization. Victoria, British Columbia:PracticalInk.

Rothman, Johanna. “Dispersed vs. Distributed Teams,” RothmanConsulting Group, Inc., October 25, 2010,

http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Rothman, Johanna.2007.Manage It!YourGuide toModern,PragmaticProjectManagement.Raleigh:PragmaticBookshelf.

Rothman,Johanna.2016.ManageYourProjectPortfolio: IncreaseYourCapacityandFinishMoreProjects.Raleigh:PragmaticBookshelf.

Schwaber,Ken, and Jeff Sutherland. “The ScrumGuide™,” Scrum.org,July 2016, http://www.scrumguides.org/scrumguide.html andhttp://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Sinek,Simon.2011.StartwithWhy:HowGreatLeadersInspireEveryonetoTakeAction.NewYork:Portfolio,PenguinRandomHouse.

“The High Cost of Multitasking: 40% of Productivity Lost by TaskSwitching,” Wrike.com, September 24, 2015,https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

EXPERIENCEREPORTS:

“Experience Reports,” Agile Alliance, (n.d.),https://www.agilealliance.org/resources/experience-reports/.

PROJECTANDTEAMHEALTH:

“Early Warning Signs of Project Trouble—Cheat Sheet.” 2017.https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf

“TeamHealth Radar – Summary View,” Agilehealth. 2014.http://agilityhealthradar.com/wp-content/uploads/2014/11/bigradar.gif.

RESOURCEEFFICIENCY:

Modig, Niklas, and Pär Åhlström. 2015. This is Lean: Resolving theEfficiencyParadox.London:RheologicaPublishing.

Rothman,Johanna.“ResourceEfficiencyvs.FlowEfficiency,Part5:HowFlowChangesEverything,”RothmanConsultingGroup, Inc.,September20, 2015, http://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-5-how-flow-changes-everything/.

SCALING:

Disciplined Agile 2.X—A Process Decision Framework. 2016.http://www.disciplinedagiledelivery.com/.

Kniberg,Henrik.“ScalingAgile@SpotifywithTribes,Squads,Chapters& Guilds,” Crisp, November 14, 2012,http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.

“Overview—LargeScaleScrum,”LeSS.2016.http://less.works/.

“SAFe® for Lean Software and System Engineering,” SAFe®. 2016.http://www.scaledagileframework.com/.

SKILLS:

Beck, Kent. Paint Drip People, August 4, 2016,https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/.

“Generalizing Specialists: Improving Your IT Career Skills,” AgileModeling, (n.d.),http://www.agilemodeling.com/essays/generalizingSpecialists.htm.

Hunter, Brittany. “Of Software Designers & Broken Combs,” AtomicObject, June 27, 2013, https://spin.atomicobject.com/2013/06/27/broken-comb-people/.

SECTION5—IMPLEMENTINGAGILE:DELIVERINGINANAGILEENVIRONMENT

Larsen, Diana, and Ainsley Nies. 2016. Liftoff: Start and SustainSuccessfulAgileTeams.Raleigh:PragmaticBookshelf.

RETROSPECTIVES:

Derby, Esther, and Diana Larsen. 2006. Agile Retrospectives: MakingGoodTeamsGreat.Raleigh:PragmaticBookshelf.

Gonçalves, Luis, and Ben Linders. 2015. Getting Value out of AgileRetrospectives: A Toolbox of Retrospective Exercises. Victoria, British

Columbia:Leanpub.

BACKLOG:

Adzic, Gojko, Marjory Bissett, and Tom Poppendieck. 2012. ImpactMapping: Making a Big Impact with Software Products and Projects.Woking,Surrey:ProvokingThoughts.

Patton,Jeff,andPeterEconomy.2014.UserStoryMapping:DiscovertheWholeStory,BuildtheRightProduct.Sebastopol:O'ReillyMedia.

Rothman, Johanna. “We Need Planning; Do We Need Estimation?”Rothman Consulting Group, Inc., January 21, 2015,http://www.jrothman.com/mpd/project-management/2015/01/we-need-planning-do-we-need-estimation/.

STANDUPS:

Brodzinski, Pawel. “Effective Standups around Kanban Board,”Brodzinski.com, December 30, 2011,http://brodzinski.com/2011/12/effective-standups.html.

Fowler, Martin. “It's Not Just Standing Up: Patterns for Daily StandupMeetings,” Martinfowler.com, February 21, 2016,http://martinfowler.com/articles/itsNotJustStandingUp.html.

Hefley, Chris. “How to Run Effective Standups and Retrospectives,”Leankit, September 15, 2014, https://leankit.com/blog/2014/09/run-effective-standups-retrospectives/.

EARNEDVALUE:

Griffiths, Mike. “A Better S Curve and Simplified EVM,” LeadingAnswers, June 6, 2008,http://leadinganswers.typepad.com/leading_answers/2008/06/a-better-s-curve-and-simplified-evm.html.

SECTION6—ORGANIZATIONALCONSIDERATIONSFORAGILEPROJECTS

Bankston, Arlen, and Sanjiv Augustine. Agile Team PerformanceManagement: Realizing the Human Potential of Teams, June 14, 2010,www.lithespeed.com/transfer/Agile-Performance-Management.pptx.

Browder, Justin, and Brian Schoeff. Perfect Strangers: How ProjectManagersandDevelopersRelateandSucceed.CreateSpaceIndependentPublishingPlatform,2016,https://www.createspace.com/.

Griffiths,Mike. “AgileTalentManagement,”LeadingAnswers,October14, 2015,http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html.

Kohn,Alfie. 1999.PunishedbyRewards:TheTroublewithGold Stars,IncentivePlans,A's,Praise,andOtherBribes.NewYork:MarinerBooks.

Mar,Kane.“HowtodoAgilePerformanceReviews,”Scrumology,(n.d.),https://scrumology.com/how-to-do-agile-performance-reviews/.

McChrystal,Stanley,TantumCollins,DavidSilverman,andChrisFussell.2015.TeamofTeams:NewRulesofEngagement foraComplexWorld.NewYork:Portfolio,PenguinRandomHouse.

Pink, Daniel. 2011.Drive: The Surprising Truth AboutWhatMotivatesUs.NewYork:RiverheadBooks.

SECTION7—ACALLTOACTION(INSPECTIONWITHOUTADAPTATIONISFUTILE)

Dennis,Pascal.2006.GettingtheRightThingsDone:ALeader'sGuidetoPlanningandExecution.Cambridge:LeanEnterpriseInstitute.

Griffiths,Mike.“IntroducingAgileMethods:MistakestoAvoid—Part3,”Leading Answers, March 15, 2007,http://leadinganswers.typepad.com/leading_answers/2007/03/introducing_agi_2.html

Little, Jason. Lean Change Management: Innovative Practices forManaging Organizational Change. Happy Melly Express, 2014,http://www.happymelly.com/category/hm-express/.

Rising,Linda,andMaryLynneManns.2004.FearlessChange:Patternsfor Introducing New Ideas. Upper Saddle River: Addison-Wesley

Professional.

“The IDEALModel,” Software Engineering Institute,CarnegieMellon,2006,http://www.sei.cmu.edu/library/assets/idealmodel.pdf.

ANNEXA1—PMBOK®GUIDEMAPPINGLarsen, Diana and Ainsley Nies. 2016. Liftoff: Start and SustainSuccessfulAgileTeams.Raleigh:PragmaticBookshelf.

ANNEXA2—AGILEMANIFESTOMAPPINGManifesto for Agile Software Development, 2001,http://agilemanifesto.org/.

Principles behind the Agile Manifesto, 2001,http://agilemanifesto.org/principles.html.

ANNEXA3—OVERVIEWOFAGILEANDLEANFRAMEWORKS

AgileBusinessConsortium,2014,https://www.agilebusiness.org/what-is-dsdm.

Ambler, Scott. “The Agile Unified Process,” Ambysoft, May 13, 2006,http://www.ambysoft.com/unifiedprocess/agileUP.html.

Anderson, David. 2010. Kanban: Successful Evolutionary Change forYourTechnologyBusiness.Seattle:BlueHolePress.

Beedle,Mike.EnterpriseScrum:ExecutiveSummary:BusinessAgilityforthe 21st Century, January 7, 2017,http://www.enterprisescrum.com/enterprisescrum/.

Cockburn,Alistair.2004.CrystalClear:AHuman-PoweredMethodologyforSmallTeams.UpperSaddleRiver:PearsonEducation.

Cockburn,Alistair.“CrystalMethodologies,”alistair.cockburn.us,March28,2014,http://alistair.cockburn.us/Crystal+methodologies.

Disciplined Agile 2.X—A Process Decision Framework, 2016,http://www.disciplinedagiledelivery.com/.

Joint MIT-PMI-INCOSE Community of Practice on Lean in ProgramManagement. 2012. The Guide to Lean Enablers for ManagingEngineeringPrograms.NewtownSquare,PA:Author.

“Kanban,”Wikipedia,lastmodifiedMay4,2017,retrievedonNovember22,2016fromhttps://en.wikipedia.org/wiki/Kanban.

“Kanban(development),”Wikipedia,lastmodifiedMay4,2017,retrievedon November 29, 2016 fromhttps://en.wikipedia.org/wiki/Kanban_(development).

Reddy, Ajay, and Jack Speranza. 2015. The Scrumban [R]Evolution:Getting the Most Out of Agile, Scrum, and Lean Kanban. Boston:Addison-WesleyProfessional.

“Overview—LargeScaleScrum,”LeSS,2016,http://less.works/.

“SAFe® for Lean Software and System Engineering,” SAFe®, 2016,http://www.scaledagileframework.com/.

Schwaber,Ken, and Jeff Sutherland. “The ScrumGuide™,” Scrum.org,July 2016, http://www.scrumguides.org/scrumguide.html andhttp://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

“Scrum of Scrums,” Agile Alliance, (n.d.),https://www.agilealliance.org/glossary/scrum-of-scrums/.

“Scrumban,” Wikipedia, March 2, 2017,https://en.wikipedia.org/wiki/Scrumban.

“State of Agile Report: Agile Trends,” VersionOne, 2017,http://stateofagile.versionone.com/.

SutherlandJeff.“AgileCanScale:InventingandReinventingSCRUMinFive Companies.” Cutter IT Journal 14, no. 12 (2001): 5–11.http://www.controlchaos.com/storage/scrum-articles/Sutherland200111proof.pdf.

“The 2015 State of Agile Development,” Scrum Alliance®, 2015,https://www.forrester.com/report/The+2015+State+Of+Agile+Development/-/E-RES122910

Wells, Don. “Extreme Programming: A Gentle Introduction,” ExtremeProgramming,October8,2013,http://www.extremeprogramming.org/.

Why Scrum? State of Scrum Report, 2016,https://www.scrumalliance.org/why-scrum/stateof-scrum-report/2016-state-of-scrum.

APPENDIXX2—ATTRIBUTESTHATINFLUENCETAILORING

Griffiths, Mike. “Agile Suitability Filters,” Leading Answers, 2007,http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf

Jeffries, Ron. “We Tried Baseball and It Didn'tWork,” ronjeffries.com,May2,2006,http://ronjeffries.com/xprog/articles/jatbaseball/.

Rothman, Johanna. “One Experimental Possibility: Self-OrganizationfromComponentTeamstoFeatureTeams,”RothmanConsultingGroup,Inc., September 23, 2014,http://www.jrothman.com/mpd/agile/2014/09/one-experimental-possibility-self-organization-from-component-teams-to-feature-teams/.

GLOSSARY

1.ACRONYMS

ATDD acceptancetest-drivendevelopment

BDD behavior-drivendevelopment

BRD businessrequirementdocuments

DA DisciplinedAgile

DoD definitionofdone

DoR definitionofready

DSDM DynamicSystemsDevelopmentMethod

Evo evolutionaryvaluedelivery

LeSS Large-ScaleScrum

LSD LeanSoftwareDevelopment

PDCA Plan-Do-Check-Act

PMO projectmanagementoffice

ROI returnoninvestment

RUP rationalunifiedprocess

SAFe® ScaledAgileFramework®

SBE specificationbyexample

SBE specificationbyexample

XP eXtremeProgramming

2.DEFINITIONSA3.Away of thinking and a systematic problem-solving process that collectsthepertinentinformationonasingleA3-sizesheetofpaper.

AcceptanceTest-DrivenDevelopment (ATDD).Amethodof collaborativelycreating acceptance test criteria that are used to create acceptance tests beforedeliverybegins.

Agile.AtermusedtodescribeamindsetofvaluesandprinciplesassetforthintheAgileManifesto.

AgileCoach.An individualwith knowledge and experience in agilewho cantrain,mentor,andguideorganizationsandteamsthroughtheirtransformation.

AgileLifeCycle.An approach that is both iterative and incremental to refineworkitemsanddeliverfrequently.

Agile Manifesto. The original and official definition of agile values andprinciples.

AgileMindset.AwayofthinkingandbehavingunderpinnedbythefourvaluesandtwelveprinciplesoftheAgileManifesto.

AgilePractitioner.Apersonembracingtheagilemindsetwhocollaborateswithlike-mindedcolleaguesincross-functionalteams.Alsoreferredtoasagilist.

AgilePrinciples.ThetwelveprinciplesofagileprojectdeliveryasembodiedintheAgileManifesto.

AgileUnifiedProcess.Asimplisticandunderstandableapproachtodevelopingbusiness application software using agile techniques and concepts. It is asimplifiedversionoftheRationalUnifiedProcess(RUP).

Agilist.SeeAgilePractitioner.

Anti-Pattern.Aknown,flawedpatternofworkthatisnotadvisable.

AutomatedCodeQualityAnalysis.Thescriptedtestingofcodebaseforbugsandvulnerabilities.

Backlog.SeeProductBacklog.

Backlog Refinement. The progressive elaboration of project requirementsand/or theongoingactivity inwhichtheteamcollaborativelyreviews,updates,andwritesrequirementstosatisfytheneedofthecustomerrequest.

Behavior-Driven Development (BDD). A system design and validationpracticethatusestest-firstprinciplesandEnglish-likescripts.

BlendedAgile.Twoormoreagileframeworks,methods,elements,orpracticesused together such as Scrum practiced in combination with XP and KanbanMethod.

Blocker.SeeImpediment.

Broken Comb. Refers to a person with various depths of specialization inmultiple skills required by the team. Also known as Paint Drip. See also T-shapedandI-shaped.

BurndownChart.Agraphicalrepresentationoftheworkremainingversusthetimeleftinatimebox.

BurnupChart. A graphical representation of thework completed toward thereleaseofaproduct.

Business Requirement Documents (BRD). Listing of all requirements for aspecificproject.

Cadence.Arhythmofexecution.SeealsoTimebox.

CollectiveCodeOwnership.Aprojectaccelerationandcollaborationtechniquewherebyanyteammemberisauthorizedtomodifyanyprojectworkproductordeliverable,thusemphasizingteam-wideownershipandaccountability.

Continuous Delivery. The practice of delivering feature incrementsimmediately tocustomers,often through theuseof smallbatchesofworkandautomationtechnology.

Continuous Integration. A practice in which each team member's workproductsarefrequentlyintegratedandvalidatedwithoneanother.

Cross-FunctionalTeam.A team that includes practitionerswith all the skillsnecessarytodelivervaluableproductincrements.

Crystal Family ofMethodologies. A collection of lightweight agile software

developmentmethodsfocusedonadaptabilitytoaparticularcircumstance.

Daily Scrum.A brief, daily collaborationmeeting inwhich the team reviewsprogress from the previous day, declares intentions for the current day, andhighlights any obstacles encountered or anticipated. Also known as dailystandup.

DefinitionofDone(DoD).A team'schecklistofall thecriteria required tobemetsothatadeliverablecanbeconsideredreadyforcustomeruse.

Definition ofReady (DoR).A team's checklist for a user-centric requirementthathasalltheinformationtheteamneedstobeabletobeginworkingonit.

DevOps. A collection of practices for creating a smooth flow of delivery byimprovingcollaborationbetweendevelopmentandoperationsstaff.

DisciplinedAgile (DA).Aprocessdecisionframework thatenablessimplifiedprocessdecisionsaroundincrementalanditerativesolutiondelivery.

Double Loop Learning. A process that challenges underlying values andassumptions in order to better elaborate root causes and devise improvedcountermeasuresratherthanfocusingonlyonsymptoms.

Dynamic SystemsDevelopmentMethod (DSDM). An agile project deliveryframework.

EvolutionaryValueDelivery(EVO).Openlycreditedasthefirstagilemethodthat contains a specific component no other methods have: the focus ondeliveringmultiplemeasurablevaluerequirementstostakeholders.

eXtremeProgramming.An agile software developmentmethod that leads tohigher quality software, a greater responsiveness to changing customerrequirements,andmorefrequentreleasesinshortercycles.

Feature-Driven Development. A lightweight agile software developmentmethoddrivenfromtheperspectiveoffeaturesvaluedbyclients.

FitforPurpose.Aproductthatissuitableforitsintendedpurpose.

FitforUse.Aproductthatisusableinitscurrentformtoachieveitsintendedpurpose.

FlowMaster.Thecoachfora teamandservicerequestmanagerworking inacontinuousfloworKanbancontext.EquivalenttoScrumMaster.

Framework. A basic system or structure of ideas or facts that support anapproach.

FunctionalRequirement.Aspecificbehaviorthataproductorserviceshouldperform.

Functional Specification. A specific function that a system or application isrequired to perform. Typically represented in a functional specificationsdocument.

HoshinKanri.Astrategyorpolicydeploymentmethod.

HybridApproach.Acombinationoftwoormoreagileandnon-agileelements,havinganon-agileendresult.

IDEAL.Anorganizationalimprovementmodelthatisnamedforthefivephasesitdescribes:initiating,diagnosing,establishing,acting,andlearning.

ImpactMapping.Astrategicplanningtechniquethatactsasaroadmaptotheorganizationwhilebuildingnewproducts.

Impediment.Anobstacle thatprevents theteamfromachievingitsobjectives.Alsoknownasablocker.

Increment.Afunctional,tested,andaccepteddeliverablethatisasubsetoftheoverallprojectoutcome.

IncrementalLifeCycle.An approach that provides finished deliverables thatthecustomermaybeabletouseimmediately.

InformationRadiator.Avisible,physicaldisplaythatprovidesinformationtothe rest of the organization enabling up-to-the-minute knowledge sharingwithouthavingtodisturbtheteam.

I-shaped. Refers to a personwith a single deep area of specialization and nointerestorskillintherestoftheskillsrequiredbytheteam.SeealsoT-ShapedandBrokenComb.

Iteration. A timeboxed cycle of development on a product or deliverable inwhichalloftheworkthatisneededtodelivervalueisperformed.

IterativeLifeCycle.Anapproachthatallowsfeedbackforunfinishedworktoimproveandmodifythatwork.

KaizenEvents.Eventsaimedatimprovementofthesystem.

KanbanBoard.Avisualization tool thatenables improvements to the flowofworkbymakingbottlenecksandworkquantitiesvisible.

KanbanMethod.An agilemethod inspired by the originalKanban inventorycontrolsystemandusedspecificallyforknowledgework.

Large Scale Scrum (LeSS). Large-Scale Scrum is a product developmentframework that extends Scrum with scaling guidelines while preserving theoriginalpurposesofScrum.

Lean Software Development (LSD). Lean software development is anadaptation of lean manufacturing principles and practices to the softwaredevelopment domain and is based on a set of principles and practices forachievingquality,speed,andcustomeralignment.

LifeCycle.Theprocessthroughwhichaproductis imagined,created,andputintouse.

Mobbing.A technique inwhichmultiple teammembers focus simultaneouslyandcoordinatetheircontributionsonaparticularworkitem.

Organizational Bias. The preferences of an organization on a set of scalescharacterizedbythefollowingcorevalues:explorationversusexecution,speedversusstability,quantityversusquality,andflexibilityversuspredictability.

OrganizationalChangeManagement.Acomprehensive,cyclic,andstructuredapproach for transitioning individuals, groups, and organizations from thecurrentstatetoafuturestatewithintendedbusinessbenefits.

Paint-Drip.SeeBrokenComb.

Pairing.SeePairWork.

PairProgramming.Pairworkthatisfocusedonprogramming.

PairWork.Atechniqueofpairingtwoteammemberstoworksimultaneouslyonthesameworkitem.

Personas.An archetype user representing a set of similar end users describedwiththeirgoals,motivations,andrepresentativepersonalcharacteristics.

Pivot.Aplannedcoursecorrectiondesignedtotestanewhypothesisabouttheproductorstrategy.

Plan-Do-Check-Act (PDCA). An iterative management method used in

organizations to facilitate the control and continual improvement of processesandproducts.

Plan-DrivenApproach.SeePredictiveApproach.

PredictiveApproach.An approach toworkmanagement that utilizes aworkplanandmanagementofthatworkplanthroughoutthelifecycleofaproject.

PredictiveLifeCycle.Amore traditionalapproach,with thebulkofplanningoccurringup-front,thenexecutinginasinglepass;asequentialprocess.

ProjectManagementOffice(PMO).Amanagementstructurethatstandardizestheproject-relatedgovernanceprocessesandfacilitatesthesharingofresources,methodologies,tools,andtechniques.

Product Backlog. An ordered list of user-centric requirements that a teammaintainsforaproduct.

ProductOwner.Apersonresponsibleformaximizingthevalueoftheproductandwho is ultimately responsible and accountable for the end product that isbuilt.SeealsoServiceRequestManager.

ProgressiveElaboration.Theiterativeprocessofincreasingthelevelofdetailin a project management plan as greater amounts of information and moreaccurateestimatesbecomeavailable.

Refactoring. A product quality techniquewhereby the design of a product isimprovedby enhancing itsmaintainability andother desired attributeswithoutalteringitsexpectedbehavior.

Retrospective. A regularly occurring workshop in which participants exploretheirworkandresultsinordertoimprovebothprocessandproduct.

RollingWavePlanning.Aniterativeplanningtechniqueinwhichtheworktobe accomplished in the near term is planned in detail, while the work in thefutureisplannedatahigherlevel.

ScaledAgile Framework (SAFe®). A knowledge base of integrated patternsforenterprise-scalelean–agiledevelopment.

Scrum. An agile framework for developing and sustaining complex products,withspecificroles,events,andartifacts.

Scrumban.AmanagementframeworkthatemergeswhenteamsemployScrumas the chosenway ofworking and use theKanbanMethod as a lens through

whichtoview,understand,andcontinuouslyimprovehowtheywork.

ScrumBoard. An information radiator that is utilized tomanage the productandsprintbacklogsandshowtheflowofworkanditsbottlenecks.

ScrumMaster.Thecoachof thedevelopment teamandprocessowner in theScrumframework.Removesobstacles,facilitatesproductiveeventsanddefendstheteamfromdisruptions.SeealsoFlowMaster.

Scrum of Scrums. A technique to operate Scrum at scale formultiple teamsworking on the same product, coordinating discussions of progress on theirinterdependencies, and focusing on how to integrate the delivery of software,especiallyinareasofoverlap.

ScrumTeam.Describes thecombinationofdevelopment team, scrummaster,andprocessownerusedinScrum.

Self-OrganizingTeam.Across-functionalteaminwhichpeoplefluidlyassumeleadershipasneededtoachievetheteam'sobjectives.

Servant Leadership. The practice of leading through service to the team, byfocusing on understanding and addressing the needs anddevelopment of teammembersinordertoenablethehighestpossibleteamperformance.

ServiceRequestManager.Thepersonresponsiblefororderingservicerequeststomaximizevalue inacontinuousfloworKanbanenvironment.Equivalent toproductowner.

Siloed Organization. An organization structured in such a way that it onlymanages to contribute a subset of the aspects required for delivering value tocustomers.Forcontrast,seeValueStream.

Single Loop Learning. The practice of attempting to solve problems by justusingspecificpredefinedmethods,withoutchallenging themethods in lightofexperience.

SmokeTesting.Thepracticeofusingalightweightsetofteststoensurethatthemostimportantfunctionsofthesystemunderdevelopmentworkasintended.

Specification by Example (SBE). A collaborative approach to definingrequirementsandbusiness-orientedfunctionaltestsforsoftwareproductsbasedon capturing and illustrating requirements using realistic examples instead ofabstractstatements.

Spike. A short time interval within a project, usually of fixed length, duringwhichateamconductsresearchorprototypesanaspectofasolutiontoproveitsviability.

Sprint.DescribesatimeboxediterationinScrum.

Sprint Backlog. A list of work items identified by the Scrum team to becompletedduringtheScrumsprint.

SprintPlanning.AcollaborativeeventinScruminwhichtheScrumteamplanstheworkforthecurrentsprint.

Story Point. A unit-less measure used in relative user story estimationtechniques.

Swarming.Atechniqueinwhichmultipleteammembersfocuscollectivelyonresolvingaspecificimpediment.

TechnicalDebt.Thedeferredcostofworknotdoneat an earlierpoint in theproductlifecycle.

Test-DrivenDevelopment.Atechniquewheretestsaredefinedbeforeworkisbegun,sothatworkinprogressisvalidatedcontinuously,enablingworkwithazerodefectmindset.

Timebox.Afixedperiodoftime,forexample,1week,1fortnight,3weeks,or1month.SeealsoIteration.

T-shaped. Refers to a personwith one deep area of specialization and broadability in the rest of the skills required by the team. See also I-Shaped andBrokenComb.

UserStory.Abriefdescriptionofdeliverablevalue fora specificuser. It is apromiseforaconversationtoclarifydetails.

UserStoryMapping.Avisualpracticefororganizingworkintoausefulmodelto help understand the sets of high-value features to be created over time,identifyomissionsinthebacklog,andeffectivelyplanreleasesthatdelivervaluetousers.

UX Design. The process of enhancing the user experience by focusing onimprovingtheusabilityandaccessibilitytobefoundintheinteractionbetweentheuserandtheproduct.

ValueStream.Anorganizationalconstructthatfocusesontheflowofvalueto

customersthroughthedeliveryofspecificproductsorservices.

Value Stream Mapping. A lean enterprise technique used to document,analyze,andimprovetheflowofinformationormaterialsrequiredtoproduceaproductorserviceforacustomer.