AGILEPROJECTMANAGEMENT

TheSimplifiedBeginner’sGuidetoAgileProjectManagement

SecondEdition

Contents

ACCESSYOURFREEDIGITALASSETS

INTRODUCTION

|1|HISTORYOFAGILEPROJECTMANAGEMENT

TheAgileAlliance

Motivation

|2|BASICSTRATEGY

GeneralOutline

BasicStrategy

Scope&Staff

|3|THEENVISIONPHASE

TheProjectCharter

ChoosingTools

EstablishingaHealthyAgileWorkCulture

UsingaProductDataSheet

SprintPlanning

|4|THESPECULATEPHASE

UnderstandingUserStories

UsingPerformanceRequirementCards

UsingDailyMeetings

UsingAgiletoPromoteFlexibilityofPacing&Thought

MeasuringSprintVelocity

|5|THEEXPLOREPHASE

LeadershipthroughService

ThePoweroftheSelf-OrganizingTeam

HandlingIssueswithinSelf-OrganizingTeams

|6|THEADAPTPHASE

TheHumanFactor

ACultureofContinuousFeedback

|7|THECLOSEPHASE

TransitionManagement

TheImportanceofCelebration

|8|THECANONOFAGILEMETHODOLOGIES

VariationsofAgile

Scrum

Lean

Crystal

DSDM

XP(ExtremeProgramming)

|9|TOOLSFORAGILEPROJECTMANAGEMENT

PhysicalFiling/Classification

BasicSoftwareApplications

SpecializedAgileSoftware

|10|PRACTICALIMPLICATIONS

ExpenseStructure

StaffIssues

MarketImplications

AgilePointsofViewwithinanOrganization

|11|BRIEFAGILECASESTUDIES

GE

HomelandSecurity

|12|EXTENDEDAGILECASESTUDYNO.ONE

Implementation

TrackingProgress

SupportfromManagement

Coaching

ScalingwithintheOrganization

ScalingtheBudget

RefiningtheProcess

WhatWeCanLearn

|13|EXTENDEDAGILECASESTUDYNO.TWO

Preparation&Initialization

TheNextStep

PreparingforManufacturing

WhatWentRight

WhatCouldHaveGoneBetter

SummaryofResults

|14|CRITICISM

CustomerInput

ProfessionalImpression/CorporateImage

TeamComposition

DependencyofInterrelatedStages

Waterfall

|15|THEAGILESUB-INDUSTRY

TheSub-Industry

Literature

CONCLUSION

GLOSSARY

ABOUTCLYDEBANKTermsdisplayedinbolditaliccanbefounddefinedintheglossary.

BEFOREYOUSTARTREADING,

DOWNLOADYOURFREEDIGITALASSETS!

VisittheURLbelowtoaccessyourfreeDigitalAssetfilesthatareincludedwiththe

purchaseofthisbook.

DOWNLOADYOURSHERE:

www.clydebankmedia.com/agile-assets

Introduction

Someactivitiesareonlypossible toexecute successfully if theyareassociatedwithmorethanoneperson.Theyareeithertooextensiveintheirmagnitudeortoo sophisticated in their nature to be performed by a single individual. Theyrequiretoomuchworkoradiversityofexpertisethatnoonepersonpossesses.Itisthennecessarytoapproachtheseactivitiesusingateam.In addition to the overarching aim of satisfying the original objective, any

project,whether incommerceorbroader society, requiresproperplanningandexecution, so that the available resources of time, money, and labor areappropriately utilized. The management of projects in this way is a distinctdiscipline in the corporate sphere, replete with its various styles and theirproponents. Consider, for instance, China’s famous Three Gorges Dam. Thisdam,whichwas completed in the early 2000s, is a truly gargantuan structure.The dam secures a reservoir 660 km in length containing approximately ninecubic miles of water weighing forty billion tons. This mass of water is sosubstantial that it actually affects the rotation of the earth to a slight yetsignificantextent,andithasshiftedthepositionofthemagneticpolesbynearlyaninch.Itshydroelectricinstallationgeneratespowerequivalenttoabouttwentynuclear power reactors. The Three Gorges Dam is not only a marvel ofengineering, it’salsoamarvelofprojectmanagement.Machinesandmaterialsmustbeprocured.Peoplehavetobeemployed.Planshavetobedrawnout,andeverythingmustbecoordinatedintelligently.Butwhatifyoucould,withasimplestrokeofakey,moveanentireteamof

workers (or a crane for thatmatter) fromone sideof the594-foot-wideThreeGorges Dam to the opposite side? What if you could move, resize, andreconfigure the dam’smassive turbines at will and perform hundreds of real-world tests measuring the energy output of the dam across a multitude ofconfigurations? Would such flexibility change your approach to project

management?Informationtechnologyismoreflexibleandattimesmoreunpredictablethan

thephysicalmaterialsemployedataconstructionsite.Ifyouattemptedtopursuean ITproject—softwaredevelopment, let’s say—thesamewayyoupursue thebuilding of a dam, with an end-to-end ironclad blueprint of your build and astrictproductionschedule,thenyourlackofflexibilitywouldlikelyprohibityoufromdeliveringanoptimalproduct.Yourprojectmanagementapproachwouldbemuchstrongerifyouincorporatedanelementofintelligentflexibilityonyourpathtoachievingthebestpossibleresult.Ontheflipside,ifyoutriedtobuildadam“flexibly,”withouttheaidofafairlypreciseblueprint,thenyou’dbelikelytowastecopiousamountsoftime,money,andresourcesor,worse,buildadamthatcouldnotstand.Frommassive publicworks projects to the creation of complex IT services,

the concerns of project management persistently come into play. Manyconsiderations of project management are universal, such as budget, designconsiderations, construction methods, time frame, marketability, keyspecifications,andperformancethresholds.Theapproachesusedwhenassessingthese considerations, however, are not universal and will prove dramaticallydifferent dependingon the nature of the project.A simple copy andpaste canmovemilesofpowerfulcode;thesameagilityisnotfeltinmattersofconcrete,stone, and lumber. Agile is a popular methodology of modern projectmanagementthat,whileparticularlyfittingforsoftwaredevelopmentendeavors,can be applied across a broad range of production environments. This bookexamines Agile in detail, including its history, its techniques, and itsimplicationsforthosewhouseit.Thebookbeginsbyexploringtherelevanceofproject management at large. It then proceeds to work through the variousaspectsofAgilebeforereviewingtheEnvision,Speculate,Explore,Adapt,andClosephasesofAgileProjectManagement.AseriesofcasestudiesinAgilearereviewedinthelaterchapters,followedbyareviewofthepopularcriticismsthathavebeendirectedatAgile.ThereisalsoanoverviewoftheAgilesub-industrythathasarisen,intermsofbothadvisoryservicesandthesoftwaretoolsthatitsusenecessitates.

This book is intended as an introduction to the Agile Project Managementsystem.

ThoseinterestedinapplyingAgiletotheirprojects,eitherasanexperimentoron the basis of a more serious recommendation, should remember that theinformation provided by this text is general in nature and does not constitutespecificprofessionaladviceororganizationalstrategy.Asapreliminarysourceof information,however, it shouldenable the reader topursuedeeper inquiriesandultimatelydecideon the suitabilityof theAgile systemand,once thathasbeenestablished,theexactvariationtoapply.Finally,thoughourcontemporariesmaynotallbeinagreement,thistextwill

treat “Agile” as a proper noun while concurrently acknowledging that Agilemethodologies spanmany industries and encompass several distinctly definedframeworks. Nevertheless, we take the position that “Agile ProjectManagement” (APM), can signify a distinct structure (Envision, Speculate,Explore,Adapt,Close),pertheoutlinepresentedinChapters3through7.

|1|HistoryofAgileProjectManagement

InThisChapter

TheHistoryofAgileAgilePrinciples

TheAgileAllianceTheconceptofastandardizedorprescribedstrategyforprojectmanagement

is not new. Different organizations or cultures may have practiced their ownmethodsinregulatinglargelaborforcesorassigningresourcestotheprojectsinwhichtheyengaged.However,itwasonlysincethemiddleofthe1950sthattheconceptbegantoberegardedasamoreformaldisciplineandattractitsofficialterminology. At present, it is taken seriously in commerce and elsewhere, asevidencedby, for example, theAssociation forProjectManagement (APM) intheUKor theAmericanSociety for theAdvancementofProjectManagement(ASAPM).Agile Project Management to large extent represents a reformation of or

departure from several of the preexisting 20th century project managementmethodologies. Therefore, the formulation and subsequent promotion of adiscreteandself-containedmanagementmethodologyisnotanovelty,noris itsurprising that it draws on existing systems of both project and businessmanagement.Agile Project Management (or Agile for short) was devised within the

softwareindustry.Theprocessofcreatingnewsoftwareisknownspecificallyas“development.”TheinitiatorsoftheAgiledoctrinewereallsoftwaredevelopers.This is possibly why it has such a strong association with the IT sector.ProponentsofAgilehavemadetheassertionthatitisapplicabletoanyindustry,

andthereisliteratureexamininghowthishashappenedinpractice.Itspotentialfordeployment inactivitiesoutsideof ITwillbediscussed in laterchaptersofthisbook.In early 2000, correspondence about project management techniques was

startedbetween theeventualAgile roleplayers.This initial interestblossomedintoaformalconferenceinChicagoin2001.1There,seventeenprofessionalsinthesoftwareindustryhashedoutanewmethod,basedontheirexperiencewiththeir respective, preferred alternatives. At this meeting, they composed thevariousstatementsthathavebecomesynonymouswiththeAgilemovement.First,theyidentifiedwhatareregardedasthethreeerroneousassumptionsin

projectmanagement:

1. Itispossibletoplanalargeproject.(Meaningthatit’spossibletomoreorlessanticipateandmapout

thedevelopmentandresultofaprojectfrombeginningtoendwithahighdegreeofclarityandpredictability)

2. Itispossibletoprotectagainstlatechanges.(Meaningthatlatechangesarenotinevitable)

3. Itmakessensetolockinbigprojectsearly.(Meaningthatresourcesonalargescaleshouldbeacquiredearly

andinfull,becausethereisnochanceofanywaveringfromstatedplans)

Asyoucansee, thesethreeissuesallhighlight thepointraisedat theendofthe previous chapter: that the objective of a project (or the end user’sexpectations) can change during the course of its execution and make itimpossible for the project team to provide a satisfactory result. The firstassumptiononthelistisanallusiontotheimmensityofsomeprojectsandhowtheyarenotamenabletoarigidanddetailedframeworkorforecasting.Evenasimplejoblikepaintingahousedependsonstableweather.Howmuchmoreso,then,theconstructionofadamspanninganentiremountainrange,orasoftwareapplication attempting to compete in a spacewhere newcompetitors enter the

marketonadailybasis?The meeting proceeded to identify four binary juxtapositions, showing

preferenceforanewapproachtoprojectmanagement.

Individuals&InteractionsoverProcesses&ToolsWorkingSoftwareoverComprehensiveDocumentationCustomerCollaborationoverContractNegotiation

RespondingtoChangeoverFollowingaPlan

The idea is thatwhile there isvalue in the itemson the right-hand side, theitemsontheleft-handsideshouldbevaluedmore.The last item is particularly noteworthy here, but the others also serve to

illustrate the emphasis on people instead of procedure (the first item), on theefficacy of the end result rather than the bureaucratic administration of itsdevelopment and presence in the market (the second item), and on customerservice and satisfaction over impersonal, disinterested business practice (itemthree).Itshouldbestatedthattheemphasisonreducingtheadministrationassociated

with a project (its bureaucracyor “comprehensive documentation”) sometimesattracts the adjective “lightweight” in the context ofAgile (as opposed to the“heavyweight” systems that encompass extensive administration andmanagementstructures).Intryingtoestablishtheseprinciplesastheelementsofaprojectmanagement

strategyinpractice, themeetingresultedin thecreationof the12PrinciplesofAgileSoftware(figure3).

ThislistofprinciplesisknownintheindustryastheAgileManifesto,andithas been officially published on the website of the Agile Alliance, whichconsistsoftheoriginalseventeenmemberswhodraftedit:

KentBeckMikeBeedleArievanBennekumAlistairCockburnWardCunninghamMartinFowlerJamesGrenningJimHighsmithAndrewHuntRonJeffriesJonKernBrianMarickRobertC.MartinSteveMellorKenSchwaberJeffSutherlandDaveThomas

Thereisnoneedtoenterintoadetailedanalysisoftheseindividualsortheircareers in the IT industry. What is important to note is that some of themrepresented the most prominent existing management paradigms at the time.These were Extreme Programming (Kent Beck), Adaptive SoftwareDevelopment (Jim Highsmith), Feature-Driven Development, PragmaticProgramming (AndrewHunt and Dave Thomas), Crystal (Alistair Cockburn),Scrum(KenSchwaberandJeffSutherland),andDynamicSystemsDevelopmentMethod (DSDM). Some of these paradigms are either closely associatedwithAgileorareregardedasitssubsidiarymethodologies.Whatisalsoobviousfromthemembers’namesisthattheyarerelatedtosoftwaredevelopment.

OnecontributorwhodoesmeritindividualmentionisJimHighsmith,whohasgoneontocreateareputationforhimselfastheleadingauthorityontheAgileProjectManagementmethodology.WewillbereferringtothepublishedworkofHighsmithatvariouspointsthroughoutthistext.

MotivationThedesire toestablishanew,moreeffective,orotherwise improvedproject

management system in the software industry was based on advertised andsubstantial dissatisfactionwith existingmethods. Thiswas perhaps due to theexpansionoftheITindustry,intermsofbothscaleandrangeofapplication,ormerelybecause thenature of its productmakes it the territory for this typeofexperimentation.By theyear 2000, the Internet, software, and computer technologywere the

machinery of the future; even smaller, local industries were irrevocably tech-dependent.Thetechgeniehadsaidfarewelltoitsbottlealongtimeago,andtherelevanceoftheInternetandITwouldbeaninevitablehallmarkofthetwenty-first century. Peoplemay not remember theY2K crisis (the phenomenon thataroseasaresultoftheinabilityofsomesoftwaretoprocessmorethantwodigitsfor theyear inadate, rendering ituselessonJanuary1,2000)orhowexcitedeconomistsandothercommercialobserversbecamewiththeintroductionofITintoeachnewsphereofeconomicactivity.Buttheoverarchingsentimentofthetime was one of expectation, complete with all the sci-fi style imaginativepredictionthatgoeswithit.With the IT industry being required to supply solutions on such a massive

scaletosomanydifferentmarkets,arefinedorevenentirelynewmanagementapproach was a priority, especially one which is so uniquely suited to theindustry itself. As an example, Windows 95, an earlier Microsoft operatingsystem(whichsomeyounger readersmayhave toGoogle to identify), sold40millioncopiesinitsfirstyear.Microsoft’slatestoffering,Windows10,reached75millionusersinfourweeks.2

One fundamental characteristic of software and its development that maymake it susceptible to trouble iswhat the industry terms“uncertainty.”This is

moreinconnectionwiththealreadyoutlinedunstablenatureofaprojectanditstargeted results. The development of new software is uncertain in that itsultimate desired functionality cannot be determined until it is in use by thecustomer.Sometimes the end user’s expectations change once the software is in use,

sincetheymayrealizenewpossibilitiesorreceivemoredecisivefeedbackfromtheirowntargetmarket.Becauseof this, thesoftwaredeveloper is taskedwithcreatingaproductthatissatisfactorybutthatsimultaneouslyhastosubscribetothe potentially shifting requirements of its commissioner. This is known as“scope creep,” and the opportunity it presents for failure, frustration, andmiscommunicationisobvious.Prior to the formalized advent of Agile, management protocols revolved

around two basic approaches, the latter of which would evolve into what werecognizetodayas“Agile”:

WaterfallWaterfallistheprotocolmostpopularlymentionedinconjunctionwithAgile

andisoftenseenasanopposingorantiquatedmethodology.Itinvolvesdevelopingthesoftwareaccordingtoapriorplanordeterminedframeworkofactivity,likethestagesintherapidsofawaterfall.Itissometimesreferredtoas“plan-driven.”

Spiral,rapidprototyping,evolutionarydelivery&incrementaldeliveryAlloftheseapproachesentailtheproductionofpiecesoftheultimateproduct,

forthecustomertoexperimentwithandprovidearesponseto.Theyaresometimesdescribedas“agile,”thatis,asopposedtotheexecutionofapremeditatedplan.The incremental or phased nature of the second approach proved more

compatiblewiththedevelopmentofsoftware,modulatingtheuncertaintythat’soften innate to the development process. Understanding Agile as a departurefromWaterfalliscriticalandwillberevisitedseveraltimesthroughoutthistext.

In assessing the various sub-methodologies that have arisen under the Agileumbrella, it is important to remember what preceded it (Waterfall) and howsuccessive innovations and spin-off methodologies contributed to our presentnotionof“Agile.”

ChapterRecap

Agilewasbornofthesoftwareindustry’sneedforinnovativeapproachestoprojectmanagement.

AgileoffersasolutionforuniqueuncertaintiesthataffecttheITindustry’sabilitytodevelopproducts.

TheWaterfall(pre-Agile)methodofprojectmanagementoffersausefulcomparisonpointwhenstudyingAgileProjectManagement.

1JimHighsmith,“History:TheAgileManifesto,”AgileManifesto.org,2001,http://agilemanifesto.org/history.html.2JaredNewman,“Fourweeksafterlaunch,Windows10isalreadyon75millionPCsandtablets,”PCWorld,August26,2016,http://www.pcworld.com/article/2975911/windows/four-weeks-after-launch-windows-10-is-already-on-75-million-pcs-and-tablets.html.

|2|BasicStrategy

InThisChapter

DistinctionsBetweenAgile&WaterfallComparative5-StepProcessesThatDefineAgile&WaterfallAgile’sApplicationofFlexibilityasaResponsetoUnpredictability

Agile(adj.):Abletomovequicklyandeasily

GeneralOutlineAgile Project Management, as the name suggests, is a rapid and highly

responsive method of process management. Its leading proponent, JimHighsmith,haswritten that it enablesamuch faster,more flexible response tochanging market circumstances and the sudden, unexpected tactics ofcompetitors.3That is, essentially,how ithas come tohave theadjectiveas itsofficial name—due to the supposedly malleable and reflexive nature of theprocessestowhichitisapplied.Forthispropensity,Agilereliesonthephasedorstagedprocessstructurethat

it represents. Instead of the more traditionalWaterfall approach, whereby theproject is defined, its parameters stated, and then its constituent steps taken,Agileallowsforself-terminatingphasesorincrements.Attheendofeachphase,or“iteration,”thecustomerispresentedwithausableproductandtheirfeedbackis sought in order tomodify the next increment. This incremental or iterativeapproacheventuallyarrivesatthefinalproductorultimateresult.It shouldbeapparent from thisdescription thatAgilemakesanadaptedend

result possible. During the project, the customer or end user can assist indetermining its course, by supplying additional information or changing theirexpectationsentirely.Duringtheearlytwentiethcentury,millionsofimmigrantscametotheUnited

Statesinsearchofabetterlife.Theyoftenhadverylittlemoneytospend,andsoadopted amethod of home building thatmany in themodern daymight findperplexing. Once they had saved enough money to buy a plot of land, theywould construct only the basement on the land. The basementwould be theirresidenceuntil theyhadaccumulatedenoughmoneytoaddoneor twostories.Such a development approach is similar to the Agile system insofar as thecustomer (homeowner) is presentedwith a finished andworkable stage of theproductattheendofeachiteration.Iftheirfundsareexhaustedoriftheyrealizethattheynolongerrequirefurtherdevelopment,theycanterminatetheprocessentirely.In other ways, the home building analogy is much more similar to the

traditional Waterfall method of project management. The materials used inconstructingahomecan’tbe rapidlymoved,copied,ordeleted from thebuildlikealineofcode.Moreover,thefunctionsservedbyahomearefairlyapparentoutofthegate,whereasthedevelopmentofsoftwaremaybedrivenanddivertedbyreal-timefeedbackfromcustomersandfast-pacedadvancesintechnologicalcapacity; new processors come to market a lot faster than new buildingmaterials. The iPhone’s “iOS” operating system has gone through countlessiterationssincetheiPhone’s2007debut,eachiOSupdateseeminglycapableofevolvingtheproductfromtheinsideoutasopposedtomerelysupplyingadd-onfeatures. This nuanced, non-linear, and fast-paced character of softwaredevelopment is one of the reasons that the need for alternatives to traditionalprojectmanagementmethodsbecameapparent.Agilewasbornoutofthisneed.

BasicStrategyThe most important steps in the project management system prescribed by

Agile are adapted from a more traditional paradigm. Previously, projectmanagementterminologyincludedfivestepsintheprocess.Highsmithinventedhisownfivestepsasanalogoustothoseandinaccordancewiththeunderlyingphilosophyofhisownsystem.

TheInitiatingandPlanningstagesinthetraditionalWaterfallprocessinvolveidentifyingwhatthecustomerwantsandthenplanninghowtoprovideit,whichhappens during theExecuting stage.Agile, on the other hand, uses the loosertermsofEnvisioningandSpeculating todescribe thefirst twostages,and thenExploring to refer to the actual implementationof theplan.This isbecause inAgile, the execution of that specific increment does not represent the sole orentireexecutionphaseoftheprojectand,generally,theprojectisnotsubjecttoafixedproductdescription.Customerfeedbackissoughtandappliedto thenextphase,Exploring.This, inturn,meansthattheproductis“adapted”ratherthan“controlled.”The use of language in these five steps is indicative of theAgile approach.

The rigid, narrow philosophy behind the traditional management system isreplacedby themoreflexible, responsiveattitudeofAgile. InChapter3,we’lltakeamoreexpansive,in-depthlookateachofthesefivesteps.InassessingAgile,itisimportanttorememberthatthesystemwasdevisedin

order to improve the development of new products. Highsmith describes thefollowingfivemainimperativesforAgile’sapplication:

Agile is referred to as iterative because it involves an itinerant (phased)processwithwhich to fulfill thecustomer’sneeds. It is incrementalbecause itdoessoinstagesofcompletion.Thepriorityistoproducesomethingattheendof each stage that the customer can use, that fits a clear business need.Thesestages of completion are commonly referred to as sprints. Sprints are theessentialdevelopmentunit(buildingblock)inAgileProjectManagement.Theyaretypicallyoneweektoonemonthinduration.Theyareteam-basedburstsofworkthatfocusonthedevelopmentofaspecific,agreed-uponsetof“features”(see chapter 3). The Agile Project Management’s sprint-based approach, asopposed to that ofWaterfall, oftenproves a better fit for businesses thatmustnavigateconstantlychanginglandscapestoremaincompetitive.Itisalsousefulfor businesses that want to produce products fast that can accommodateimmediatebusinessneeds.

Scope&StaffIn keeping with its emphasis on an unknown or unpredictable project

outcome,Agiledoesnotspecifythefinalproduct,astheplan-driven(Waterfall)methodsdo.Inthelatter,theproductoroutcome(thescope)oftheprojectisthefirstitemofinterest.Estimatesarethenmadeastotheentirecostandtimeframeoftheproject.Often,budgetsareoverrunandadditionaltimeisrequired.Agile,however,doesnot specifyanexact scope (as is seen in thestrikingly

inexact terms used to describe its initial steps—Envisioning, Speculating, andeven Exploring to refer to its execution). Rather, its focus is on the availableresources of time and money. In this way, the project cannot exceed thoseparameters. Also, as an iterative process, it allows the customer to terminatetheirinvolvementattheendofanyiteration,leavingthemwithausableproduct,even if it is not the entire or ultimate output that they initially desired. It is,therefore, theoretically impossible for anAgileproject to surpass theavailablecapitalinvestmentoritsdeadline.Thisapproachalsohasimplicationsforhowstaffparticipationintheprojectis

managed.Agiledoesnottoleratethemoretraditionaltop-down(vertical)power

dynamicinthemanagementoftheprojectteam.Instead,theteammembersareencouraged to takeownershipof theprojectandmanage themselves toa largeextent. Certain team leaders are used in Agile merely to negotiate or removeinstitutionalobstructionsandmaintainanenvironment that is conducive to theteam’s work and success. It is the team itself that sets the work agenda anddecidesontheproperapproach.AllofthesefactorswillbecomemoreapparentinChapters3through8,aswe

explore the component parts of theAgile ProjectManagement Life Cycle (or“Framework”) indepth,andinChapter8,aswediscussvariousAgile-specificmethodologies.

ChapterRecap

ThecomponentsofAgileProjectManagementcorrelatewiththetraditionalWaterfallmethodbutoffergreaterflexibility.

Agileusesanincrementalapproachtocompletingprojectsbasedonworkunitscalled“sprints.”

TeamdynamicsinanAgileworkingenvironmentarenotashierarchicalastheyareintraditionalworkingenvironments.

3Highsmith,AgileManifesto.org.

|3|TheEnvisionPhase

InThisChapter

DetailsofAgile’sEnvisionPhaseTheImportanceofBuildingaVisionCreatingaProjectCharterTheRolesoftheProjectManagerandProjectSponsorSelectingCollaborationToolsHowtoPlanSprints

The five steps—Envision, Speculate, Explore,Adapt, Close—as introduced inthe previous chapter are referred to as the Agile Project ManagementFramework or, sometimes, as theAgile ProjectManagement LifeCycle. Thenames of the five steps themselves were first recorded by Jim Highsmith,seemingly in response to the key tenets of theWaterfall method. Everythingabout the APM Framework, especially when compared to Waterfall, is anendorsement of flexibility. The Waterfall term “planning,” for instance, wasrejected in favor of “speculating,” because planning carries with it theconnotation of a fixed road map, where the core parameters (the roadsthemselves) aren’t expected to change. “Speculating,” by contrast, allows formore unexpected events, shifts, perhaps changes in available resources orchanges in thedemandsandexpectationsof thecustomers,orevenchanges inthe goals of the project management team itself. “Explore” (the third step) isreally the execution phase, but because explore is a less rigid term than“execute,” the team can operate with greater flexibility and agility. Becausethey’reexploring,there’slessriskofbeingovercautious,tooafraidofmakingamistake, too reluctant to attempt creative solutions. If you’re “exploring” thenyou’re still gathering answers, even as you’re asserting them, and thisdisposition,Agilefinds,makesforoptimalprojectmanagement.

Figure6showshowthelifecyclephasesproceedthroughoutthecourseofaproject.You’llnoticethattheSpeculate,Explore,andAdaptphasesareiterativeandmayrecurseveral times throughout the lifeofaproject.TheEnvisionandClosephases,bycontrast,areone-timeonly.

Highsmith makes the argument that the static Waterfall-style methods areusefulifthebusinessispursuing“repeatablemanufacturing,”butifthebusinessispursuing“reliableinnovation,”thenAgileProjectManagementismorelikelytoyieldoptimalresults.ByfollowingthestepsintheAgileProjectManagementFramework,theongoing,meaningful,andvaluableeducationofteammembersbecomespossible,ifnotinevitable.Andnotonlydoesmanagementenjoyahighlevelofvisibilityintotheprojectmanagementprocessasitunfolds,butothersintheorganization—teams,managers,andanyotherinterestedparties—areabletoinspectandlearnfromtheprocessbeingfollowedbyanygiventeam.Ascompanies,organizations,oreventeamsgrowlarger,itbecomesmoreand

moredifficulttopursuemeaningful,enduringchangestoestablishedprocesses.ConsistentrelianceontheAgileProjectManagementFrameworkallowsteamstobeevermoreflexible,evenastheygrow.Creatingavisionforanewproduct,service,orprocessimprovementshould

occurbeforeanystrategicapproachisconsidered.Bythetimeyou’redevelopingstrategy(mainlyintheSpeculatephase)you’realreadyconsideringthe“how”oftheproject,whenyoufirstneedtoconsider the“what.”Author,publisher,and“visionary”MichaelHyattarguesthatourvisions,whencultivated,haveawayofattractingthestrategyneededtobringthemtolife.Onhisblog,YourVirtualMentor,Hyattrecountsapersonalstorywherethestrengthofhisvisionwasableto turn around a failing enterprise. His supervisor had resigned unexpectedly,and Hyatt was made head of his division. The division was failing, the leastprofitable out of seven in the company. Rather than “being reasonable” andkeepingexpectations low forhisdivision,Hyattdecided togoona retreat forseveral days with the intent of developing a bold and optimistic vision forsuccess. He created a simple plan containing targets for various performancemetrics.Uponreturning,Hyattcalledameetingwithhisstaff.Althoughhewasfrankwith themabout the current conditionof thedivisionand the challengesahead,hepresentedacompelling,specificvisionforwhathewantedtoseethemaccomplish as a team. Most among Hyatt’s staff rolled up their sleeves andcommitted to bringing the new vision to reality. After a while, even the

stragglers and cynics began to believe that a new daywas possible. Eighteenmonths later, and for several years thereafter,Hyatt’s divisionwas one of thecompany’sstrongestandconsistentlyturnedasizableprofit.4

In the Envision phase of Agile Project Management, the vision you createshould be specific with regard to “what” and “who.” A “what” might besomethinglike,“Iwanttocreateanaugmentedreality(AR)videogamethatwillbeplayedby themeparkgoerson theirmobilephones.Thegamewill featurecharacters that are licensed to be used by the theme park. The characterswillprovidethegameplayerscluestothelocationsofvariousARartifactsthatcanbefoundatcertainlocationswithinthethemepark.Ifaplayercollectsacertainnumberofartifacts, thenhecanredeemthemforprizesatgiftshops.ThisARgame will be downloadable for a one-time fee of $2.99 and will bring in$250,000inrevenuetotheparkduringthefirstyear.”

TheProjectCharterAprojectcharter isused todocument theessentialvisionforaproject.The

charterisusedtodefinewhattheprojectis,whoitinvolves,andwhatconstitutessuccess.Theremaybecertainabstractandtheoreticalelementstothecharteraswell,suchas“projectmission.”Inthecaseofouraugmentedrealitygame,themissionwouldbesomethingtotheeffectof,“Toengagethemeparkcustomersinanewandmemorableway,whileleveragingourintellectualpropertyassetstobuildprofit.”Ateammaychoose toforgoaprojectcharter—for instance, if theproject is

toosmallandtimeisafactor.Thedecisionsaboutwhether tocreateacharter,how long it shouldbe, andwhat it shouldcontainmustbedecisions thatyourentireteamparticipatesinmaking.Yourproject charter canbeused toestablishandcodifypriorities. Ifyou’re

developing anARgame that encouragespeople to explore a themepark, thenyou’ll want to prioritize safety during the course of product development.Prioritiesmayalsobeestablishedtodefineprojectresponsibilitiesandorderofwork. For instance, you may want certain employees or contractors involvedwith the project to always work on programming tasks when possible and to

only work on testing tasks if no programming tasks are available. For otheremployeesorcontractorsyoumaywanttoassignexactlytheoppositepriorities—testing and then programming. Again, defining priorities wherever possiblewillpreventneedlessdeliberationandexpediteproduction.InChapter3,wediscussedhow thescopes forprojectsaredefined inAgile

ProjectManagement. To summarize, thoughAgile provides an added level offlexibility,organizationsmuststillbeawareof the limits toavailable timeandresources. When scoping a project through Agile Project Management, youshould focus first on the overall vision for the project, whichwill be definedsuccinctly in the project mission. Don’t make themistake of focusing on theresourcesyoucurrentlyhaveonhand,but instead focusonyourvision for theprojectandwhatyou’dliketheprojecttobe,anddefineyourscopeaccordingly.It’s okay to set an ambitious goal. If there simply aren’t sufficient resourcesavailable to support what you have in mind, then you’ll rub up against thatrealitysoonenough.What’smostimportantisthatyoudon’tlimityourselftooseverelyrightoutofthegate.Instead,allowyourdefinedscopetozeroinonthenatureofyourcustomer.Arewetargetingkids,adults,men,women,etc.?Whatistheessentialvaluewe’llbebringingtoourcustomers?Isitentertainment?Isitconvenience?Isitimprovedhealth?Anddon’tforgettoreflectonthe“why”ofyourproject,asyoudefinescope.Ifyoudon’twantyourprojecttogoofftrack,then it’s important tomaintainandadhere toaclearlydefinedpurpose; in thiscase,“We’recreatinganARgameforour themepark toattractvisitors to thepark and to boost revenue.” Record these scoping parameters in your projectcharter.Yourprojectchartershoulddetailthevariousrolesandresponsibilitiesofkey

team members, such as the project manager and the project sponsor. If theprojectmanager is theCEOof theproject, then theproject sponsor is like thechairman of the board of directors. There will usually be less hands-oninvolvement from the project sponsor, but he’ll ultimately be responsible formaking sure that the project is supplied with money, resources, and workers.He’ll be the liaison between the project and executive management, ensuringthatthey’reawareofandsupporttheproject.Theprojectmanagerwillbemuch

more concernedwith the day-to-day of project operations.When questions onprojectscope,responsibilities,orprioritiesarise,theprojectmanagerwillbethefinal arbiter. Within a larger organization, the project manager is alsoresponsibleforpreparingreportsthatdemonstratetheprogressoftheprojectandany need for additional resources. The project manager is responsible forkeepingtheprojectontrack,adheringtothevision,byensuringthattheprojectisdirectlyservicingtheorganization’sbusinessneeds.Agoodprojectcharterwillalso includecleardefinitionsforprojectsuccess,

whether they’re revenue targets, customer engagement metrics, ticket sales,efficiency improvements, or thedevelopmentof anewproduct that standsoutfromthecompetition.

ChoosingToolsAnother key component of the Envision phase is the selection and use of

effectivecollaborationtools.Thenatureofthecollaborationtoolsyouchooseislargelydependentonthetypeofprojectyou’remanaging.Ifyou’reworkingona large construction site, then two-way radios may be optimal, but if you’reworkingonbuildinganappandyourteammembersareallovertheglobe,thenyou’ll likely be better off with cloud collaboration tools such as Slack,Quickbase, or Asana. Since Agile Project Management was born in the techsector,you’re likely to findmoreAgile teamsusingonlinecollaboration tools,eventeamsthatdon’tworkremotely.Herearesomeguidelinesfortheselectionandmaintenanceofonlinecollaborationtoolsforyourteam.

1. Beawareofthetransitionburden.Veeronthesideofusingproductswithwhichyourteammembersarealreadyfamiliar.Ifyoufeelthattheprojectyou’reabouttoembarkonwarrantsaswitch,thenbeawarethatyou’regoing tohave toonboard (setup)and train teammembers.Thatsaid, many online collaboration tools are very intuitive and your teamshouldbeabletolearnthesoftwarequickly.

2. Compare collaboration tools while keeping your vision in mind.Author,blogger,andprojectmanagementexpertElizabethHarrinurges

project managers not to ignore their gut when choosing projectmanagement collaboration tools.5 You’re not going towant to take thetime to inspect the programming code of each utility, so at somepointyou’regoingtohavetouseyourintuitiontodeterminewhichtoolsseemlikelytoaidyourteaminreachingitsstatedobjectives.

3. Be aware of how your team communicates, and choose yourcollaboration tools appropriately. One of the major differences, forinstance, betweenSlack andAsana is thatSlackmakes it easy to jumpstraight fromachat log toaphonecall. Ifyouare inneedofanonlinecollaborationtoolbutsomeofyourteammembersaremorecomfortablecommunicating via voice, then availablemediums for voice, text, chat,etc.,mustbe considered.Other considerations along these lines includethe availability of conference calling, screen sharing, and privatecommunications.

4. Stop using one or more tools when redundancies arise. You maynotice that someof the tools used by your teamaccomplish essentiallythesamefunction;however,you’rereluctanttoconsolidatebecauseyoufear theremaybe someunique informationononeor another platformthat’s not replicated elsewhere.Rather than keepingmultiple redundantcollaboration tools in place, consider, for example, having youremployeesdownloadtheirchatlogs,files,orwhateverelsemaybestoredinanowobsoletesystem,intoasearchablebatchfile.

5. Make sure that at least one of your utilities provides a viewableschedule.Thesedays,workersexpecttohavetheirprojectworkscheduleaccessible, justasstudentsexpect tohaveaccess to thecoursesyllabus.Peoplewant toknowwhere theyareontheroadmaptocompletionandwhat comes next. Given that Agile Project Management involvescombining a multitude of smaller accomplishments (sprints) into onelarge accomplishment (the project), you can expect that your teammemberswillwanttoknowwheretheystand,prettymuchatalltimes.Ifyou do not choose a collaboration utility that offers a shareable,

updateableschedule,thenbesurethatoneisaccessibleelsewherewithintheworkenvironment.

EstablishingaHealthyAgileWorkCultureTheEnvisionstagemustalsoprovideasetofprinciplesforhowyourAgile

teamwillwork together, the norms and decorum to be observed.Agile teamstypicallyworkbetterwhentheyarekeptsmaller,generallynomorethanfifteenpeople. There’s no hard rule saying teams can’t be larger, but themore teammembers, the more difficulties may be encountered when cultivating groupfocus and a careful observation of the envisioned culture. Amazon CEO JeffBezosisknownforhis“twopizzarule,”whichadvisesneverhavingameetingwheretwopizzasareinsufficienttofeedtheentiregroup.6Asmallerteamwilloperate much like a family, just more professionally. There should be anemphasisonfocus,respect,andactivelistening.Inchapter3weintroducedtheconceptof“sprints”asthebuildingblocksof

production in Agile. Sprints limit the focus of any given component of theproject. Team members should be concerned only with the objectives of thecurrent sprint. This can be a difficult task, seeing as it’s often tempting tospeculate on and criticize the project at large. If a culture is established thatlimits focus to the current sprint, then it will be easier for the team to cometogetherandworkasonetowardaclear,immediateobjective.Agile teamstend toemphasizeacultureof face-to-facecommunicationover

emailand text.Emails shouldnotbe reliedupon for facilitatingconversations,especially those that may be contentious. Remote teams may encounterparticularlydifficult team-building challenges.Tools such as regularmeetings,conference calls, and recreational discussion threads can be helpful inmakingremoteteamsmorecomfortableworkingtogether.Another often challenging cultural element that’s especially important to a

goodAgile team is awillingness to respondpositively to requests for change.Let’ssaywe’reinthemiddleofdevelopingourARthemeparkgame—perhapswe’repursuinga sprintwherewe’remappingout theparkusingaGPSutilityfromGoogle.Our project sponsor comes in towork one day and reports that

newsafetyregulationsforARgaminghavebeenpassedbythestatelegislatureandwe’rerequiredtouseadifferent,moreprecisemappingutilityforthegame.Thechangewillrequiregoingbackthroughpagesandpagesofcode,updatingAPIs(ApplicationProgramInterfaces),awholelotoftediouswork.IfahealthyAgileculture ispresent in the team, then theywill respondwithanoptimistic,can-do attitude, and will perhaps use the unanticipated monkey wrench as achance to review and sharpen up other aspects of the code that could beimproved.

UsingaProductDataSheetThe product data sheet (PDS) is similar to the project charter, but more

conciseandmetrics-focused.Thisdocumentwillcontainthemissionstatementfromtheprojectcharter,alongwithaproposedtimeline,anestimateofcost,anda listingofconstraints. Itmayalso include informationaboutprojectprioritiesthatwillgoverndevelopmentoftheproduct.Asyoumayhavenoted,muchof the informationon theproduct data sheet

alsoappearsontheprojectcharter.Themajordifferencesare1)thebrevityanddata-heaviness of the PDSwill make it quicker and easier to reference whensearchingforprojectspecs,and2)thePDSdoesn’tpaynearlyasmuchattentionto thecompositionand thefunctioningof the team; it is instead tightlyframedaroundwhattheproductwillultimatelybecome.ThePDSwillcontainmorehighlydetaileddatathantheprojectcharter.When

it’s being created, it’s important for both project workers and stakeholders tohave a seat at the table, as the details present in this document will proverelevant to all parties. Stakeholdersmay include executive levelmanagement,the project sponsor, or the end customer. For example, in the case of ouramusement park AR gaming example, it’s unlikely that the amusement parkcompanyhasateamofgamedevelopersstandingby.Theywillverylikelyhireanothercompany,acontractor,tobuildthegameforthem.Whenthiscontractorcreates the PDS for the game, the appropriate personnel from the amusementparkcompanyshouldbepresentandparticipatory,sincetheyarethecustomersinthiscase.

Itmay be tempting in some situations to hit the ground running rather thanworryingaboutaPDS,orevenaprojectcharter.Justkeepinmindthatagoodplanningprocess—anda smartlydrawnPDS—has a high likelihoodof savingtimedowntheroad,nottomentionmoney.

SprintPlanningAlthoughyoursprintsdon’tbeginuntiltheExplorephase,it’sintheEnvision

andSpeculatephasesthatyoumustconsiderandplanfortheirduration.Inordertodothisyoumustbeawareofalldeadlinesfortheprojectandallfeaturestobeincludedintheproject.ThisinformationshouldbereadilyavailabletoallteammembersviathePDS.Inordertoeffectivelyplanyoursprint,youmustbecomefamiliarwithakeyterminAgile:the“feature.”Afeatureisaparticularserviceor functionality that a systemprovides and that is valuedby a client.Featuresmusthaveboth an action anda result component.Examplesof featuresmightincludethefollowing:

Reportingerrormessagestoweb-formuserswhofailtofilloutacriticalfield

Establishinganautomatedsecurityprotocolforasystemwherebyusersarepromptedtochangetheirpasswordseverysixweeks

Reportingthenumberofstudentsenrolledinaclass

For ourAR theme park game, a featuremight be the creation of an onlineshopping site that allowsplayers to purchasemerchandise featuring charactersfromthegame.Anotherexampleofafeaturewouldbetheinstitutionofin-game“experience points,” an accumulation of data that’s scaled to ensure that theusers are rewarded for the time they spendplaying thegame (inour example,theyarerewardedwithcreditstheycanspendtobuymerchandiseatthethemeparkgiftshoporperhapsintheonlinestore).Features come in varying shapes and sizes, and when you’re defining the

length required for a sprint you must accommodate the anticipated workloadrequired for the features that will be developed during the sprint. You’re not

likelytoknowexactlyhowmuchworkwillberequiredforeachfeature,butifyou’re working with an experienced team, then they should be able to offersoundestimates.In figure 7 we’ve quantified our anticipated workloads for various features

thatwillgointothecreationofourthemeparkARgame.Ifweweretoorganizethese features into two sprints of approximately the same duration, thenwe’dprobablycombinethe“onlinestore”featurewiththe“useravatar”feature,andwe’d combine the “scaling experiencepoints” featurewith the “title graphics”feature.The“scalingexperiencepoints”featurewilllikelyrequirealotofusertesting (therefore it’svery time-intensive)andwill likelybecompleted towardthe tail end of the project. The graphic design projects (user avatars and titlegraphics)arealotmoreflexible.Theycanbecompletedfirstthingorattheveryend.Wecouldtestthegamewithasingleavatar(dependingonourscheduleandpriorities,wemayevendecidetoreleasethegamewithasingleavatar).Whenplanningsprints, it’shelpful to tagfeatures thatare timeflexiblewitha“tf” inyourfeaturelisting,or“teo”fortailendonly;seefigure7.

If you’re having a lot of trouble determining exactly howmuch time you’llneed for various features, then you can organize your features into broadcategoriesthatestimateduration,suchassmall(20hours),medium(40hours),andlarge(60hours).

You’llnoticeinfigure8thatalthoughthefeaturesareofvaryinglengths,thecumulativetotaltimeallotmentisequalineachsprint(140hours).KeepingthedurationofsprintsuniformisanessentialAgileprinciple,asitallowsyourteamtoestablishaproductionrhythm.Afteryourteamhascompletedonesprint,theywillbegintodevelopastronginternalsenseof the timetheyhaveavailable toworkand theywillsteadilycalibrate theirwork tofitwithin theexpected timeframe.By contrast, if there is a large degree of variety in the time it takes tocompleteeachsprint,arhythmishardtoestablishandtheresultiswaste.

Whenplanningyoursprints,theprocessofdeterminingwhichfeaturesshouldbedevelopedinwhichsprintsisknownassettingupthesprintstructure.Whiledeterminingyoursprintstructure,it’simportanttomakenoteofwhichpersonnelwillbeavailableandwhen. Ifwehireavideogamedevelopmentcompany tomakeanARgameforouramusementpark,wemaydiscoverthattheirgraphicdesigners are available only during the fall quarter and have commitments ateveryother time throughout theyear.Wecanplanour sprint schedule aroundtheir availability, ask them to modify their commitments to their otheremployers, or we can attempt to bring graphic design support to the projecteitherfromourownstafforfromathirdparty.Similartothetaskofensuringtheavailabilityofproperpersonnelisensuring

the availability of general resources, servers, hardware, mobile devices,software, etc.Depending on the size of your organization, theremay be otherprojectsunderdevelopmentthatarecompetingforalimitedsupplyofresources.Businesspriority isalsoan importantdetermining factor indefiningasprint

structureappropriateforyourproject.Remember, in theory,eachsprintshouldculminate in some formofusableproduct; for instance, ifwecreateanonlinestoreforouramusementparkARgame,thenthisstoreshouldbereadilyusableelsewhere in the organization. Perhaps the whole store, or at least certainproducts from it, can be listed elsewhere on other companywebsites.Alwayslook for opportunities to syndicate the value gained from each featureestablished.Andsincecertainfeaturesaresure tooffermorewidespreadvaluethroughout the business, it onlymakes sense that business prioritywill play aroleindeterminingtheorderingofyoursprintstructure.Ifyou’reworkingwithateamthat’snewtoAgileProjectManagement,then

you should include a careful consideration of “risk” when determining whichfeaturestoputintheearlysprints.Risk,inthiscase,referstothecomplexityofthe feature being developed. Does the feature require the use of highlysophisticated technology or the cumbersome and error-prone integration ofexistingcodefromapreviousprojectintoanewbuild?Isthefeaturesomethingthat’s not been attempted before by the organization or requires extensive

reliance on interdepartmental communications?Are there toomany unknownsinvolved that could potentially derail feature development? These are all riskfactors and should be consideredwhen determiningwhich features to attemptfirstintheeventthattheteamisnewtoAgile.Ifpossible,beginwithsprintsthatare simpler in nature; this will imbue the team with confidence and soundrhythm.IfnewcomerstoAgileexperienceahighleveloffrustration,thentheymaybepronetoquicklydismissingorgivinguponAgilebeforeit’shadarealchancetowork.For teams that are rifewith experience inAgile, beginningwith higher risk

sprints is usually the best approach. Experienced Agile teams can usechallenging sprints early on in the project to gage and modify importantstructuralissuessoastomaketherestoftheprojectrunmoresmoothly.Though the Speculate phase is invaluable for taking inventory of available

resourcesandstatedobjectivesandforcultivatingavisionofsuccess,youwon’tget too deep into the rigors of sprint planning until your first iteration of theSpeculatephase,whichwe’lldiscussinthefollowingchapter.

ChapterRecap

TheAgileProjectManagementFramework’sfirstphase,Envision,requiresteamstocreateadetailedvisionoftheircompletedproject.

Visionsshouldincludenumericaltargets:downloads,dollars,customers,etc.

Thevisionforaprojectshouldbebasedonidealobjectivesratherthanimmediatematerialcapabilities.

Theprojectcharterisusedtodefinethemissionandsuccessstandardsforaproject.

Carefulselectionofcollaborationtoolswillenhancetheteam’sabilitytocommunicateandremainclearonthevisionfortheproject.

Establishingthoughtfulteamnormswillimprovemoralebycreatingamorecomfortableworkenvironment.

Theproductdatasheetoffersasummaryofdatarelevanttoprojectprogressandobjectives.

Sprintsareplannedbyestimatingworkloadsassociatedwithvariousfeaturesandbalancingthemoutbetweensprints.

4MichaelHyatt,“WhyVisionIsMoreImportantThanStrategy,”YourVirtualMentor(blog),MichaelHyatt.com,January23,2012,https://michaelhyatt.com/why-vision-is-more-important-than-strategy.html.5ElizabethHarrin,CollaborationToolsforProjectManagers,(Philadelphia,ProjectManagementInstitute,2016).6VivianGiang,“The‘TwoPizzaRule’IsJeffBezos’SecrettoProductiveMeetings,”BusinessInsider,October,29,2013,http://www.businessinsider.com/jeff-bezos-two-pizza-rule-for-productive-meetings-2013-10.

|4|TheSpeculatePhase

InThisChapter

DetailsofAgile’sSpeculatePhaseSelectingFeaturesforSprintsFeatureRequirementsProductRoadmapsHowtoOrganizeFeatureProductionUserStoriesCalculatingSprintVelocity

In the previous chapter, we discussed the Envision phase of Agile ProjectManagement,whichisastand-alonephasethat’spursuedonlyonceperproject,at the very beginning. The next phase, the Speculate phase, is one of threephases that iterate multiple times in the life cycle. These iterative phases,Speculate, Explore, andAdapt, are all in play during the course of any givensprint.The Speculate phase is devoted to determining which features should be

releasedfor the immediate iteration(Speculate,Explore,orAdapt). It’salso inthe Speculate phase that milestones are established aimed at conforming thework done in the iteration to the vision developed during theEnvision phase.Remember, theSpeculatephase isAgile’sanswer to thePlanningphaseof thetraditionalWaterfallmethod.MuchoftheworkdoneintheSpeculatephasewillresembleplanning,butwithanaddedlevelofflexibilityandamorehonestandanticipatory acknowledgment of the fact that calculations and even businessgoalsarelikelytochangeastheprojectproceeds.

When using the Agile methodology for software projects, iterations(Speculate, Explore, Adapt) usually last from two to six weeks. Hardwareprojectswill usuallyhave longer time frames. In either case,project costs andrisksmustbeassessedand,whendecidingonwhichfeaturestoincorporateintotheproject,thecustomerorendusershouldbeconsulted.Theselectionof features isoneof themost importantpartsof theSpeculate

phase. Many Agile users will use index cards or Post-it notes to categorizedifferenttypesandstatusesoffeaturesonawhiteboard.Featurestendtofallintothefollowingstatuscategories:

NewThesefeatureshavebeenestablishedtosupportthecurrentproject.

BackloggedThesefeaturesarecurrentlyconsiderednecessaryforcompletionofthe

projectbuthavenotyetbeendeveloped.Shouldtheprojectmanagercontinuetodeemthemnecessary,theywillneedtobeassignedtoasprintatsomepoint.

IncompleteThesefeatureshavealreadybeenthroughatleastoneiteration(Speculate,

Explore,orAdapt)butwillrequiremoredevelopment.Theywillbemovedtothebackloglistduringthefollowingiteration.Inadditiontoassessingthetimeandresourcecommitmentsthatwillgointo

your features and outlining a delivery plan, it’s also important during theSpeculate phase to drill down on the unique risk assessments associated withyourfeatures.AsexplainedinChapter4,themorecomplexthefeature,themoreriskyitisthoughttobe.Tosummarize,oncetheSpeculatephaseisfinishedandyouarereadytomove

into the Explore phase, the team should have produced the followingdeliverables:

Anassessmentof thefeaturesrequiredtocomplete theproject,alongwith

theirtechnicalandpersonnelrequirementsAn estimate of the amount of time or collective man-hours that will berequiredtodevelopeachfeatureAnassessmentoftherisksinherentineachfeatureAcollectionofsignificantmilestonesAreleaseplan

ThefirsttimeateammovesthroughtheSpeculatephase—immediatelyaftertheEnvisionphase—the timeneeded tocomplete the requiredspeculationwillbemuchgreater.This isbecause the firstSpeculatephaserequires the teamtolayouttheirestimatesandplanfortheentireprojectfront-to-back,justliketheywould if they were using a standard Waterfall approach. What makes Agileuniqueisthatnotonlydoesitallotfront-endplanningtimebutitalsoinstitutesrecurringplanning times thathappenat thebeginningofevery iteration, in the“Speculate” phase. After you complete the first major Speculate phase, thefollowing Speculate phases can be accomplished in a shorter time period,becauseratherthanspeculatingonthewholeproject,you’llonlybespeculatingonacertainblockoffeaturestobedevelopedinthenextiteration.Byinstitutingrecurring, designated planning times, Agile allows projects to remain flexibleandresponsivetothechangingneedsofbusiness.During the initial Speculate phase, some Agile teams create product

roadmaps, toolsusedtoassessandvisualizerequirements,timetables,andtaskpriority levels foraproject.Theproduct roadmapneednot strictlyconform totheconstraintsoflimitingfactorssuchasbudgetorpersonnel.Whileyoushouldmake estimates, you’re free to make them quite broadly. All of these initialestimatesand timetableswill inevitablybeclarifiedandchangedas theprojectproceeds.Toillustrate(create)yourproductroadmap,usevisualtoolsthatareshareable,

flexible, and simple. Many Agile teams simply use a whiteboard and stickynotes. You will arrange your proposed features for a project into groupingscalled“themes.”Themesaremacro-levelrequirementsoftheproject.InourARvideo game, a thememight be “gameplay” andwould contain amultitude of

gameplay–relatedfeatures.Anotherthemecouldbe“rewards”andwouldhandlehowrewardswouldbedistributedtoplayers.Anotherthememightbe“security”andwouldbedevotedtoprotectinguserdata.Whendevelopingyourproductroadmap,yourteamwillbeginbyidentifying

the major themes of the project. In determining themes, and subsequentlydeterminingwhichfeaturesshouldbedevelopedtosupportthem,it’simportantthatprojectstakeholdersbeinvolvedaswellasthosewhowillberesponsiblefordeveloping the product. The development of the product roadmap provides aspaceforimportantdialogbetweenstakeholdersanddevelopersaboutendgoals,strategies,resources,andlimitsoftheproject.Oncethemainthemesandfeaturesofyourproducthavebeenidentified,you

will want to evaluate your features or assign “scores” for each feature usingcertain criteria.When scores are assigned, they should be made in a relativecontextwithrespecttotheotherfeaturesrequiredfortheproject.Thisiswhyit’simportanttofirstgetabroadviewofthefeaturesyou’llbedeveloping,sothatyou’llknowhowtoscorethemrelativetooneanother.Thetwoprincipalscoringmetricsusedduringtheestimationprocessarevalue

and effort.Theproduct’s stakeholderwill be primarily responsible for scoringthevalueofvariousfeatures,whereasthedevelopmentteamwillberesponsiblefor scoring the effort.An effective system for scoring features relative to oneanothercanbefoundinthefamousFibonaccisequence.TheFibonaccisequenceis theorderingofnumberswherebyeach successivenumber is the sumof theprevioustwo:1,1,2,3,5,8,13,21,34,55,89,144,233,etc.Afeaturewithaneffortscoreof144or233willbeexceptionallychallengingandtime-intensiveforthedevelopmentteam,whereasafeaturewithascoreof8or13shouldgoalot quicker. Using the Fibonacci sequence to score features works, because itnaturally accounts for the uncertainty inherent in quantifying the complexitiesposedbylargerfeatures;asfeaturesbecomemorecomplex,it’smoredifficulttoestimatetheassociatedworkload.7When assessing value, a 144 or 233 would indicate an extremely valuable

feature,andan8or13maybesomethingtheproductcoulddowithoutifneedbe.Ifyourteamisgoingtomaintainadisciplinedscoringprocesswithclearly

definedstandardsforvariousscoringthresholds,that’sgreat.Don’tworryaboutmaintainingparityofscores,orsimilardistributionsofscoresbetweenvalueandeffort.Evenifyourvalueappraisers,forinstance,tendtousescoreslowerontheFibonaccisequenceandyoureffortappraiserstendtousehigherscores,itwon’tdistort your analyses so long as the features are always scored relative to oneanother. If the scores in each category are appliedwith appropriate relativity,youcangenerateanewmetric,called“relativepriority,”thatwillhelpyouwithprioritizationoffeatures.The formula for relative priority is simply value/effort. As the value of the

projectgoesupsodoesitsrelativepriority.Therelativeprioritywilllowerastheeffort score climbs.As an example, let’s say that our value appraisers tend toscore features high—89, 144, etc.—and the effort appraisers score featureslower: 8, 21, 34.Whenwe attempt to use relative priority to comparevariousfeatures,wewillgetuseful comparisons,despite the fact thatourvalue scoresarehighandoureffortscoresarelow.Theywouldalsobeusableifthereversewerethecase(higheffortscores,lowvaluescores).Theywouldevenbeusableif one or both of the scoring teams used a scale other than the Fibonaccisequence.All thatmatters is that the scores issued are consistently relative tootherscoresgiven.Considerthefollowingthreesamplerelativepriorityratings:89(valuescore)/8(effortscore)=11.13(relativepriorityscore)144(valuescore)/21(effortscore)=6.86(relativepriorityscore)144(valuescore)/34(effortscore)=4.24(relativepriorityscore)Basedonourcalculationofrelativepriorityscore,thetaskvaluedat89should

be higher priority than both tasks valued at 144. This is because the relativeeffortrequiredissolow.It’simportanttounderstandthatattainingyourrelativepriorityratingshould

support,notdefine,howyouprioritizeyour features inyourproduct roadmap.Therewillcertainlybefactorstoconsiderotherthantherelativepriorityrating.For example, if certain features cannot be developed before others aredeveloped,orifyourequireaccesstospecializedpersonnelforthedevelopmentof specific features, then the team must account for these factors whenprioritizingtheirwork.

UnderstandingUserStoriesOneofthemost importantAgiletoolsthatyou’llcreateandreferenceinthe

Speculate phase and throughout the life cycle of an Agile project is the userstory.Auserstoryisaone-ortwo-sentencestructuredtestimonialthatprovidesacustomer’sperspectiveontheneedforaproduct.As a [fill in the blank], I want to [fill in the blank], so that [fill in the

blank].Let’ssupposethatourprojectistodevelopanonlinejobboardforengineers.

Oneoftheuserstoriesweuseinourprojectmightlooklikethis:Asan[engineerlookingforworkonline],Iwantto[browseemployerswho

are looking fora specific skill], so that [I canreachprospectiveemployerswhohaveaspecificneedfortheskillsIprovide].Organizations using Agile often solicit user stories from all of their team

members—anyone can contribute regardless of rank or experience—and thenthey record theuser storieson indexcardsorPost-itnotes,where theycanbeviewedbythewholeteam,discussed,organized,reconsidered,andreorganized.Whatauserstorydoesisallowtheteamtocreateavisionfortheircustomer.

The team will begin to envision what their customer’s priorities are, whatproblemstheyhave,andwhattheirexpectationsarefromserviceslikethosetheteamintendstoprovide.There’salsoapowerfuldouble-checkingutilityinherentin theuseofuser stories.The last fieldof thestandarduser story is“so that,”which should clearly define the customer’s expectation. Let’s return to ourprojectexamplefromChapter4,theARgameforthethemepark.Wesaidthatoneof the featureswewantedwas theabilityof theplayer toearnexperiencepointswhileplayingthegamethatwouldmakehimmore likely towinprizes.Wemightdevelopauserstorythatresemblesthefollowing:Asa[playerofthegame],Iwantto[seehowmanypointsIneedtoreachthe

nextlevel],sothat[Icanworktowardaspecificprize].Welearnsomethinginthisuserstory.Welearnthatwecanmeetavaluable

customer’s need by showing him what prizes are available and may becomeavailable based on the level he’s reached in the game. Since our user story

explains that hewishes towork toward a specific prize, then, during our nextSpeculate phase,wemight consider adding a feature that shows game playerswhatprizes theycurrentlyqualifyforaswellaswhatprizes they’llqualifyforaftertheyreachthenextlevel.Wecouldusethatsameuserstoryforanotherormultipleotherfeaturesaswell.Wemightaddafeaturethatallowsuserstopicka prize they want at the beginning of the game and then receive updatesthroughouttheirgameplaydetailinghowclose(orhowfaraway)theyarefromearningtheirsought-afterprize.Userstoriesarewrittenthroughoutthecourseoftheprojectlifecycle.Some

organizations host a user storywritingworkshop at the very beginning of theproject,whereallteammembersareinvitedandencouragedtoparticipate.Userstoriesareusuallytitledandranked.Ametriccalledstorypointscanbeusedtoseparate the simpler stories from those that are more expansive and requirecomplexevaluationandresponse.Just likethevalueandeffortmetricsusedtorankfeatures,storypointsmayalsobescoredusingtheFibonaccisequence.Justaswiththescoringoffeatures,scoringofuserstoriesbywayof“storypoints”will prove perpetually useful so long as the stories are scored relative to oneanother.Someuserstoriesareparticularlybroad,somethinglikethis:Asaplayerofvideogames,Iwanttosharemygamingexperienceswithmy

friends,sothatwecanhaveafunwaytokeepintouch.In the context of our AR theme park game, this user story would be

considered epic, since it presumably would require a multitude of features toresolve.We’dhavetosetupacamerawithinthegameapp,awaytopushthephotocontentthroughoneormanysocialsharingAPIs,andwe’dhavetohaveanEULA(EndUserLicenseAgreement)createdcontainingalltheprivacyandlegalliabilityissuesthatouruserswouldneedtosignoffoninordertousethefeature.User stories don’t necessarily pertain only to normal use of the app. For

example:As a hacker, I want to exploit security vulnerabilities, so that I can access

sensitiveuserdata.It’s important to consider all potential interactions and interactors with the

product,notjustthoseforwhichtheproductisintended.Intheabove“hacker”example, the user story would be scored on the basis of how much work isrequiredtoensurethattheappissecure.

UsingPerformanceRequirementCardsSometimesafunctionisrequiredofaproduct,butthefunctioncan’tsimplybe

expressedasa feature.OurARgame, forexample,will requireaGPSfeaturethatwillreporttheuser’sgeographicpositiontothegame.Inorderforthegametoworkproperly,itmustbeabletoconsistentlytracktheuser’spositionasheorshemoves about thepark; therefore, a performance requirementmight be thattheGPSreportmustbeupdatedeveryfiveseconds.As shown in figure 10, the performance requirement is assigned a unique

number and/or a unique name. The criteria for performance satisfaction areexplained, and a complexity level is assigned. At the bottom of the card is adescriptionofhowtheperformancerequiredistobemeasuredandbywhomit’stobeverified.

Atthediscretionoftheteam,someperformanceattributesmaybenotatedbyusingan“acceptancetest”that’swrittenontoafeaturecardratherthanastand-aloneperformancerequirementcard.Thekeythingstoconsiderarewhethertheparticularperformancethresholdneedsanaddedlevelofindependentvisibility,whether it depends on multiple features, and whether the added detail of theperformance requirement card—such as the identity of theverifyingparty andthe “acceptability point of measurement”—is necessary for providing bettervisualizationofprojectrequirements.

UsingDailyMeetingsAnotherimportanttooloftheSpeculatephaseisregularstructuredmeetings.

MeetingsinAgilehavemanynames.TeamsusingtheScrumoffshootofAgile(seeChapter9)refertothisdailymeetingasthe“DailyScrum.”Othersrefertoitasthe“dailystand-upmeeting,”sonamedbecausetheattendeesareexpectedtostandontheirfeetforthedurationofthemeeting.Thepointistoensurethatthemeetingsdon’tdragonbutretainasharp,pointedfocusontheissuesoftheday. During these meetings, each member of the development team isresponsible for issuing a brief report. The format is something akin to thefollowing:YesterdayIworkedon[statewhatwasworkedonyesterday].TodayI’llbeworkingon[statewhat’stobeworkedontoday].Myimpedimentsare[stateanyimpediments].This format is designed to assure focus and brevity. As a general rule,

stakeholders should not participate in the daily stand-up meeting, onlydevelopers. If stakeholderswant toconversewithdevelopers, then theyshouldseek themout after themeeting.You don’twant long back-and-forths to takeplaceduringtheteam’sdailystand-upmeeting.Thefocusshouldbeonensuringthateveryoneisonthesamepagefortheday’sworkload;it’snotintendedtobea forum for theoretical discussion or even for problem resolution. Now, thatdoesn’tmeanthatteammembersshouldn’tkeepalertforreportsofimpedimentsthattheymaybeabletohelpresolve.Justdon’tusethemeetingtopresentyour

solutions. Instead, find theperson after themeeting andhelp them resolve theimpediment. If meeting participants frequently bring up issues that needimmediateresolution,then,ratherthanattemptingtoresolvetheissuesoranswerthe questions right away,write the problemsdownon a special section of thewhiteboard so that they may be resolved immediately following the meeting.SomeScrumteamsinstitutionalizeafter-meetingproblemsolvingbyholdinganoptional “after-party” meeting following the daily stand-up. The brilliance ofthismodelisthatitpreventspeoplefrombeingstuckinameetingwhenthey’vegotworktodo,butitgivespeoplewhoneedhelpawaytogetit.To ensure that the meeting proceeds in a timely manner, assign one team

membertoplaytheroleoftimekeeperandtocrackthewhipifsomeonebeginstodroneonfortoolong.Theprojectlead(productowner)shouldnotberunningthismeeting.An order should be established to determinewhich developmentteammemberreportsfirst,andthatordershouldbeadheredto.Someteamsliketo switch theorderof reportingeveryweekoreveryday tokeep things fresh,whichisgreatsolongaseveryoneisclearonthesequenceandreadytojumpinwhenit’stheirturntoreport.Whenparticipatinginthedailystand-upasaproductowneroramemberofa

developmentteam,payattentiontothemoodoftheteam.Isitapathetic,cynical,energetic,optimistic?Youdon’tneedmorethanafewminutesofmeetingtimeto get a good feel for team chemistry. You should also be able to ascertainwhetherthegroupisworkingatapaceappropriateforthetasksit’sresponsibleforcompleting.Iftheproductbacklogcontinuestogrowandthepaceofissue-resolution and feature release is slow, then you’ll need to figure out what’scausingyourteamtounderperform.Dependingonthesizeofyourteamandhowcloselytheyworktogetherona

dailybasis,youmaybeabletoreducethefrequencyofyourstand-upmeetingsfromdaily tobiweeklyoronceweekly.Youmayalsoconsiderhavingspecialmeetings,usuallyonalessfrequentbasis,whereyouinviteproductstakeholderstogetupdatedon thestatusofaproject.Whenhosting thesespecialmeetings,consider allotting ten to twenty minutes of time at the end of the meetingspecificallyforstakeholderstoaskquestions.

UsingAgiletoPromoteFlexibilityofPacing

&ThoughtAgile, in many ways, teaches us to think and to plan by means that

accommodatethetoolsandtechnologiesweuse.Agileasaprocesshasabuilt-inawarenessof how impossible it is to build an entirely accurateor evenusablefront-endplan.Inthepast,projectmanagerswouldbetheonesresponsiblefordeterminingexactlywhatwouldberequiredforaprojectandhowlongitwouldtake,butnow,withAgile, that responsibility is sharedamong themembersofthe development team. With Agile, the estimates offered for timelines,productionschedules,andthelikeareinaconstantandthoughtfulstateofflux.Thoughtful, because the system demands continuous evaluation, prioritization,andestimation.WithAgile,betterestimatesarepossibleinsuccessiveiterations,becausetheteammembersarecontinuouslyamassinghands-onexperiencewiththeproject.Meanwhile,thestakeholdersandevencustomersbenefitfrommoreimmediateexposuretofinished,usableproducts.The scope of an Agile project is defined by the features contained in the

productbacklogaswellasnewlyaddedfeatures.There’susuallynotadefinitivenumberoffeaturesthatyoumusthave,noristhereanumberwhichyoumustbecarefulnottosurpass.Bycontrast,thecumulativeexpecteddurationofagivensprintshouldremainconstant—eachsprintshouldbeofsimilarduration.

MeasuringSprintVelocityWhenitcomes to timemanagementandmeasuring thepaceofwork,sprint

velocity is one of themost importantmeasurements inAgile.Velocity can bedeterminedbyaveragingthestorypointsresolvedbyadevelopmentteamduringa series of sprints. The number you’re trying to get at is the number of storypointsthatcanberesolvedduringagivensprint.That’syourvelocity.

Note:Dependingonwhoyouask,youcanalsomeasure sprintvelocity inotherways, suchas thecumulativeeffortratingsforthefunctionsbeingdeveloped.

Velocitycanbeusedforawidevarietyofbusinesspurposes.Let’ssayyou’reattemptingtotimethereleaseofyourproduct,sothatit’supandrunningbya

certaindate,likeopeningdayoftheOlympicGames.You’rebuildingasoftwaresystemforOlympicvillage—the temporary residenceswhereOlympicathletesarehoused—thatwillhelpmakeathletesawareof theircompetitionschedules,transportationarrangements,andanyotherspecial factors thatwillensure theyreport to their events on time. You can use velocity measurements to makecertaintheproductistestedandreadytoreleasebyopeningday.Youdothisbytotalingalloftheuserstorypointsthatneedtoberesolved,andthendetermininghowmany sprintswill be required at your currentvelocity.Youmayalsousevelocitytoconformtobudgetaryrequirements.Ifyourdevelopmentteamcostsabout$50,000aweekandyourprojectbudgetis$500,000,thenyou’llneedtodetermine howmany sprints are possible in ten weeks (as you will have tenweeksbeforeyougooverbudgetonlabor)andthenuseyoursprintvelocitytodeterminehowmanystorypointscanberesolvedduringthattimeperiod.Thereareamultitudeofotherreasonsthataprojectmanager,stakeholder,orproductownermaywanttoexertcontroloverthedevelopmentandreleasetimelines.Forinstance,

Ifaparticularproductneedstobescheduledforreleaseatthebeginningofaholidayseason

If a product needs to be released tomarket as soon as possible after it hasdemonstratedsufficientfunctionality

Ifaproductneedstobereleasedatthesametimeasanotherorganization(oranother department within your organization) releases a complementaryproduct

Ifaproductneedstobereleasedatthesametimeasacompetitor’sproduct

Ineachofthesescenariostheprioritiessetwillbeinaccordancewithbusinessinterests, and the Agile system allows product developers to respond morepredictablyandinacoherentwaygiventhespecifiedtimeframe.Things can get a little tricky if you attempt to guess your team’s velocity

before they begin work. Velocity is best measured after the team has had a

chancetocompleteafewsprints.Ifyou’reworkingwithadeadlineorwithinabudget, then you’ll need to gradually focus the project as it proceeds throughdevelopment. Don’t attempt to do all of the planning at the beginning—remember, we’re using Agile, not Waterfall. If you wander and explore andspeculate before youdetermine theway forward, thenyou’ll fare better in theend.

ChapterRecap

TheAgileProjectManagementFramework’ssecondphase,Speculate,isfocusedonthedevelopmentofpiecemealprojectcomponents(features)bywayofshort,iterativeburstsofwork(sprints).

Productroadmapscanbeusedtooutlinetherequirementsforaproject.

Featureproductioncanbequalifiedandorganizedusingbasicscoringsystems.

Performancerequirementcardsanddaily“stand-up”meetingsareusedintheSpeculatephasetoassessprojectprogress.

SprintvelocitycanbeusedtoquantifyandmanagetheworkpaceofanAgileteam.

7Asmaier,February20,2012(1:55p.m.),commentonStackOverflow(blog),http://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker.

|5|TheExplorePhase

InThisChapter

DetailsofAgile’sExplorePhaseTheRoleoftheProjectManagerintheExplorePhaseSelf-OrganizingTeamsPlan,Do,Check,Adjust

The Explore phase refers to the beginning of actual production. With Agile,you’llgetintotheExplorephasemuchquickerthanyouwouldwithWaterfall.Explore isnotmeant tobe interpretedas reckless experimentation, throwingabunchofideasoutthereandseeingwhatsticks.Quitetheoppositeactually,theExplore phase is meant to efficiently and steadily uncover possibilities forinnovation in a cost-effectivemanner.Agile guru and author ofAgile ProjectManagement: Creating Innovative Products, Jim Highsmith, asserts fourtechnical practices that keep costs low while expanding possibilities forinnovation: Simple Design, Frequent Integration, Ruthless Testing, andOpportunisticRefactoring.8

SimpleDesignThispracticeassertsthatthedesignofagivenfeatureshouldbepursuedwith

simplicityinmind.Ifyou’refamiliarwiththephrase“dead-endcode,”thenyouknowhowdifficultitcanbetoreworkprogrammingworkthatwascomplexlyconstructed,evenwhentheultimatefunctionservedbytheprogrammingisn’titselfhighlycomplex.Highsmithrecommendsaprocesswherebyasystemisfirstdesignedtosolveaprobleminassimpleamanneraspossible,andafterwardsthesolventsystemisrefactoredtoconformto“designpatterns.”Designpatternsarenormsthathavebeenprovenreliableovertimeandpavethewayforeaseofintegrationintoalargerproduct.Asimpleandstandardizedsystemalsomakesiteasierandlessexpensivetoconductexperimentsandto

systemalsomakesiteasierandlessexpensivetoconductexperimentsandtoadapttochangingfactors.Together,thesetwoadvantagesallowfortheutmostprobabilityofsignificantinnovation.

FrequentIntegrationUpuntilnowwe’vediscusseduserstoriesandfeaturesasindividual

componentpiecesofaproductandhavenotaddressedtheissueofintegration.HighsmithurgesAgileteamstoadoptthepracticeoffrequentintegrationonthebasisthatit’shighlypreferabletodevelopinganintegrationschemeonlyafterasmatteringofcomponentfunctionsarealreadyupandrunning.Onemaywonderwhetherpursuingfrequentintegrationmaydistortvelocity,presumingthatintegrationwillbecomemoreandmorecomplexastheprojectexpands.Thetruthisthatitdoesjusttheopposite.Beingproactiveandsystematiconintegrationissuesminimizesthefootprint.Manydevelopmentteamsuseintegrationcontrolsystemsandpolicies,wherebynewcode(inthecaseofprogramming)isalwayssubmittedtoanestablishedintegrationframework,whichtestsandanalyzesthecode,facilitatingexpedientintegrationwiththelargersystem.

RuthlessTestingTheoverarchingtheorybehindruthlesstestingisthattheworkwillgoquicker

andtheproductwillbebetterifahighstandardofproductqualityismaintainedthroughoutthedevelopmentprocess.Eachsprintshouldculminateinthecreationoffeaturesthatcorrectlyandreliablyexecutetheirfunctions.Eachfeatureshouldbethoughtofasamini-productwithindependentintrinsicvalue.Whendefectsareidentifiedandweededoutearly,amuchcleaner,smootherworkenvironmentiscreated.Changescanbemadeandexperimentscanbeconductedatlowcost.Furthermore,developmentteammembers,ifmadetointeractandworkwithaconsistentlytestedproduct,willhaveaclearerideaoftheproduct’sultimatecapabilities.Iftestingisnotconductedregularly,aggressively,andaccurately,thendevelopmentteammembersareleftintheunenviablepositionofmakingassumptionsaboutvariousunderlyingproductcomponents(“AssumingwegetallthebugsoutofcomponentA,componentBshouldworkfine”).Whenruthlesstestingisthenorm,theseverificationsare

shouldworkfine”).Whenruthlesstestingisthenorm,theseverificationsareinstant(“BecauseweruthlesslytestedcomponentA,wecannowtestcomponentBandverifyforcertainthatitworksasintended”).Automatedtestingatregularintervalsandusingmanyvarietiesoftestsarethekeycomponentsofruthlesstesting.

OpportunisticRefactoringThisisaboutnotbeingsatisfiedmerelybecauseaproductworks.Developers

mustalsobeonthelookoutforopportunitiestoimprovetheproduct’sinternalstrengths,suchastheefficiencyofitsprogramming,inordertoensurethattheproductcanbedeployedindiversesettingsandcanbereadilyupdatedandexpanded.Therefactoringprotocolshouldalwaysincludeatestattheendtoensurethatnochangetothedesigncausedamaterialchangeinperformance.When you consider all of Highsmith’s recommended technical practices

together, thenyouwillseehowtheycoordinateandreinforceoneanother. It’seasier to integrate various features of a product if they’ve been constructedfollowingasimpleandstandardizedprotocol.It’seasiertotestaproductifit’sbeeneffectivelyintegrated.Andit’seasiertorefactoraproductifyou’reabletoimmediately test its ability to retain its functionality after the refactoring iscomplete.DuringtheExplorephase,thedevelopmentteamwillrelyonthedailystand-

upmeetings to coordinatework.Aswe discussed in the previous chapter, thedaily stand-upmeetings shouldbekept short and shouldbeused for reportingandobserving,notproblemresolution.Ifyou’reintheroleofaprojectmanager,usethestand-upmeetingstolisten

and observe. You should be on the lookout for impediments that could bepreventing development team members from handling their assignmentsefficientlyandaccurately.Developerswhoareengagedwiththeirworkandfeelasifthey’remakingprogresswillbemorelikelytodemonstrateahighlevelofconfidence and pride when reporting. Developers who are frustrated or whoaren’t as focused as they need to bemay not be very forthcoming about theirworkandmaygiveoffanairofdisinterestorannoyanceatthemeetingdespite

itsspecialfocusonbeingshortandtothepoint.TheendingofanExplorephaseismarkedbythedeliveryoftestedfeatures.

This is usually packaged around the ending of a sprint. On some occasions,however,anExplorephasemustcome toanendbeforenewdeliverableshavebeenproduced.Forexample, ifadevelopment teamexceeds its timeallotmentfortheExplorephasewithoutproducingtheplanneddeliverables,thenit’stimefor them toproceed to theAdaptphasewhere they’ll assesswhatwentwrongandresetthecourse.

LeadershipthroughServiceUnlike the traditional, Waterfall approach to project management, where

leadership exerts its will from the top down, in Agile ProjectManagement agreat multitude of leadership faculties are defined and driven by thedevelopment team.For instance, it isupto thedevelopment teamtodeterminetheprioritiesofthevariousfeaturesandtoestimatehowlongeachfeaturewilltaketodevelop.Theprojectmanageristhereprimarilytoremoveanyobstaclesthatmightstandinthewayofoptimalperformancebytheteam.Scrum, one of the most popular Agile methodologies, defines a project

management role called a “Scrum Master.” It is in this role that the uniqueleadership principles of Agile Project Management are codified. Manydiscussions of Agile use ScrumMaster as a term that’s interchangeable withprojectmanager.Otherdiscussionstrytodelineateadifferencebetweenthetwo.The reason for this confusion is that the uniquely Agile roles, such asScrumMaster,areanoutgrowthofthetraditionalprojectmanagerrole.Insomeorganizations the title “projectmanager” is retained, even though this person,when working on Agile projects, acts effectively as a ScrumMaster. In otherorganizations,thetworolesaredelineated,andwhiletheScrumMasterfocusesontheAgileprocessandplaystheroleofthe“servantleader,”theformalprojectmanager is in charge of financial monitoring of the project and maintainingcommunicationswiththestakeholders.ManyintheAgile-friendlycommunitiesrefusetousetheterm“projectmanager”foranyteammemberiftheteam,asawhole,ispursuingAgileProjectManagement.Thishostilesentimenttowardthe

term “project manager” comes from the term’s association with the moretraditionalmethodologies of projectmanagement. Hard-coreAgile proponentsare pursuing a major reinvention in the art of project management, and thisincludesareinventionoflanguage.RegardlessofwhethertheleaderofanAgile teamisconsideredthe“project

manager,”the“ScrumMaster,”oranythingelse,it’simportantthatsomeoneplaytheroleofmasterfacilitator(servantleader)fortheAgileteam.InsomesetupstheorganizationelectstousebothaScrumMasterandaprojectmanagerforthesame project. The ScrumMaster is put in charge of overseeing Agilemethodologies, while the general project manager takes care of stakeholderrelationsandmayalsooverseemoretraditional,Waterfall-styleinitiativeswhenneeded.Iftheprocessesusedforaparticularprojectarefairlywelldefined,thenaWaterfallapproachmayproveoptimal.Iftheprojectrequiresmoreinnovative,outside-the-box thinking, then the Agile methodology will grant thedevelopmentteammoreflexibility.In short, the principal responsibilities of an Agile project

manager/ScrumMaster/servantmanagerarethefollowing:

1. Facilitatecommunicationbetweenteammembers.ItfallsontheAgileprojectmanagertosetupatimeforthedailystand-uporScrummeetingsandtoensurethatteammembersarepresentandparticipating.Especiallyinhighlytechnicalprojects,gettingpeopletomeaningfullyinteractonaregularbasisisanimportantandchallengingjob.

2. Clear impediments. The last item reported by the development teammembers during a daily stand-up meeting is the impediments they areencounteringintheircurrentroles.AgoodAgileprojectmanagerlistenstotheconcernsexpressedandmakeseveryefforttoclearimpedimentstoensureoptimalperformancebytheteam.

3. Coach.TheAgileprojectmanager ischargedwithsafeguardingmoraleandidentifyingpocketsofanxietyordespair.Ifanemployee(orgroupofemployees)isn’tbuyingintothesystem,thenthesystemwon’tfunction

aseffectively.

4. Supportteamdecisions.TheroleoftheAgileprojectmanagerisnottomakedecisionsforthegroupbuttofacilitatethegroup’sabilitytomakeits owndecision and then to allow things to take their coursebasedonthat decision.Even if theAgileprojectmanagerdoesn’t agreewith thegroup’sdecision,heshouldstillstrivetosupportit.KeepinmindthattheAgilemethodologyisdesignedsothatmistakescanbemadethroughoutthe product development process. It’s expected that you, as the projectmanager,will bewrong on some occasions and that your teamwill bewrongonsomeoccasions.TheAgileapproachistolearnasmuchascanbe learned from mistakes. If you were against the idea from thebeginning, thensee ifyoucan learnanythingelse fromamistakeotherthanwhatyoualreadykneworsuspectedmighthappen.

5. Watch for team stressors. TheAgileProjectManagement system canbe intense, especially when the sprints commence and featuredevelopmentbegins. If aproject is tenweeks long, forexample,weekstwotoninearelikelytobethemostintensebecausetheywilloccupythebulkoffeaturedesigntime.Keepaneyeoutforstressedteammembersanddevelopwaystomoderatetheworkload.Trytopaceyourweekssothatforeverytwotothreeweeksofintensework,there’soneweekthat’salittlemorelaidback.

6. Secureresources.TheAgileprojectmanagerisresponsibleforensuringthat the teammembers have all of the resources necessary to do theirjobs. Resources may include various types of information, such ascustomerdataormarketingdata.Thetypesofsoftwareandhardwarethatwillaidinworkontheprojectare,ofcourse,importantresources.Thereare also intangible resources, such as training courses, curricula, andtests, aswell as access to specializedpersonnel, subjectmatter experts,designers,consultants,etc.

ThePoweroftheSelf-OrganizingTeam

Ratherthanrelyingonaprojectmanagerwhoactslikeataskmaster,theAgilesystemoptsforaprojectmanagerwhoactslikeaservant.Theteamistheentitythathasultimateauthorityandownershipovertheproject.Amongotherthings,self-organized Agile teams assess their productive capacity and define theirsprint targetsbasedon requests from theproductowner.Theproductowner istheAgile teammemberwho,moreso thananyoneelse,knowsaboutwhat theproduct is and does. The product owner is also the tie that binds together thedevelopmentteam,thecustomer,andthebusinessstakeholders.The product owner’s responsibility is to communicate to the development

teamwhattheproductneeds(thisisoftendoneviathecollaborativerecordingofuser stories) and the development team will be able to parse out the variousfeatures required, determine howmuch time it will take for each feature, andthenincorporatethattimeallotmentintoaplannedsprint.Aself-organizingteamisalsoproactivewhenitcomestocommunicatingwithoneanother.Ratherthanrelying on emails or waiting for a higher-up to facilitate communication, theteammembers identify necessary communications and speak face-to-facewithotherteammemberswheneverpossible.A self-organized team will generally produce a better product than a team

that’s being driven by a boss. An emphasis on shared ownership over theproduct, proactive communications, and self-determined task management allcontributetooptimizedresults.AsaprojectmanagerorScrumMaster,youwillwant to do all you can to vividly portray the potential advantages of self-organization: greater personal autonomy, amoremeaningfulwork experience,andthedevelopmentofapotentiallyground-breakingproduct.There’s certainly an art that goes into the cultivation of a successful self-

organizing team. Sometimes, once you feel that self-organization has beenestablished,it’sdifficulttoassessthefactorsthatwereresponsible,andthereforeit’s difficult to reliably replicate them. Nonetheless, being part of a self-organizing team allows you to look around and observe someof the elementsthatkeeptheteaminapositiveflow.Thenwhenyoutrytoreplicatethatteamdynamicforafutureproject,atleastyou’llknowwhatitisyou’relookingfor.One of the key features of a strong self-organizing team is the fluidity of

leadership.Theroleoftheleaderwillpassnaturallyfrompersontoperson.Theteam members will become keen and sensitive to opportunities to be goodleaders,aswellasopportunities tobegoodfollowers.Since there isnoformalbossor taskmaster,nooneneeds toguard their ego,but can insteadallow thebest ideas and solutions to surface amid the group. Good teammembers in aself-organizingteamarecontinuouslyputtingoutcurrentandusefulinformation.Thisisprimarilydoneintheformofworkreportsgivenduringthedailystand-upmeeting.But it’s also expected that teammemberswill activelyparticipatethroughout the duration of a project. For interpersonal conflicts or arguments,thelocalresolutionisstronglypreferred.Theteamitselfshouldbetheprincipaladjudicatorforproblemsthatarisewithinit.

HandlingIssueswithinSelf-OrganizingTeamsFor disagreements that arise concerning how to proceed on various tasks or

features,orhowtoaccuratelyscoreauserstoryorfeature,teammembersmuststrivetodetachthemselvesfromtheneedtobe“right.”ThebeautyofAgileisthatmistakesareexpectedandwill alwaysaddnew information to the system(and to the team), even if they fail tooffer sustainable solutions.Furthermore,theevaluationstructureusedbyAgileevaluatestheperformanceoftheteamasacollective unit.Therewill be no individual performance reports following anygivenproject.Thewholeteamisgoingtobeeitherrightorwrongtogether.Onepotential signof trouble iswhenyounotice that a smallgroupof team

membersappeartobedrivingtheprojectandtherestappeardisinterested, justalongfortheride.Theseorganicmicro-oligarchies,thoughnatural,arecertainlynotpreferred.Onewaytointroduceafreshdynamicintotheteamistomixupthe various roles. Part of the beauty of Agile is that team members are notrelegatedtooneparticularjob,butareexpectedtobewillingtojumpintorolesthatmaybeoutsideoftheircomfortzonesorareasofexpertise.Problems may also arise if the project’s stakeholders or customers are not

regularly available to collaborate with the development team. The input,especiallyofthecustomer,iscritical,sincetheymustultimatelybesatisfiedwiththe resultingproduct.Anotherpotentialproblemcomeswhen thedevelopment

team is ready to employ the Agile methodology, but the stakeholders orcustomers aren’t familiar with Agile and are taken aback by its lack of ahierarchicalstructure.Inthesesituations,educatingstakeholdersonthebasicsofAgile philosophy and soliciting their routine interaction with the project arelikelytoyieldfavorableresults.Inordertoensurenecessaryparticipationbyallinvolvedparties,manyAgile

teamsadoptthePlan,Do,Check,Adjust(PDCA)methodofproduction.

PlanDuringthe“plan”phaseofthecycle,theAgileteamassessesitsobjectives,

expectations,andpotentialproblems.Itisalsousefultoconsidertestingendeavorsduringtheplanningphase.Findoutwhatinformationandreal-timefeedbackyourteamwillrequireinordertodevelopthebestpossibleproduct,andstructureyourplanningaccordingly.

DoThe“do”phaseisaboutimplementingtheplannedcourseofactionand

retrievingaccuratedatathatwillinformthenexttwostepsoftheprocess,“check,”and“adjust.”

CheckThe“check”phaseprovidesroomforAgileteamstoassessthecompatibility

ofthe“plan”and“do”phases.Didtheresultsbroughtaboutbythe“do”phasereflectthegoalsestablishedinthe“plan”phase?Didtheresultsexceedexpectationsorfallshort?Wastheplancarriedoutproperlyinthe“do”phaseorweretheredeviations?Asaprojectproceedsthroughseveraliterations,havingalogthatdocumentsseveralplansandtheresultsoftheircorrespondingexecutionscancomeinhandy.Large-scalepatternscanbeusedtofurtherperfecttheprocess.Informationrecordedinthe“check”phasecanbesharedwithprojectstakeholdersalongwithproposalsforprocessimprovements,whichconstitutethenextphaseofthePDCAcycle,“adjust.”

AdjustThe“adjust”phaseisaboutcontinuallyestablishinghigherstandardsforthe

project.Overthecourseofseveraliterations,thegoalsestablishedinthe“plan”phase,theefficiencyofthe“do”phase,andtherigorousnessofthe“check”phaseshouldbecomemoreenhanced.Ifyourproduct stakeholders remainplugged in toyourPDCAprocess, then

you will notice a continual improvement in quality that will meet and oftenexceed stakeholder expectations. In many ways the “adjust” portion of thePDCA cycle is a microcosm of the Adapt phase of the Agile ProjectManagementFramework,discussedinthefollowingchapter.

ChapterRecap

TheAgileProjectManagementFramework’sthirdphase,Explore,isfocusedonuncoveringopportunitiesforinnovation.

ProjectmanagersinAgiledon’tmanagesomuchasfacilitate,inaccordancewiththewillofa“self-organizing”team.

8JimHighsmith,AgileProjectManagement:CreatingInnovativeProducts(UpperSaddleRiver,NJ,Addison-Wesley),2010.

|6|TheAdaptPhase

InThisChapter

DetailsofAgile’sAdaptPhaseObtainingContinual,UsefulFeedback

Going back to our example of an augmented reality game taking place in theenvironment of a theme park, imagine that our Agile team had planned andattempted towork toward a gaming interface that required the players to aimtheirmobiledevicesatthethemepark’srollercoastersastheywereinmotion,followingthepathofthetrainalongthetrackandearningpoints(inthegame)for doing so. The product ownerwas enthusiastic about this particular featurebecause it would give park patrons something fun and rewarding to dowhilewaiting in line.Now, let’s say that for any variety of reasons, the use of liverollercoastersintheARgamingenvironmentwasn’tworkingout.Theteamhadalreadybeen throughadozenor so “do”phasesof thePDCAcycle, theyhadgone through a dozen or so “adjusts,” and still no dice.But at the end of thesprint, the Agile team, rather than deeming the project a failure, pursues aholistically revisedoutlookon thenatureof theproblemathand.Recognizingthat the root concern of the product owner is providing patrons with a moreenjoyableexperiencewhilewaitinginline,theAgileteamdoesnotdeclaretheendeavorafailurebutinsteadspeculatesonawaybywhichtheprojectcanbeproductively “adjusted.” One idea is to use the game’s GPS overlay toconcentratemorepoints of interest into line-waiting areas.Perhapskeyvirtualartifacts,necessarytocompletecertainobjectiveswithinthegame,canonlybeaccessed just shy of the boarding areas for popular rides. Therefore, gamersultimately must ride certain rides in order to obtain their desired in-gamecollectibles.AnotherAgileteammembersuggeststhat thepointsofinterestbedynamicandalterable,sothatadjustingthemmaydrivepatronstocertainrides

ortoothersectionsofthepark.Lesspopularridesmightcontainmorevaluablevirtual artifacts, contributing to the balancing out of line-waiting times acrossattractions.Thoughweweren’table toattainwhatwesought toattainduringour initial

Speculatephase,wechose toAdaptrather thantofail.Andwewererewardedby value-adding alternatives that the technical staff, product owner, and allstakeholdersfeelcomfortablewith.The Adapt phase takes place at the end of each sprint and centers on a

comparisonofwhatwasdeliveredversuswhatwasplanned.Therewill,inmostcases, be certain discrepancies between the plan and the result, and theAdaptphase isused tomakechangesandoffernewsuggestions.TheAdaptphase ispart of the perpetual Speculate, Explore, Adapt iteration; therefore, multipleAdaptphasesmaytakeplaceduringthecourseofagivenproject.It’simportantthatcustomersandstakeholdersbe involved in theAdaptphases,as theremaybeaneed todiscuss substantial changes to theproject. It’s also important thatanynewbusinessneedsbearticulatedtotheAgileteambeforetheyrevertbackto the Speculation phase. For example, if our theme park executives haverecentlycome to thedecision that theyneed toattractmorecustomers to theircarnival game midway, then they will want to inform our Agile team toconcentratemorepointsof intereston themidway.The themeparkexecutivesmay have recently struck a deal with a new entertainment studio andwill beobtaininglicensureforanewportfolioofcharacters.Ratherthan“Pokefriends,”thebusinessnowwantsourAgileteamtodesignitsgameusingcharactersfrom“DragonWarriors.”A successful Agile team will track the lessons learned and changes made

acrossseveralsuccessiveAdaptphases.Doingsowillprovide the teamwithaprocessimprovementmeta-analysis.Theteammemberswillbegintogetasenseof one another’s strengths, weaknesses, and abilities to be flexible and adapt.TheAdaptphasemayincludeashufflingoftechnology,responsibilities,and/orpersonnel.Dependingontheanalysisoftheteam,featuresandprocessesmaybeaddedor takenaway.Thecontents andplanneddurationsofupcoming sprintsmaybeadjusted.Teammembersmaybeshuffledaround.TheAdaptphasemay

alsoincludeacriticalreviewofthedailystand-upmeetings.Whatmightbedonetomake thesemeetingsmore helpful andmore efficient? Speak now or holdyourpeaceuntilafterthenextsprint.While learning from your shortcomings is key, it’s also important to take

notice of what you’ve done right. The Adapt phase provides a chance tocelebratebigaccomplishments,suchasthesurpassingofmilestonesestablishedduringtheSpeculatephase.

Note:IfyourteamisusingtheScrummethodology,post-Sprint“Adapt”assessmentsarecommonlyreferredtoas“SprintRetrospectives.”

TheHumanFactorProject managers have a lot of responsibilities including risk assessments,

reporting, and fostering communication between team members. It’s alsoincumbentupontheprojectmanagertoregularlyassessthementalandphysicalwell-being of the Agile team members. Agile can be an intense, fast-pacedworkingmethod(they’recalled“sprints”forareason),andpeoplegettired.Forprojectmanagers, theAdaptphase canbeused to assess themorale andwell-beingofteammembersandtotakeactionasappropriate;forexample,aprojectmanager may decide to excuse a team member from a certain sprint. Theexcusedteammembermayusethetimeawayfromtheprojecttotakeavacationor to tend to company affairs outside the project. SomeAgile teams prefer tokeep teammembers engaged only in the team’s central project so long as it’sstillindevelopment,theideabeingthatyou’remetaphoricallylockedinaroomtogether,allyouhaveiseachother,andyouneedtofocusallofyourenergyonsupportingyourteaminyourstruggleforfreedom,whichofcourseisgainedbycompletionoftheproject.Theotherpotentialproblemwithchangingyourteammembers toomuch is that it canmake itmoredifficult to calculate “velocity”(seeChapter5).

ACultureofContinuousFeedbackTonurturesuccessfulandperpetuallyfruitfulAdaptphases,anAgileproject

managermustknowhowtoelicitusefulfeedback.Successfulprojectmanagers

will ask pertinent questions and facilitate meaningful dialogs between teammembers.Theacquisitionofuseful feedback shouldbecontinuousand shouldnot be relegated only to the Adapt phases. Building a culture of continuousfeedback is actually easier than youmight think.Much of theAgile structureinadvertentlylimitsroomforcontinuousfeedback.Dailystand-upmeetingsaredesigned tobequick and to thepoint, unencumberedbyprotracted theoreticaldiscussions or general complaints. Sprints are designed to be fast-paced andfocused,notcontemplative.Therefore,ifyouprovideanongoingforumforyourteammemberstoprovidegeneralfeedback,thenthey’lllikelytakeadvantageofit.Aphysicalfeedbackboxcanworkwellinthisrespect.Youmayalsobeableto leverageyouronline collaboration tools (seeChapter 4) to solicit feedback.Employeesmay candidly record and deposit their thoughts on variousmatterswithout having to offer immediate solutions. Complaints and suggestions arereviewedduringtheAdaptphase,andarehopefullypairedwithviableremedies.UsingafeedbackboxorasimilarsetupallowsyourAgileteamtoconcurrentlygenerate continuous feedback while also capitalizing on the rigorous focusinherentintheAgileProjectManagementmethod.Thecontentofthefeedbackboxwillalsoinspirenewandinnovativeideasfromtheteam.Inmanycases,itwon’tbefeasibletoimmediatelyimplementalloftheideasgenerated.TheteamwillhavetoprioritizetheimportanceoftheideasintheAdaptphaseanddecidewhichonestoincorporateintothenextsprint,whichonestoaddtotheproductbacklog, andwhich ones to disregard. The Scrum team as awhole should beinvolved in the prioritization process, either through voting or by some othermeans.

ChapterRecap

TheAgileProjectManagementFramework’sthirdphase,Adapt,emphasizesaresponsiveflexibilitythatwelcomesnewopportunitiesforaddingvalueandnewdefinitionsofsuccess.

ThoughtheinterpretationoffeedbackistechnicallyassignedtotheAdaptphase,alleffortsshouldbemadetocollectcontinuousfeedbackthroughoutthelifecycleofaproject.

|7|TheClosePhase

InThisChapter

DetailsofAgile’sClosePhaseProjectRetrospectivesEmployeeSend-OffsandCelebrations

AftertheAdaptphase,theprojectwilleitherrevertbacktotheSpeculatephase,or,iftheprojecthasattaineditsendpoint,thenitwillbemovedintotheClosephase. Project end points can be established for various reasons, some good,some not so good. If all of the features scheduled for development have beencompleted, then theprojecthascometoanendandcanenter theClosephase.The project may also enter the Close phase for administrative reasons, forinstanceifitexceedsitsbudgetandfailstoacquiremorefunds.Theprojectmayend due to a changing business need. For example, the theme park we’reworkingformaydecidethatanARgameisjusttoomuchofalegalliability—their insurance bill is already expensive enough. And on some occasions,projectscometoanendsimplybecausetimerunsoutonatime-sensitiveproject.IfmyAgileteamiscreatingadynamicvoterdatabasethatwillhelpusturnoutvotersonelectionday, thatprojectmaynotbeviableafter theelection isoverandmaythereforebeshutdown.The central function of theClose phase is to ensure that all lessons learned

fromtheclosure (andhopefullycompletion)of theprojectarecategorizedandreintegratedintothecollectiveknowledgeofthebusinessororganization.MuchlikearetrospectivemeetingisheldduringtheAdaptphaseafterthecompletionof each sprint, a more broadly scoped retrospective meeting is held at theconclusionofaproject.Thisbroadassessmentoftheproject,andtheperspectiveit brings, is unique to the Close phase and what really makes that phaseworthwhile. Some Agile teams may also produce a retrospective report or

document detailing the key lessons learned. The attendance at a retrospectivemeetingmayincludealargersubsectionofinterestedparties,includingnotjuststakeholders and customers, but executive leadership as well. Outside partiesmaybeinvitedtoattendthesemeetingsifwarrantedbycircumstance.Sinceneweyes will be on the project during the Close phase, new ideas may also begeneratedandnewfeaturesmaybecalledfor.Existingfeaturesonthebackloglistmaybegreen-litaswell.Partof thecustomaryretrospectiveisareviewofthe features thatwere on the backlog but nevermade it to production. If, forinstance, a project is brought to the Close phase after exceeding its budget,certainbackloggedfeaturesmaystillberesurrectedorrolledintoanewproject,dependingonthewishesofthestakeholders.It’salsopossibleforaparticipantintheretrospectiveprocesstocomeupwithamust-haveideaforanewfeature,which,again,eitherresults intheresurrectionof theprojector thenewfeaturebeingrolledintoanewproject.Inotherretrospectivemeetings,thestakeholdersmaydecidethatthefeatures

on the backlog may simply be disregarded. Another possibility is that thebacklogged featuresmaybewait-listed andperhaps implemented in the futuredependingontheperformanceoftheproductasis.During the Close phase, project-specific administrative tasks should be

resolved before the team disbands and information becomes decentralized.Vendorsmustbepaid.Accounts receivablemustbe collected.Teammembersmust be made aware of their next assignments. A monitoring infrastructureshouldbeerectedtotracktheongoingimpactoftheprojectonbusinessneeds.Theorganizationaswellastheprojectmanagerandteammembersaregoingtowanttoknowtheextenttowhichtheireffortsmadeadifference.

TransitionManagementIt’stheresponsibilityoftheprojectmanagertoensurethatteammembersare

clearaboutwhentheirworkontheprojectiscomplete.Asaprojectwindsdownit’s not uncommon for some team members to be excused before others,dependingontheirresponsibilities.Theprojectmanagershouldensurethatteammemberswhosework iscomplete transition smoothly to theirnext rolewithin

the organization, facilitating this transfer by maintaining adequatecommunicationwithboththeteammembersandtheirnewmanagers.Giventhatmost projects require severalmonths to complete, the transition period can beemotionally jarring for teammembers, sobeon the lookout for signsof stressandstrivetobeaccommodating.

TheImportanceofCelebrationAgile guru Jim Highsmith, when describing the Close phase, says projects

should end with a celebration.9 Having a team celebration gives everyone achance to appreciate all they’ve accomplished during the project. The Agilemodelisbuiltoniterativeburstsofhard,focusedwork,soit’sonlyappropriateto party like there’s no tomorrow once thework is complete. Celebrating theendingofaprojectwillalsoinstillinyourteamasenseofclosure,afeelingthatalltheirhardworkwasvindicated.During the celebration event, if possible, ensure that team members are

recognized for extraordinary accomplishments made during the course of theproject. In addition to recognizing individual accomplishments, your Closephasecelebrationshouldincludeanacknowledgmentoftheteam’ssuccesswiththeAgilemethodology. Itmay be helpful to host anAgile debriefing sessionbefore your celebration where the team can discuss their perception of theframework over the course of the project. Where might the process beimproved?Whereandwhendidtheprocessseemmostuseful?

ChapterRecap

TheAgileProjectManagementFramework’sthirdphase,Close,isconcernedwithassimilatingallknowledgegainedfromtheprojectintotheoverallorganizationalintelligence.

DuringtheClosephase,projectmanagersshouldensureahealthytransitionofteammembersintonewprojects.

9JimHighsmith,“AnAgileProjectManagementModel,”TechTarget.com,accessedon9/7/16,http://media.techtarget.com/searchEnterpriseLinux/downloads/04_Highsmith.pdf.

|8|TheCanonofAgileMethodologies

InThisChapter

PopularVariationsofAgile

VariationsofAgileAsstated in theprecedingchapter, therearedifferent sub-approacheswithin

theAgilesystem.TheseareeitherderivedfromtheoriesthatexistedbeforetheAgile system was officially initiated, or they are the work of individualproponents.Someofthemmay,therefore,resembleearlierprojectmanagementparadigms.Thishereditarysuccessionoradaptationisnotanewphenomenoninproject or business management. Since the inception of project management,there has been a substantial degree of intermixing and synthetic progression.ThischapterdoesnotpurporttobeanexhaustivediscussionofalltheavailableapproachesundertheAgileheading.These sub-approaches are sometimes referred to as “flavors,” a term taken

from the softwareprogramming environment.The term is an indicationof thedistinctions that exist in order for a program to meet variable needs, such asthoseofuserswhorelyondifferentoperatingsystemsorhaveotherpreferences.Tryingtoassesswhichapproachwillbestsuitanorganizationrequiresadeep

awareness of a project’s specific nature and precise application.Research intothe issue is necessary.Nomatter howpositiveother people’s remarksmaybeabouta specificvariationofAgile, eachproject facilitatorneeds tocompare itwiththeirsituationinordertodeterminewhetheritisasuitablecourseofaction.Thislistpresentsfiveofthemostimportantvariationsinusetoday.Theyare

not listed inorderof importanceorprevalenceofuse.Asageneralguideline,project managers are advised to observe described principles and established

practices inorder toevaluateeachapproach in relation to theircommon tasks.Ultimately, no project is ever anymore successful than the commitment, hardwork,andexpertiseofitsteam.

ScrumThisisthemethodmostoftenmentionedinAgileliterature.Itisperhapsone

of the best examples to highlight as an illustration of howAgile operates. Itsinternalprocesses, terminology,andstyleof teammanagementareanaccurateandtransparentdemonstrationofhowAgilefunctionsandthephilosophythatitentails.OneofthefirstproponentsofAgile,KenSchwaber,wasinvolvedintheinitialformulationoftheScrummethod.The word scrum is taken from the sport of rugby. For those who are

unfamiliar with this sport, it is played by fifteen players on each team andclosely resemblesAmerican football.Thescrum isamovementengaged inbyboth teams, during which eight players on each side (the heaviest, mostphysicallyimposingmembers)packtogetherandpushagainsttheiropponentsinacollectiveeffort.But scrum isn’t theonlypieceof rugby terminology in the system.There is

also the “kick-offmeeting,” duringwhich the project is discussed for the firsttimebytheprojectteam,inordertoascertainwhatthegoalsareandhowtheyare going to be achieved. During this meeting, the product backlog isestablished.Thisisthetoolusedtokeeptrackoftheworkthatneedstobedone,which is essentiallywhat the customer desires from the initiative (the scope).The customer is defined, and their expectations are discerned in the form of“userstories.”In ourAR game example, the theme park attendeewould be the customer.

Andherearesomeexamplesofuserstories:

Iwanttoearn,track,andredeempointsforplayingthisgame.Iwanttosharemyin-gameachievementswithmyfriendsonFacebook.IwantmygameplayoptionstoexpandasIprogressthroughthegame.

Theiterations(stages)withintheprojectareknownas“sprints,”andtheyareessentially the same as sprints used in the broader context of Agile. In eachsprint, backlog items are selected and resolved,whilenew items that arise areplacedontheproductbacklogtobeaddressedduringfuturesprints.Onceasprintiscomplete,thefinishedstageoftheprojectispresentedtothe

customerfortheirassessmentandfeedback,whichwillbeusedtoadditemstotheproductbackloganddefine furthersprints.What iscritical to realizeaboutthis example is that the game players (customers) may decide that they wantdifferentthingsduringthecourseofsuccessivereleasesofthegame.Customersmay find that features they thought they wanted actually detract from theirexperience, while features that didn’t poll well in feedback logs prove quitepopularintherealworld.Atthesejunctures,datafrompastprojectsofasimilarnaturemayalsoprovehelpful.Asprintor“iteration”shouldnotlastmorethanfourweeks.Sometimesitmay

beasshortasoneweek.Regardlessofthesprint’sduration,itshouldculminatein theproductionof somethingofvalue for theenduser (customer), even if itdoesnotyieldtheultimatelydesiredoutcome.Atthestartofeachsprint,teammembersholda“sprintplanningmeeting.”If

this is not the first sprint, themeetingwill be combinedwith a “sprint reviewmeeting,” which focuses on the preceding sprint. The targeted outcome for aparticularsprint,theSprintGoal,isestablishedduringtheplanningmeeting.Atthestartofeachday,thereisalsoa“dailystand-upmeeting.”Thismeeting

typicallydoesnotlastlongerthanfifteenminutes,andthememberspresentarerequiredtoremainstandingforitsduration.Thisissupposedtosymbolizeandengenderthesenseofimmediacy,alertness,andquickresponsethatthesystemincorporates.InScrum,thismeetingisknownastheDailyScrum,anditisusedtoplanthenexttwenty-fourhoursofactivity.DuringtheScrum,thefollowingquestionshavetobeanswered:

WhatdidIdoyesterdaythatwasmaterialtotheSprintGoal?WhatamIgoingtodotodaythatismaterialtotheSprintGoal?IsthereanythingstoppingusfromreachingtheSprintGoal?

Thebacklogconceptcanbeappliedtoeitherthesprintortherelease,whichistheeventualdeliveryoftheultimateproduct.Duringthecourseoftheprojectorsprint,aBurndownChartisusedtotrackprogressateachlevel.Thisisagraphthatdescendsinitstrajectory,markingprojectorsprintprogressasproportionalto the passage of time. The Task Board is used to promote awareness of theprojectinitsentirety,fromtheuserstoriesthroughtheiterationstothefinishedstages. It is an invaluable tool that organizes and tracks tasks that have beeninitiated, are in progress, and have been completed. In conjunction with theBurndownChartandtheuserstories,theTaskBoardprovidesa“one-stopshop”ofvitalinformationfortheScrumprojectteam.

TheteaminaScrumprojectconsistsofthreeroles.Theseare:

ProductOwnerScrumMasterDevelopmentTeammembers

TheProductOwner is themanagerof theprocess.However,heor shedoesnot micromanage the people who work on the project. The workers are leftlargely tomanage themselves. Instead, the ProductOwner takes responsibilityforthelistofbacklogitems,makingsurethateveryoneknowswhatisonitandwhateachitemrepresents.SometimestheypartiallydelegatethisfunctiontotheDevelopmentTeam. It is important to note that theProductOwner is a singleperson,notamanagementteam.TheScrumMasteristhepersonwhoseroleisdevotedtotheimplementationof

theprojectmanagementsystemitself.TheyneedtobewellacquaintedwiththeScrum(Agile)paradigmandbeabletoconveyitspracticeandideologytootherstaffmembers.They liaisewithboth theProductOwnerand theDevelopmentTeaminordertoensurethattheScrumsystemoperatesasitshould.TheDevelopmentTeamistypicallysmall,althoughpreferablynotfewerthan

threemembers.Ithasnointernalhierarchyortitles,otherthanDeveloper.It isself-managing,thatis,nootherpersonprovidesinstructionsonhowtomeetthebacklog objectives. The Team comprises all the necessary expertise, and itaccomplishestherequiredlevelandnatureofactivityeachday.Itis,therefore,cross-functional.The outputs of the Scrum process, such as the backlog list and the product

increments,areknownasitsartifacts.ThisdiscussionofScrumrevealscertaintermsandprinciplesthataregeneric

to all of theAgile sub-approaches.For thedescriptions that follow, the readercan simply refer back to this discussion of Scrum in order to compare andunderstandthem,eventhoughthetermsandtheinternalproceduresusedineachmethodologymaynotbethesame.

LeanLeanisabusinessmanagementphilosophyemployedandmadeprominentby

theToyotaMotorCorporation. It is sometimes referred to asToyotism or theToyota Production System. Since the process must take place as quickly aspossible,itspriorityistoensurethattheentiremanufacturingprocess,fromthesupplier network to the end user, entails nowasted resources or time. It is anorganizational strategy that aims at minimum expense and shortest possibledurationwithhighlevelsofcustomersatisfaction.Applying Lean toAgile is a naturalmanagement progression in enterprises

that alreadymake use of the former. It is an interesting approach, and it hassomeapparentadvantagesandsnags.On the plus side, the use of cross-functional teams enables less outlay of

expertise. This is seen as a form of waste in the Lean and Six Sigmamanagement paradigms, so themore fully staff is utilized, the better.BecauseLeanminimizes the costs of the project, it also allows for a greater return oninvestment (ROI), or a more substantial output on the customer’s availablebudget.Ontheotherhand,Leanalsorequiresconstantmonitoringoftheproject.Itis

sometimes based on statistical or other methods of assessment, and thisnecessitates the absorption of productivity time by what is essentially anadministrative function. Project managers will need to decide whether thereducedexpensesoccasionedbytheimplementationofLeanarejustifiedbytheadditional burden of work that it entails. This, coupled with the statisticalanalysisfoundationofLean,makesthepairingofLeanandAgileinappropriatefor many product development projects. Lean is best applied to continuousprocesses (manufacturing or otherwise) whileAgile harnesses the incrementalproductionmethodtoproducecustomer-tailoredresults.

CrystalCrystal is another sub-approach that was devised by one of the original

seventeencomposersoftheAgilephilosophy,AlistairCockburn.Cockburnstillmaintains a website on the methodology, and he states the following three

underlying principles in his approach to software development (or any otherproject):

Human-powered: maximizing the potential of each person on the projectteam(people-centricasopposedtoother-centric)Ultralight:theleastpossibleadministrationandauxiliaryactivities,regardlessofprojectsizeorscopeStretch-to-fit:alwaysstartoutwithalittlelessthanyouneedandexpandittorequirements(preventsdepletionor“cuttingaway”)(http://www.alistair.cockburn.us)

TheseprinciplesreflecttheAgileManifesto(seeChapter2),andinthecaseofthe third principle, also a Lean aspect. It is no surprise that Cockburn listsreadingmatteronhissitethatisalsofoundontheJapaneseJust-In-Time(JIT)businessmanagementsystem.Crystal is not one specific methodology, but rather a “family” or group of

business methods. This is a source of criticism, since many methods are notmutuallyinterchangeableandcannotbeswitchedduringthecourseofaproject.While Crystal places a strong priority on the testing of a product underdevelopment(somethingwhichhasalwaysbeenapartofsoftwaredesign),itisnot always feasible to have a teammember dedicated to that activity in everyteam. In fact, this requirement may start to breach the second, “ultralight,”principle.Oneof theprimary focusesof theCrystal setofmethodologies,however, is

thatitis“human-powered,”somethingalsoemphasizedintheAgileManifesto.

DSDMTheDynamicSystemsDevelopmentMethod(DSDM)isanoldersystemthat

hasbeenadopted into theAgilestable. Itusesseveral techniques to render theproduct according to loose Agile principles (that is, it is incremental anditerative).SomespecificDSDMtacticsincludethefollowing:

MoSCoWPrioritization

Timeboxing

(http://www.dsdm.org)

MoSCoW Prioritization refers to themethod of identifying priorities in theprojectbyusing theconceptsMust,Should,Could,andWon’t.Timeboxing isrelated to the emphasis on establishing the desired quality, expense, and timeframeof the project at its initiation, in keepingwith theAgile approach.Thismethod determines a specific time period (called a time box) for individualplannedactivitiesandfocusesonmeetingsmaller,attainabledeadlinegoals.

Like Crystal, the concentration on quality in DSDM requires a member ofeachteamtofunctionasatester.Atthesametime,DSDMisdesignedtobetheresultofdevelopmentandinputbybusinesspeopleinabusinessenvironment,soit regards value as the most important objective of the project. MoSCoWPrioritizationallowsboththeprojectteamandtheendusertodeterminewhichrequirementsoftheproductareessentialandwhichareoptional,sothattheenduserdoesnothaveunrealisticexpectationsaboutwhatthetechnologyiscapableoforwhatispossibleontheavailablebudgetoftimeormoney.Timeboxingismerelyamethodofdividingtheprojectintomanageablesegmentsinrelationtocostandtime.ApossiblecriticismofDSDMisthatitismoreadministrativethantheother

sub-approaches. It entails comprehensive studies before work is initiated, andconstant customer liaison and feedback once it has begun. Also, thedocumentation concerning the project is administered by what is known as aconsortiumandisnotavailableforfree.

XP(ExtremeProgramming)NottobeconfusedwiththeMicrosoftoperatingsystemWindowsXP(which

is also sometimes referred to simply as XP), Extreme Programmingmethodology, or XP, is the project of Agile co-establisher Kent Beck (seeChapter2).Ontheofficialsite,thedisciplineisdescribedasfollows:

“Extreme Programming is a discipline of software development based on values of simplicity,communication,feedback,courage,andrespect.”Thefollowing“CorePractices”areoutlined:

WholeTeamPlanningGame,SmallReleases,CustomerTestsSimple Design, Pair Programming, Test-Driven Development, DesignImprovementContinuousIntegration,CollectiveCodeOwnership,CodingStandardMetaphor,SustainablePace

(http://www.xprogramming.com)

XPisthemostusedsoftwaredevelopmentstrategyintheUnitedStatesatthetime of this writing. With its extensive and customer-directed planningphilosophy, aswell as its utilization of “pair programming” (a tactic inwhichone programmer tests another programmer’swork), it has a sound operationaland technical basis. The concept of pair programming is expanded by theadoptionof thecollectivecodeownership technique, according towhichmorethanoneprogrammerintheteamcanworkonthesamecode.Thistechniqueisfurtherenhancedbytheuseofuniformcodethroughouttheentireproject.Also,it is the customer who establishes quality tests for the development team toimplement.

ChapterRecap

ScrumincorporatesAgile’sconceptsofsprints,userstories,productbacklogs,andnon-hierarchicalteamorganizationintoauniqueprojectmanagementsystem.

Otherprojectmanagementmethods,suchasLean,Crystal,DSDM,andXP,maymeaningfullyinteractwithAgiledependingonthenatureoftheproject.

|9|ToolsforAgileProjectManagement

InThisChapter

Assets(Tools)ThatFacilitateAgileProjectManagement

Atoolinthisinstanceisdefinedasanyphysicalactivity,technique,orsoftwareprogram that accomplishes some purpose within the applied managementmethodology.Ifthemethodologyrepresentsthestrategythatgovernstheprojectwork,thetoolsareusedintheimplementationofthatstrategy.Forexample,ifthe project team needs to determine how many productive hours certainiterationswillrequire,therearetoolsavailabletoassisttheminthisestimation.Sometoolsareusedtoassesstheentirescopeoftheproject,fromitsoutsettoitsdeliveryofthefinalproduct,whileothersarefarmoreimmediateandnarrowtoprovidesmaller,morelocalizedsolutions.Thesetoolsareeithersoftwareprogramsorsoftwareincorporated,asopposed

toolderormoretraditionaltoolssuchaspaperfilingsystems,Ganttchartsandother hard copy planning and assessment systems.Unfortunately, some of theolder tools simply do not have the features or capacity to accommodate thetechniquesusedinAgile,sincethosetechniqueswerenotinusewhenAgilewasdeveloped.

PhysicalFiling/ClassificationSystemsThese systems work to a certain extent in a software environment. It is

unlikelythattheywouldappearasanattractiveoptiontomanyusers.Also,theyare not easy to transmit to the customer or to remote members of thedevelopmentteam.Softwareusedinassessmentsorplanningtypicallydoesnotgeneratephysicalcopiesofitsoutput,unlesstheuserdictatesotherwise.

BasicSoftwareApplicationsThese include the traditional style options such as Microsoft Excel or

OpenOfficeCalculator (or, forMac users,Numbers). These applications haveserved their purpose in the past, but modern team management and productdevelopmentprocesseshaveledtotheriseofasub-industryinthedevelopmentofsoftwarethatspecifically targets theprojectenvironment(seethediscussionofcollaborationtoolsinChapter4).Projectparticipantsmayfindthatprogramslikethesearetoolimitedormisdirectedintheirfunctionality,requiringextremeimprovisationintheiruse(whichdoesnotalwaysmakeafavorableimpressionon the customer), or even making some operations in Agile impossible toexecute.

SpecializedAgileSoftwareThesearetheapplicationsthathavebeendesignedandmarketedspecifically

for theusersofAgilemethodologies.Therefore, theyare themost suitable fordeployment in Agile activities. A number of applications have even beendevelopedbysomeofthefoundersoftheAgilemovement,suchasKentBeck’sExtremeProgramming.As with any software, there are open source (freeware) and proprietary

programs.The listbelowmentionssomeof themosteasilyavailableproducts,but it is bynomeans exhaustive and isnot intended to constitutepromotionalmaterial.Startingwith the proprietary or trademark software, the following programs

areavailableonthemarketatthistime:

VersionOnePivotalTrackerRallyScrumwiseAgileAgendaAgileBenchAldonAgileManager

AgileSoup(Androidapp)AgileZenAgileCockpit

(specificallyforScrumteams)

The previous list is not a list in any order of priority, and there are moreprogramsavailable,withmore tobe released.Someof the listedoptionsofferfree trialperiods, so interestedpartiesareadvised toexperimentwithdifferentsoftwaretodeterminewhatworksbestfortheirspecificprojectsituationbeforeinvesting.Turning to open source, which may be used at no charge indefinitely, the

following products are available for download. Once again, this is not anexhaustivelist,andusersshouldbeawarethatsomeopensourcesoftwaredoesnotcomewithanysortofguarantee.

Agilefant(acloudserverthatprovidesadownloadableversionoftheprogram)ClearworksExpressFireScrum(Scrum-specifictool,thereareatleasttenopensourceScrumtoolsavailable)PlanigleXPStudio(NB:thisisNOTMicrosoft’soperatingsystem)XPlanner+RetrospectivaScrinchPPTS(ProjectPlanning&TrackingSystem)

ChapterRecap

BothcommonofficesoftwareandspecializedAgilesoftwareareavailabletoassistwithAPM.

|10|PracticalImplications

InThisChapter

GoingBeyondTheorywithAgileHowAgileCutsCostsGettingYourTeamtoBuyInHowAgileCanImproveMarketPosition

ThischapterexaminesthepracticalissuesthatariseinsituationswhereAgileisusedtomanageaproject.Theissuesarecategorizedunderthreebroadheadings:costs, staff, andmarket implications.These categories seem to be appropriate,given that Agile focuses on and seeks to optimize these aspects of projectmanagement.

ExpenseStructureAny project usually involves expense of some kind. Whether it is the

cultivationofbeans inplasticholders foranelementaryschoolexerciseor theconstruction of a bridge over a river, expenditure has to be monitored, andusuallypredicted,beforeworkbegins.Agileservestoreduceorrestrictcostsintwoways;oneofthemisverygeneralinitsoperation,andtheotherismoreaninternalfunctionofhowtheprojectismanaged.It has already beenmentioned that, as opposed to the more traditional and

premeditatedWaterfall philosophy of “plan first, do next, see if the budget ismet,”Agilefirstestablishesthebudgetandthentriestocontainthescopeoftheprojectwithinit.ThispointofdepartureisthemoregeneralofthetwowaysinwhichAgilelimitstheexpenseassociatedwithaproject.Thecustomerorotherproject commissioner is assured of two things: first, that they won’t have tospendmore than they are prepared to, and second, that even if their availableresourcescannotsupporttheultimatedesiredoutcome,theywillatleastbeleft

withsomethingconstructivetoapplyintheirorganization.Thisalsoimpliesthatthecustomerisnevergoingtobepresentedwithafinal

result that isnot satisfactory tosomeextent.Thiseventualityhasalreadybeenoutlined in a preceding chapter. There are some horrific examples of thishappening inmega-industry, instanceswhere the development teammay havesubscribed entirely to the project brief and even overrun the budget and timeframe,butdeliveredaproductthatwasuselesstoitsenduserorafailureinitstargetmarket.The second and more microcosmic manner in which Agile cuts costs is

throughitsuseofqualitymonitoringandassessment.Thishappensonaconstantbasis,especiallyinmethodologiessuchasXPorCrystal.Buildingahouse takesplace according to apreapprovedblueprint.But it is

perhapsmoresensibletohavethehomeownerspresenttoshowthemthevariousstagesofconstruction,sothattheycanrefineortweaktheplansastheydesire.In fact, people who commission the construction of their own homes usuallytake a very intense interest in the process and even resort to their ownprocurementofmaterialsorspecialistartisansif theybelievethattheyareabletodothejobmorecheaplythantheprimarycontractor.This,then,isoneofthestrengthsofAgile.

StaffIssuesTheScrumstyleofholdingmeetingsmayseemimmatureorshowy.However,

it does advertise anattitudeofurgency toobservers, suchas customers.Teammembersareencouragedtoadopt thesentiment that thecustomer’sdeadlineisimportant and that they need to approach their taskswith a sense of urgency.This is in contrast to premeditated Waterfall projects that sometimes extendbeyondtheirinitialdeadlineandwhere,inthefinalanalysis,someoperativesareexposedasrequiringaninordinateamountoftimetocompleterelativelysimpleactivities.Thisdestroyscustomersatisfactionanddistortsperception,sincesomeof those operativesmay have been paid according to the time that they spentworkingontheproject.Toreferback to the immigrants’homeconstructionsiteoncemore, imagine

thelaborersarrivingatthesiteinthemorning.Theyfirstsitaroundforaboutanhourorninetyminutes,drinkingcoffeeandchattingaboutpersonalaffairs.Thentheysluggishlystarttochopintothehardgroundtoexcavatethefoundation,stillconversing about their marriages, finances, and sports teams. When the siteforemanyellsat themtoshowsomeenthusiasm,theyreplythat theystillhaveplenty of time to finish the job. Now compare that scenario with a sprintmeeting. It is obviouswhich approach businesspeople, and society in general,wouldratherseeinactionwheretheirmoney,marketshare,orotherinterestsareatstake.Sometimes project or business management systems necessitate the

introductionofasupervisoryorfacilitatorrole,whichisnotaninherentpartofthe organization itself. This role is either partially or entirely dedicated to theimplementationofthesystem.Itsjobtitlemayevenreflectthatcapacity.Asanexample, in Scrum there is the ScrumMaster, who does not participate in theconcreteprojectlaborbutisnotentirelyateammanagereither.Therearecertainissues related to this phenomenon of dedicated, supplementary roles, whetherfull-orpart-time,thatneedtobediscussed.First, the person who occupies the role needs to have an above-average

understanding of the system. They need to be trained in its application andprocedures. Once their role is implemented, they may not be available toperform their usual duties.Thismaybecome the focusof envyor antagonismfromotherstaff,since“So-and-soisneverattheirdeskthesedays,”or,assomemayask,“Howcometheygettogotoalltheseminarsandstuff?”This type of hostility to implementation needs to be alleviated as soon as

possible.Otherstaffmembersneedtorealizethatthesystemisbeingusedforaspecificpurpose.Inintroducingtheplantothem,theconcrete,anticipatedROIoradvantages forcustomer service shouldbeexplained indetail, in terms thattheycanunderstand.Theselectionprocess for the facilitator shouldalsobeastransparent as possible, possibly on a voluntary basis. It should be obvious toeveryonewhyacertainpersonisbeingusedinthatrole,theextentofhisorhernewexpertise,andwhythatroleisnecessary.Sometimes,employersinstituterewardsorincentivesforstaff.Thisisharder

toaccomplishwhentheoutputofacollectivetaskdependsonthecontributionofanentireteam.Measuringtheperformanceofindividualmembersisnotonlycomplicatedattimes,butalsopotentiallysensitive,especiallywhentheteamisengagedinanabnormalorinterimendeavor.ThisisafactortotakeintoaccountinselectingandinstitutingtheappropriateAgilemethodology.There is also the usual resistance to newmethods, especiallywhere new or

atypical techniques are involved. Standing during meetings and using oddterminology are sometimes too hard for the less flexible (or more dedicated)staffmembers to accommodate themselves to.Once again, the benefits of thesystem’simplementationneedtobeemphasizedatalltimes.Anotherreasonthestaffneedtobeproperlyinformedaboutimplementationis

thattheunderstandingofitsimportanceempowersthemtomanagetheprocessthemselves, either partially or entirely.TheAgile system advocates the use ofstaff under what is largely their own supervision. The prime example of thissentiment is seen in the Scrummethodology, in which no outside person hasauthority over how the Development Team manages and executes the actualproject labor. The Teammanages itself,mostly, and the ScrumMastermerelyprovidesrelevantinformationandupdatesontheprogressoftheproject.When staff take ownership of a situation or project, they are easier to

motivate,sometimesrequiringnopromptingatall.Their levelofdedication tothe success of the initiative is much higher, and they are likely to be morecreative in their input, since they are not blindly following instructions orperformingtoabareminimumstandardsetbysomeoneelse.Anincreasedsenseofresponsibilitytranslatesintogreaterattentiontoqualityandmorerespectfordeadlines, which is harder to achieve in the traditional Waterfall paradigm,wheretheprojectmanagerhasgreaterorevenabsoluteauthorityandtheprojectscopehasalreadybeenfixedatitsoutset.Apossibleproblemattachedtotheprincipleoftheexceptionallyempowered

teamisthatitsinternaldynamicsmaysometimesobstructitsprogress.Becauseofitscross-functionalnature,somemembersmayhaveoverlappingoridenticalskillsets,butsubscribetodifferentapproacheswithinthesamediscipline.Thisis obvious territory for dispute and/or paralyzed communication. Another

possibleobjectionisthatsomeofthemethodologies,XPinparticular,mightrelyon pair programming (see Chapter 4). Not everyone in the software industrysupportsthistechnique.However,giventhesuccessofXPgenerally,thisseemstobearelativelylesssignificantsourceofconcern.

MarketImplicationsAccording to Highsmith (2004), this is one of the focus areas of theAgile

movement. Agile’s emphasis is on the development and introduction of newproducts, so the market is better served by a faster turnaround time on suchintroduction, either in response to its stated needs or as an improvement uponexisting options. Enterprises sometimes also have to react in a short space oftimetothesuddenreleasestrategyofacompetitor.Agile allows for speedy development procedures. Since the process of

developmentandrefinementisexecutedinstagesoriterations,thecustomercanprogressively perfect the product or limit its scope, thus enabling a moreimmediateintroductiontothetargetmarket.Atthesametime,theycanreleasean undeveloped version of the product, butmarket it as a new advance in theindustry,thenaddtheremainingstagestolatereditions.Theconstantinvolvementofthecustomerinthedevelopmentprocessresults

in greater satisfaction on their part. If they are able to observe the project’sprogress as it happens, and if they are providedwith regular and spontaneousfeedback, they may experience the service provided by the developer assuperior. Adherence to differentiated time frames is always appreciated, as isstayingwithintheapprovedbudget.

AgilePointsofViewwithinanOrganizationWhen implementing Agile within your organization, the system will be

perceived differently by various members of the organizational hierarchy. IfAgileisimplementedproperly,thenteammembersthroughouttheorganizationstandtobenefit.Executive levelmanagerswill appreciate the transparency and efficiency of

Agileprojects.Usingburndowncharts(Scrum),productbacklogs,roadmapsand

other Agile tools, executives can obtain quick high-level insight into projectstatus.ExecutivesalsoappreciatethatAgileisbuilttobeflexibleandthateachsprintdeliversnewfunctionality.Iftheneedsofbusinesschangesuddenly,thenongoing projects can reflexively change as well. Moreover, since functionalproductsarebeingdevelopedconstantlyduring thecourseofaproject, there’smoreopportunity to takeproducts tomarketquickly andonanongoingbasis.Agile can also facilitate overall higher product quality through the rigorous,ongoingtestingmechanisms.Onesuchtestingmechanismis“test-drivendevelopment”orTDD,whichhas

been steadily incorporated into Agile ProjectManagement, particularly in thefieldofsoftwaredevelopment.TDDisastyleofcodingwherebyprogrammerscreate tests that will intentionally fail until a feature has been properlydeveloped. The tests are preserved, cataloged, and continuously implementedthroughoutproduction.TDDisused tominimizeproductdefects,whichkeepsexecutiveshappy.For consumers,Agile’smain benefit is, again, its inherent flexibility. Since

functionalityisreleasedinchunks,productscangotothemarketinstagesandcustomerfeedbackcanbereadilyincorporatedintotheongoingdevelopmentofaproduct.ThislevelofdynamiccustomizationforthebenefitofthecustomerisnotofferedbytheWaterfallmethod.Developmentteammemberswillappreciatetheinfluenceandautonomythey

gain throughAgile ProjectManagement.DuringAgile projects, it is the teammembers who prioritize features and determine the goals for their sprints. InScrum, the Agile team configuration includes a specialized party, the ScrumMaster (separate from the project manager), who acts essentially as a teamadvocatetoremovebarriersandfacilitatecommunicationwithintheteam.

ChapterRecap

ImplementingAgilecanrequirealeapoffaith,andyouareguaranteedtoseesomeresistanceinyourorganization.

BenefitsofAgilecomeintheformofloweredcosts,morerapidandresponsivemarketengagement,andamoreautonomousandempoweredworkforce.

|11|BriefAgileCaseStudies

InThisChapter

ApplyingAgileinthePrivateandthePublicSector

GEOurfirstcasestudy,GE(formerlyknownasGeneralElectric),showshowthe

system can be deployed in an industry that is not exclusively centered on thedevelopment of software, but one that is outside of the pure IT industry. Ofcourse, large corporations usually have an IT department and requiredevelopment of their ownproprietary software, so that iswhereAgile ismostlikelytobeused.OneexampleofhowGEhasusedAgileisinitsfinancedepartment.There,a

new software infrastructure was required for crunching numbers so thatoperatives would be better able to reach informed decisions. Essentially abusiness analysis intervention, the new software was required to gather datafrom the existingplatformsandmake it accessible to thenewprogram.Usingtraditional methods, the estimated turnaround time for the integration processwasbetweeneighteenandtwenty-fourmonths.The integrationvia thenewsoftware,whichwas executedbyGE’sown in-

house IT department using Agile, took all of one year, inclusive of itsimplementation.Thistypeofintegrationisnotuncommoninlargecompanies.Someofthem

maintain enormousdatabasesof customer information and transaction records.Shiftingtheentirearchiveofdatatoanew,moreefficientsystem,oronewhichhas expanded capabilities, may be a matter either of reducing expenses or ofnecessityduetoachangingmarketenvironment.Thesoonercompaniesareableto conclude the integration, the sooner they canmeet the new expectations oftheircustomersorstartsavingoncosts.By cutting a year off the development time of the software, GE not only

preempted an additional year’s use of their prior system, but also eliminatedtwelvemonthsofdevelopmentalexpense.ThiswasmadepossiblebytheAgile

methodology.Themoretraditionalapproach,withafixedprojectscopeandanestimated budget and time frame (such as eighteen to twenty-four months),wouldhaveresultedinatleastanothersixmonthsspentindevelopingthenewsoftware.Therealsowouldhavebeennoguaranteeas to itsabsolutesuitability.Agile

delivers satisfactory pieces one at a time, resulting in an end product that isstableandfunctional.Using amore conventionalmethodology, the summary release of the entire

new software package would have necessitated a more sudden andcomprehensive integration process, which is not only institutionally traumaticbutcausesupheavalamongstaffwhohavetobetaughtitsuseenmasseonanimmediate,acceleratedbasis.TheyalsohavetowasteproductivetimewhiletheIT personnel work overtime transferring all the data to the new platform andtryingtounderstanderrorsandhowtoresolvethem.Someoftheseerrorsmaybesystemicandmighthavebeenavoidedthroughanincrementalapproach.Theexamplecited in thischapter isn’t theonlyareaof theenterprisewhere

GE has used Agile. The company has also instituted the methodology in itsIndustrialInternetrangeofsoftwareproductsforenergyproducers, theGEOil&GasEngineeringInitiative,whichhasbeenpubliclyreportedtomakeuseofAgilesoftwaredevelopment.

HomelandSecurityThe U.S. Department of Homeland Security (“Homeland Security” or

“Department”) is an example of a government organization that hasimplemented Agile in its software development activities. As the federalauthorityoninternalsecurityandborderintegrity,HomelandSecurityprocessesmatterssuchas immigrationand the identificationofcitizens. Ithasamassiveuserbase(theentirepopulationoftheUnitedStates),andthestandardofitsdataneedstobeimpeccable.Atthesametime,thesystemusedtoprocessandstorethatdataisrequiredtobeentirelysecureatalltimes.The quality of the data and the security of its archiving depend on the

sophistication and reliability of the software used by the Department. It is

understandablethatHomelandSecuritydevelopsitsownsoftware,usingitsownIT resources, since national databases are highly sensitive and should not beentrusted in their entirety to outside contractors to maintain (even thoughoutsourcingisanexistingstrategy).In2013,theDepartmentstartedtouseAgilein its softwaredevelopment (in addition to cloudcomputing), in an attempt toimprovetheturnaroundtimeonnewprojects.

ProjectDeliveryHomelandSecurityhasanannualbudgetofapproximately$6billion,with

about15percentofthisbudgetspentonIT.Agilewasimplementedinresponsetoanidentifiedweaknessinthebudgeteddeliveryofnewsoftwareproducts.In2013,aboutoneinthreeITprojectsexceededeithertheirbudgetortheirdeliverytimeframe.ThisconcernwasaddressedbyinstitutingAgiletechniques.Theemphasisoftheimplementationhasbeenontheuser.Thedevelopers

liaisewithusers,discussspecificinstancesofuserexperience,andthenallowtheuserstobeinvolvedinthetestingofthenewsoftware.Inthesensethattheenduserparticipatesdirectlyinthedevelopmentprocess,

thisisanimportantmethodofempoweringmembersofthepublicintheexpenditureofgovernmentresources.Theinternalorcitizenaffairsdepartmentinanycountrymaybeseenasslow,excessivelybureaucratic,orculpableintheunnecessaryabsorptionofpublicfunds.Throughengagingthepublicinthecreationandimplementationofnewsystemsandprocedures,theelectoratemaybemoreamenabletothesentimentthattaxrevenueisbeingspentwiselyandthattheservicetheyreceiveistheoptimumpossibleexperience.

GovernmentContractsThecompetitionforgovernmentbusinessisatraditionalaspectofcapitalist

economies,andproposalsforgovernmentprojectsaresometimesfiercelycontested.HomelandSecurityisnoexceptiontothistypeofattentionfromprivatebusiness.Asfarassoftwaredevelopmentcompaniesareconcerned,theDepartmenthasestablishedaninnovativenicheuseoftheAgilemethodologyinawardingcontracts.BecauseAgiledevelopmenttakesplaceiniterations,itispossibletoassign

eachsprinttoadifferentcontractor.Rememberthateachsprintdeliversausablephaseoftheendproduct.Theentireprojectcanthenbespannedoveralongerorshorterperiodoftime,postponed,orsuspendedindefinitely,withoutthecontractorbeingabletoopposeanysuchdecision,orevensecurepermanenttenureinprovidingthedevelopmentservice.Thishasadvantagesforgovernmentinthatanunsatisfactoryserviceprovider

canbeabandonedaftertheirfirstsprintinvolvement.Budgetarydisciplineandtheflexibleprioritizationofnewproductsarealsoeasiertoaccomplish.ThesearetwooftheprimarybenefitsoftheAgilemethodology,asillustratedbyitsapplicationinthegovernmentsphere.

|12|ExtendedAgileCaseStudyNo.One

InThisChapter

ACaseStudyinAgile

Yahoo! is amultinational firm known for its web portal, Internet search, andrelated services.With a $32 billionmarket cap, the company can certainly becalled a “large enterprise.” What follows is the summary of a case studypresentedbyYahoo!AgilepractitionerGabrielleBenefield,whichdescribestheprocess Yahoo! took when implementing Agile. The proof here is not in thepudding, but in the fact that Yahoo! still retains the Agile method of projectmanagementdespitethechallengestheyfacedduringtheinitialimplementationstages.

ImplementationIntheenvironmentthatistheInternet,theonlyconstantischange.Yahoo!,a

company that provides products and services to more than 500 million usersworldwide, knew the importance of remaining flexible and adaptive whenbringing products to the global, web-based market. Benefield joined thecompany in 2005 to propel their adoption of Agile ProjectManagement. Thegoal, startingwithScrum,was to utilize the lightweight framework thatAgilemethodsprovidetocreate“collaborativeself-organizingteams”that“effectivelydeliver products to market.” While the following case study outlines manychallenges Yahoo! faced, Benefield considers the implementation a success,citing“tremendoussuccessesandvaluablelessonslearned.”Yahoo!grewtremendouslyfromwhatwasessentiallyastartupcompanytoa

largeenterprise.In2002theybegantopursueastandardprocesstodeliverbetter

products faster. This initiative was based on a program called the ProductDevelopmentProcess(PDP),aWaterfall-typeprogramthathadbeenmandatedby Yahoo!’s management.What Benefield found was that many of Yahoo!’steams and divisions either ignored the process entirely or insteadmanaged toretroactively manufacture participation when they had in fact abandoned theprogram’smethods.Thoseteamsthatadheredtotheadministration’smandatedapproachfound theprocessmoreahindrance thananasset.Afterdebating thetop-downmandateofAgileor thebottom-upgrassrootsmethod, theenterprisechosetoimplementtheprogramwiththesupportoftherank-and-filefirst.Thefocusesofdysfunctionweretheprojectandteammanagementportionsof

operations. There were significant shortfalls in the areas of planning, projectmanagement, releasemanagement, and team interaction.While they were notlaunched simultaneously, Benefield cites a wish to have launched AgileengineeringprotocolsandprojectmanagementScrummethodsatthesametime.Thisservesasacautionarytale;eventhoughtheapproachwasnotatop-downinitiative,itcouldhavebenefitedfromawiderscope.Initially,fourteamsvolunteeredtotestthenewAgilemethodsandsharetheir

experienceswiththerestoftheorganization.Theirbusinessunitswerediverse;they ranged fromproducts for customers (email andphoto sharing) to internaltools (small businessmanagement). Initially the volunteers committed to fourdirectives:

1. TocompletecomprehensiveScrumtraining

2. To work with outside Scrum coaches, especially during the periodencompassingthefirstseveralsprints

3. TousethestandardizedScrumprotocoloutlinedbyScrumadvocateKenSchwaber

4. Tocompleteatleastonesprint

InkeepingwiththeiterativenatureofScrumandAgile,volunteerteamscouldoptoutoftheprogramanytimeafterthefirstsprint.Feedbackaftertwomonths

waspositive;managerssawresults,andteammemberslikedthesystemandtheexperience.This led to aword-of-mouth circulationof theprogramwithin theorganization,andthepraisegeneratedencouragedotherteamstoexpressinterestintheAgilemethod.In lieu of using external coaches, the enterprise shifted to using an internal

Scrumcoachingteam.Thepurposeofthisteamwastopromotethebenefitsofthe implementation of Scrum within the organization as well as to providetraining, coaching, and support for the teams using Scrum. This includedensuring that key events and programs were followed, such as theaforementioned daily stand-up meetings, iteration planning, and sprintretrospectives.Oneof the functionsof theAgileProjectManagement system is to identify

deficiencies within an organization. As this happened for Yahoo!, who wasmaking the change from a mandated Waterfall system to a grassroots Agilesystem, Benefield and her team started addressing issues as they arose andmakingthefixesavailableforall teams.Thismeant that inpractice,asolutionforone teamwasasolution forall teams.ThesesolutionswereAgile-minded,including reductions in bureaucracy as well as improvedmethods of resourceplanningandportfoliomanagement.

TrackingProgressBenefield and her team knew that the only method of measurement would

have to be clear and accurate. Across the organization, teams who hadimplementedtheprocessweresolicitedforfeedback.Thosewhoparticipatedinasurveyonthenewly-implementedprogramsreceivedcustom-printedT-shirts.Thisincentiveprovedeffectivebutmaynotbeagreatfitforeveryorganization.Itistheresponsibilityofmanagementtodeterminehowtobestincentivizetheirworkforce. In this case, the overall response ratewas a surprising 71 percent,fourteenpointshigherforScrumpilotteammembers,andtheresponsesrevealedboth thehugebenefits and the resistances tochange. Inaddition tocirculatingthe promotion of Scrum, these surveys bolstered other teams to get on boardwiththeAgilemethod.

SupportfromManagementFeedbackfrompeerswasdeterminedtobethebiggestfactorinmanagement’s

comfort level with Scrum’s adoption progress. The members of the company(theoriginalauthorofthiscasestudyincluded)whoweretaskedwithexpandingthescopeofScrumwithintheorganizationtendedtobriefmanagersmostlyonthe benefits rather than themechanics ofScrum.This approach reinforced theproblematic trend of general managers over-focusing on results while under-focusing on methods. Benefield clearly indicates that this led to issuesconcerning the ability ofmanagement to support teams thatwere dedicated tothe adoption of Scrum. It is important to remember that the transition from amandatedWaterfall program to a lightweight adaptivemethod is a significantchange; the fact that Agile methodologies remain relatively newer and moreexperimental contributes to the resistance that somemembers ofmanagementwillinevitablyexhibit.

CoachingOnce the frameworkwas inplace for thevolunteer teams,Benefield’s team

implemented their engagement model, which allowed them to coach severalteamseffectively.Benefieldstatesthat thismodelwassensitivetothefact thatnotwoteamswouldfacethesamechallengesandnotwoteamswouldprovidethe same solutions. This spurred a waiting period for management that wasbasedontheneedforScrumcoachestolearntheindividualneedsofeachteamthey coached. Learning this information allowed coaches to tailor the Scrumarchitecturetofittheneedsoftheirindividualbusinessunits.CoachingalsomeantnotforcingScrumdownemployees’throats.Scrumwas

reservedforthosewhovolunteeredtotakeonthechallengesofadoptingthenewproject management program. The initial implementation was organized asfollows:

InitialDiscussion

MeetwithpeoplewithintheenterprisewhowereinterestedinScrum,and

discussbenefitsandchallenges.Scheduleoverviewsforkeymembersoftheteam.Organizetrainingandcoaching,includingScrumMastertraininginconjunctionwithteamtraining.

Preparation&Training

WorkwithProductOwnertodevelopproductbacklog.Conducttwo-dayScrumtrainingforthewholeteam.

Coaching

Forthefirstsprint,theAgilecoachwouldfacilitatethefollowing:»Firstsprintplanningmeeting»Firstsprintreview»Firstsprintretrospective

For the second sprint, the Agile coach would be present to mentor theScrumMasterduringmeetings.Duringthefirststagesofthisprocess,theAgilecoacheswere infrequentcontactwith the teams tokeep theiradherence to theprocessontrack.Coachesandfacilitatorswouldworkwithotherteamsaswellto accelerate learning, spot issues early, and pursue improvement. Benefieldadmits that the first threemonthswerechallenging,but the teams thatadoptedScrum used it to begin to self-organize and were ready for more advancedtraining.

ScalingwithintheOrganizationAttheendof2005Yahoo!hadtwenty-fiveteamswhowereusingtheScrum

processconsistently.Eighty-fourpercentofteammemberssaidthenewsystemwasanimprovementovertheoldermethodstheyhadbeenusing.However,aninternalobstaclearose:abudgetarycyclechange forced theentirecompany toproducemore resultswith fewer resources.Thiswasachallenge forBenefieldandherteams,andthecompany’sresponseisagoodexampleofwhattoavoid

whenimplementingAgile.Other teamswithin thecompanyhadheardabouthoweffectiveScrumwas,

either through internal channels or through other professional channels. Withlittle knowledge of implementation or procedure, the individual business unitsdeterminedthatScrumwouldbeacure-allfortheirbudgetarywoes.Insteadofusing theprofessional coaches,many team leaders resolved to learnScrumontheirown,which led to inconsistencyandpoor interactionbetweenteams.Thenumber of teams implementing Scrum,with andwithout the support ofAgilecoaches,rosebyafactoroften.Benefieldandhercoachescouldn’tkeepupwiththetrainingprogressofeachteamandasaresulttheentireprogramwasatrisk.Teams were denied coaching on the basis of availability but moved forwardregardless.Benefield concluded that while Scrum is simple and appears simple, it can

causequiteabitofchangewithinateamandcanchangethedynamicbetweenteammembers.Not everyone is receptive to change, a factwe all knowwell.Theroleofcoachesandstandardizedtrainingistohelpdevelopteamsthroughthe transition period inwhich peeling off layers of administrative control canhighlightareasofpoorperformanceanddysfunctionwithinateam.Teamsoftenblamed the Scrummethodology as the cause of their challengeswhen in facttheir reluctance to adoptnewprocesseswas the root cause.Another issue thatarose—andthisisverycommoninorganizationsthatattempttoutilizeAgile—isthattheteamclaimedtohaveadoptedScrum,toptobottom,andtobemakingexcellentprogress.Acloserlookattheirmethodsrevealedthatwhattheywerecalling Agile was in fact a series of mini-Waterfalls. This, too, reflects theunwillingness of many people to discard old habits. These challenges can beovercomewithfocusedtrainingandtheuseofAgilecoaches.

ScalingtheBudgetExperience showed again and again that the teams that saw focused and

dedicated training also saw the most success. In this period, the coaches stillcould not adequately train the growing number of teams that were requestingassistanceintheiradoptionofScrum.Thoughtheimplementationprogramwas

receiving funding from an internal professional development organization, thedemand for training requiredmore coaches than the programcould afford.Tomake her case for additional funding, Benefield implemented a program togather metrics concerning the effectiveness of the teams that had receivedadequatecoachingcomparedtothosethathadnot.Thefirststepinthisprocesswastoinitiateinternalcasestudiesandsurveys.

The surveys found that there were significant differences in satisfaction andperformance between the teams that had coaching and those that had not.Unsurprisingly, the teams with a solid Scrum foundation benefited from thecoachingandthrived,whileteamsthathadapoorfoundationalbaseorlittletono coaching had many ongoing challenges and difficulties. While top-levelmanagementwas interested in this data, theyneededmore evidence to releasethefundsformorecoaches.Once an effective measurement system was devised, Benefield’s surveys

found millions of dollars in savings and massive increases in productivityranging from 0 percent to nearly 200. The average productivity increase wasabout 34percent.Managementwas thrilled. Interestingly enough, that numberhas stayed fairly consistent over time as the programhasmatured. In 2007 (ayear later) theaverage recorded increase inproductivitywas39percent.FromthisprocessBenefieldgainedsomevaluableinformationabouttheuseofScrumcoacheswithinYahoo!;remember, thisdata isspecific toYahoo!andmaynotbeapplicabletootherimplementationscenarios.

OneAgilecoachcancoachabouttenteamsperyear.Each team averages ten people (making the ratio of coaches to staffmembers1:100).Basedonsurveyed results,averageproductivity improvementswereabout34percent.

RefiningtheProcessOnce themoneymaterialized,more coaches could be implemented and the

program could be scaled effectively. The expanded coaching program also

allowed some mistakes that had surfaced to be corrected along the way.Benefield’s teamhas continued to promoteAgilewithinYahoo! by creating aculture around it. Promotion efforts include T-shirts and internalcommunicationstorecognizethesuccessstoriesgeneratedbyotherteamswithinthecompanyandtopromotefurtheradoptionoratleastopennesstoAgile..Thisisawisemethodofadoption:bottom-upinsteadoftop-down.

WhatWeCanLearnOrganizationscontemplatingtheimplementationofAgilecanlearnquiteabit

fromthiscasestudy. It isanexercise inwhat todoasmuchaswhat toavoid.MostimportanttotheentireprocessisthatYahoo!’simplementationwasdonefromthebottomupwiththesupportandacceptanceoftheemployees,notfromthe top down as a mandate from the higher level management. The latterscenario is self-defeating in the sense that the creation of an environment inwhichteammemberscanfeelempoweredclasheswithamanagerialassertionofcontrol.A pitfall, however, was the slow expansion of the coaching team.

Organizations need to understand that sweeping changes cannot be effectiveunlesstherereallyischange.Coachesrepresentastructuredandguidedpathtofacilitating that change, and Yahoo!’s ignoring of their role in the processcreatedmoreworkandexpenselater.ThiswasoutofthehandsofBenefield’steam,butathoroughunderstandingbyallrelevantmembersoftheorganizationwouldhelpimplementtheprocess.GabrielleBenefield’s teamatYahoo!worked toadoptScrumacrossa large

organizationbyfittingtheorganizationtotheprogram.Thefollowingcasestudysummary demonstrates the Intel Corporation’s Agile implementation processand how they stretched Scrum to fit their organization’s particular needs andprotocols.

ChapterRecap

Byanticipatingresistanceandofferingincentives,Yahoo!steadilyconvinceditsemployeestobuyintoScrum.

|13|ExtendedAgileCaseStudyNo.Two

InThisChapter

ACaseStudyinAgile

Withannual revenuesof$38.3billionandemployeesnumbering86,300at thetime of this study, Intel Corp. is a world leader in the production ofmicroprocessors, motherboard chipsets, and flash memory products. The casestudy’s focus is on the Oregon and Pacific (OAP) product developmentengineering(PDE)teamandtheirimplementationofAgileProjectManagementmethods. The team needed to implement these new methodologies acrossmultipleteams,sites,cultures,andenvironments.OAP’sworkproductwasatestprogramdesigned to run automatic testing equipment (ATE).This is uniquelychallengingbecausenooff-the-shelf programming couldbeused; theprogramusesaproprietaryoperatingsystemand interface languages.Prior to theAgileadoption process the team suffered from a number of issues including highturnover rates, poormorale,missed schedules, and insaneworkweeks. Thesefactors alone present challenges, but additionally challenging to the AgilemindsetwasthestrongWaterfallculturethatexistedatIntel.Intel decided to implement Scrum at the beginning of a project, because

duringthelower-stressinitialstagesoftheprojectastrongfoundationcouldbedeveloped, and the best practices developed there could be transferred to laterstagesintheprocess.

Preparation&InitializationThefirst transitiongroup includedsix teamswithnumeroussub-teams. Intel

reachedouttoDanubeTechnologiesInc.asaScrumimplementationvendorand

began the process of transitioning to theAgilemindset. Initially, twentyor sogroup and technical leads attended focused training in a two-day workshop.Teamleadersagreedtocommittoathree-monthpilotperiodduringwhichtheywouldusetheirtraining“asis”insteadofattemptingtofitittotheorganization.This is an interestingmethod forpromotingadoption, andas theauthorof thecase study, Pat Elwer, notes: “Even though the agreement was there, I couldalready sense a split in the organization into ‘pigs’ and ‘chickens’ in termsofsupporting Scrum.”10 Working with Scrum consultants, Elwer determined toadvance the following key elements of the ScrumMaster position so as not tocreateconflictoruntowardfeelingsabouttherole:

The ScrumMaster role was valued in performance evaluation as having thesameweightas“realengineeringworkratherthanadministrativeoverhead.”

TeammemberswhobecameScrumMaster did not have a technical stake intheteam’sduties.

These stipulations are unique to Intel’s circumstance but helped smooth theprocessbyeliminatingconflictsofinterestandpromotingthevalueofthenewScrumsystem.Attheendofthethree-monthprocess,thenumberofteamstobemanaged grew from six to seven, with an eighth volunteering to implementScrum.Thechallengethenbecamescalingtheprogramacrosstheorganization.UsingascalingmodelthatDanubeprovided,alongwithbestpracticeslearnedinthepilotperiodandinputfromteams,theprogramencompassedtwelveteams.AgainwithinputfromDanube,theteamsdevelopedmethodsformanagingandfostering dependencies between multiple teams as well as inter-teamcommunication.Whattheteamslearnedfromthisprocesscanbesummarizedasfollows:

Adoptionismoreimportantthanstrictadherence.Volunteerismisakeytosuccessfuladoption.Self-organizationisakeytoandaresultofsuccessfuladoption.

In the spirit of promoting adoptionover adherence, deviations from the “bythe book”Scrummethodswere discussedbut not givennegativeweight.Thismethod also promoted “outside the box” thinking and accelerated the learningcurve for all teams, aswell aswhatEwer refers to as “unity, not uniformity.”Visibilityalsobecameacriticalcomponent in the implementationprocess,andchannelsweredevelopedtoallowteamstodiscusswhatworkedaswellaswhatproved to be dead-end methods. To fit Scrum into the Intel culture andenvironment theprocesswasadjusted,andwhatfollows isabriefsummaryoftherolesthatkeyteammembersplayedintheprocessandtheprogram.

By the end of the first year, Scrum was fully rooted in the company’sdecision-making process and was a framework for planning and resourcemanagement.Remember,however, that thedevelopmentwasstill in the initial“stress-free”stages.Thesoftwarewasonlyinteractinginmodels.ThenextstepwastestingAgileintheexecutionphaseoftheprocess,inwhichthestakeswerehigherandthestressonstaffandprocesseswasmuchhigher.

TheNextStepElwer says there were many surprises when the rubber met the road. This

periodintheproductionphaseiswhenthesilicondevicesarriveandinformationmustbegatheredaboutthespecificpaththeprojectwilltaketowardthefuture.This is adifficult time inproductdevelopmentengineering. In thisperiodoneScrum team abandoned the new process entirely and reverted to Waterfalltechniques for project management. Some other Scrum teams disbanded,deciding that they were finished attempting to use the new system. TheremainingteamsclungtoScrumvigorously,ifnotveryeffectively.Thoseteamshadbeenusingtwo-weeksprintsbutfoundthemimpossibleandshiftedtoone-daysprintsinstead.Thereweredailymeetingsthatplannedforthenextdayandreflectedonthepreviousone.InthiswaytheycollapsedScrum’sprescribedfourmeetingsintoasinglemeetingunderthepressureoftheproductionstage.Thesemeetingsdemonstrated thecorevaluesofScrum,according toElwer.

Here could be observed business value prioritization, team sizing, adhering tothe backlog, peer updates, implementing process improvements and reviewingtheworkproduct.Thesepracticesgainedpaceastheteamuncoveredmoreandmore informationabout thedevices intowhich theyneeded to implement theirsoftware.The teams that didn’t give up onScrum remained intact andmovedthrough the process, eventually expanding the sprints back to the two-weekstandard.

PreparingforManufacturingAs the testing yielded a more and more bug-free program, manufacturing

loomedon thehorizon.However,Elwerwas still strugglingwith the effectiverelay of informationwithin the organization.Also at this time, in response toexistingissuesinthesoftware,anumberoftaskforceswerebeingdeveloped.AtIntel, a task force is agroupof expertswhoare called todropeverythingandaddress specific issues within development. These groups are effectivecombatantsagainstcrisis-leveldevelopmentalissues,andtheirpotencywasnotlostonElwer.Thebiggestissuewashowtoincorporatethetask-forceapproachwithout changing the overall organizational structure.At this stage, the teamsthathadretainedScrumthroughthedevelopmentalprocessweretooinvolvedinthe work to restructure effectively. The answer was Scrum “feature teams.”Adoptingthetask-forcestyle,thisgroupoftechnicalexpertsworkedlikeataskforcebutmaintainedslotsinotherteamstogivemembersacross-functionalityaswellasa“home”withintheproject.Theyservedonfeatureteams“onloan”fromtheirhomeScrumteamsandrepresentedhighlevelsofcollectiveexpertise.Theprogramwasasuccess,notonlywiththemembersoftheexistingteamsbutalsowithmanagement.Elwer makes a list of what went well and what didn’t throughout Intel’s

adoptionofScrum.

WhatWentRight

1. Theuniquenatureofthe“startingfromscratch”codingmeantthattherewas little room for error. Tests were often done on live silicon unitsinstead of in software models. This meant that a strong focus wasdevelopedonwritinggoodstoriesandwritinggoodacceptancecriteria.Good stories meant good backlogs, and good backlogs meant that thesprintsprovidedtheirintendedresults.A“pairreview”processwasdevelopedthatcalledforadeveloperand

aproductownertoagreethatacceptancecriteriahadbeenmet.

2. During the determination of velocity for the next sprint, no credit wasgivenforstoriesthatwerenotcompleted.This“nopartialcredit”policyforcedteamstofocuson100percentcompletion.Storiesthatdidnotadd

upto100percentfailedfor thatsprint,anddependent taskscouldn’tbestarted.

3. Use of a nine-day sprint model helped create regularity for the teams.Thismeant that after sprinting forninedays, review, retrospective, andplanningmeetingswereheldeveryotherFriday.Teamswouldbeoutsideofasprinteveryotherweekend,andthisultimatelyimprovedqualityoflife andmorale. Forweekends that fell inside sprints, the teams (usingtheirself-organizingcapabilities)coulddecidewhetherworkingthroughtheweekendwasnecessarytocompletetasksontime.

4. Usingastructuredcadenceallowedproductownersandbusinessownerstochangedirectionifnecessaryatrelativelyfrequentintervals.Collecteddatashoweda10to20percentlossofvelocityifasprint

wasinterrupted,soastructuredcadenceallowedtheteamstopreventincurringwhattheycalled“sprintinterrupttax.”

5. To facilitate the generation of usefulmetrics like theBurndownChart,Intelutilizedacentral,openaccesstoolthatsmoothedthetransitionandallowedforcontinuousandimpediment-freeplanning.Existingprogramsdidn’t fit theirneeds,so theydesigned theirown.Elweradmits that thecurrentofferingsaremoredevelopedthantheywereat that time,sotheneed for an organization to produce their own software is significantlylesslikelythesedays.

6. Theterm“storypoint”wasdevelopedtorefer toprojectswithcomplextime requirements and tasks that couldn’t easilybedescribedashavingduration in “days.”Using storypointsmadeconveying results touppermanagementandoutsidersmucheasier.Reducingtaskstolessthanadaywasliberatingforteamsand

enlighteningformanagement.Taskswereassignedadegreeofdifficultymeasuredinstorypoints.Ifatasktooklongerthanaday,managementcouldidentifythatthetaskwasprobablysufferingfromanimpediment.

7. The Daily Scrum meeting significantly benefited from visuals and

graphic representations of progress, with emphasis on the visualBurndownChart.

8. Useofincrementalreview,orreviewprocessesthatdidn’twaituntilthereviewmeeting,alloweddeveloperstochangecourseifnecessarybeforetheendofasprint.

9. Visibilityof thebacklogand reliablemetrics aboutperformancehelpedmanagersadjustexpectationsandreviseplansasnecessary.

10. Extensive support from upper level management made the transition asuccess.Elwer claims that anabsenceof supportwouldhavekilled theproject.

11. To effectively change the behavior of the team members who wereadopting the Scrummethodology, the newbehaviorswould have to bepracticed. Consistent use of the program and sharing of its results hasfurthercementedtheScrumframeworkintotheIntelculture.

WhatCouldHaveGoneBetter

1. Inanefforttoimprovecommunicationacrossteamsandbetweenproductowners and their teams, product ownerswere allowed to serveon theirteams.Thisworked for some teams,butothers found themselvesbeingmicromanaged,whichistheantithesisofself-organizationandpresentedthe company with roadblocks in the areas of communication and lostpotential.

2. Themaintenanceofa largebackloghadanegativeeffecton the teams.Theybegantofeelasthoughtheywerebeingoverwhelmedwithrequestsbecauseanyoneatanytimecouldeditoraddtothebacklog.AsolutionElwer’steamdevelopedwastosegregatenewbacklog

requestsfromexistingoneswithahighleveloftransparency.Thatwaythecurrentbacklogwasminimal,but“onqueue”taskscouldstillbeaccessedandassessedforlatersprints.

SummaryofResults

Elwermeasures success in fourways: cycle time, performance to schedule,morale, and transparency. Scrum is identified as the source of a 66 percentreduction in cycle time. In regard to performance to schedule, the two-weekplanningcyclehasbeenmaintainedformorethanayearsincethereleaseofthestudy.Missed commitments and schedule slipshavebeenvirtually eliminated.Morale is trending upward, with improvements in communication and jobsatisfaction. The transparency provided by the Scrum method has uncovereddysfunctions such as bugs, impediments, weak tools, and poor engineeringhabits.What is most striking about this case study is how the Scrum process was

stretchedtofittheIntelcultureandhowthatculturewaselasticenoughtoacceptthe change. In both this example and the Yahoo Inc. case study from theprevious chapter, the deciding factor in the success of the programs was thededication of one leader within the organization. That leader’s vision andvigilancepavedthewayforotherorganizationstoconsiderimplementingAgileandassessingthebenefitsthatitmaybring.

ChapterRecap

Intel’s adoption of Scrum was met by many challenges, setbacks, andaccomplishments.

10Forthosenotfamiliarwiththeadage:“Inahamandeggsbreakfast,thechickenwasinvolved,thepigwascommitted.”

|14|Criticism

InThisChapter

ProblemswithAnticipatingCustomerExpectationsCorporateAestheticsAdaptabilityChallenges

Nowthat theAgilesystemhasbeendiscussed insomedetail, let’sexplore thecriticism it has attracted through the years. Any management theory issusceptibletoopposition,eitherbyproponentsofrivalschoolsofthoughtorbythosewhohaveidentifiedareasofpotentialtroubleintheapproach.Agileisnoexception.

CustomerInputOneoftheprimaryfaultsthathasbeenobservedinAgileconcernsitsreliance

onthefeedbackoftheenduser,orcustomer.Sometimes,ifthecommissionerofaprojectisallowedtoogreatadegreeofinputorchoiceinitscourseandoutput,theultimateobjectivebecomesobscuredorimpossibletoachieveonthebasisofthe precedingwork.The aggregation of theworkmay become so distorted ordirectionlessthatitcannotbecomposedintoasatisfactorysummaryresult.Thisissuemaybeexpressedsuccinctlyinthefollowingadage:

“Thecustomerisalwaysright,assumingthattheyknowwhattheywant.”

Thatthecustomerisnotalwayssureabouttheirultimatedesiredoutcomeisareality in the IT industry, as well as in other sectors of commerce where thecustomer is allowed some level of influence in the decision-making processregarding the nature of the final product. This is seen in the way that somepeopleor organizations can take an inordinate amountof time to choose fromthe available range of options, or require “consumer guidance” or “specialistadvice,”even in theselectionofsuchmundanecharacteristicsascolororsize.

Entiresub-industriesofconsultantsand“experts”haveariseninresponsetotheindecisivenatureoffinanciallyableyetequallyirresoluteconsumers.Agilecaterstotheseconsumerstoapotentiallyhazardousextent.Givingthem

theopportunity toprovide feedbackona constantbasismaycauseextraworkfor the project team or result in conflicting or even directly contradictoryinstructions regarding theproject’s scope.Somepeople, ifgiven thechance tochange their minds, will, not so much as a matter of necessity but simplybecausetheyappreciatethesenseofauthoritythattheexerciseendows.Whereasubstantial amount of theirmoney is involved, theymay even feel obliged toenforcethatauthority,sincetheyarepayingtoholdit.Thecustomerneedstounderstandthatthemerefactthattheyhavebeenasked

for input does not necessitate that it be constantly shifting or consistentlynegative.Somecustomers are in thehabit of being intentionally impossible toplease.Thewayinwhichtheprojectteamaccommodatesthatattitudeismoreamatterofprofessionalacumenthantechnicalexpertise.As former US President Bill Clinton remarked after the provisionally

undecidednationalelectionattheendofhissecondterminoffice,“ThepeopleofAmericahavespoken,butit'snotclearwhattheysaid.”Thiseventuality isone towhichAgile is susceptible. It shouldbeaddressed

throughpropercommunicationwiththecustomeratalltimes,particularlyattheoutsetof theproject,where its riskofarisingshouldbeoutlinedandexplicitlydiscouraged.

ProfessionalImpression/CorporateImageEffective communication requires time and expense to be sustained.

Therefore, any management paradigm that relies on constant communicationincreases this item of the budget, cutting into the profit margin for thedevelopment team and representing a possible source of conflict with thecustomer. Some customers might not appreciate continuous requests forcommentortesting,especiallyiftheyarenotveryskilledintheuseofITortheybelievethattheypaypeopletosolvesuchproblemsforthem.How a business communicates with customers and other outside entities is

germanetoitspublicimage.Atthesametime,itsinnerworkingscontributetothat image too. Customers need to be presented with a professional, suitablyconstitutedphilosophyonbusinessandcustomerservice.SomecustomersmayexperiencetheAgileenvironmentastheoppositeofthat.ThefactthattheAgileteamisoftentemporaryinnaturemayendowitwitha

sense of having an improvisatory or maverick status. Also, because it issupposed to be relatively more informal than conventional, it may seem toobohemian or artistic to customers who subscribe to a more staid, traditionalapproachtowardsupplierrelationsandproductdevelopment.Lastly,Agiledoesnotemphasizethebureaucracyoftheprojectsystem.Some

operatorsmayseethisasasourceofrelief,butitispotentiallyadisadvantage.They may not even understand how to use the documentation, or they mayregardthecompilationoftheirowntrainingmaterialasanundueexpenseiteminthetotalprojectbudget.

TeamCompositionMore traditional project management systems require a comprehensive

documentation of activity. Together with a larger staff, this ensures that theabsenceordepartureofateammemberdoesnotobstructthefutureprogressofthe project.Agile, on the other hand, is somewhatmore vulnerable to changeinsofarasitusessmallerteamsandminimalliteratureorrecordkeeping.

DependencyofInterrelatedStagesSometimes the development of the final product relies on the sequential

constructionof itscomponentparts, and the laterand finalphasescanonlybeexecuted if the preceding ones have already been finished. In projectmanagement,thisisknownasdependency.Agile has been criticized because it does not provide specific solutions for

incorporatingdependenciesintoprojectmanagement.Thisseemstobeamostlyinsubstantialpointofconcern,sincetheincrementalnatureofthesystemresultsin a steady supply of finite deliverables that interact and comprise the entirefinished item. Their interaction is based on their interdependence, so it is

apparentthatinschedulingthework,theprojectteamwouldhavetoincorporatethataspectasaninherentfeatureoftheirprojectroster.IfAgiledoesnotprovideadedicatedtoolforthataspect,itisperhapsdueto

the assumption that the project team consists of highly qualified professionalswho are not operating on the basis of the linear, unidirectional Waterfallmethodology and thus have a thorough understanding of how the projectiterations fit together and will automatically realize which elements aredependentononeanother.ThisispossiblebecausetherelativelysmallerAgileteam is responsible for the project in its entirety, as opposed to the moretraditional massive project workforces, which are compartmentalized to theextent that some staffmay not have any idea of exactlywhere their output issituatedintheoverarchingschemeoftheproject.InAgile,thereisalsotheissueofrestrictiveiterations.Becausetheiterations

are fixed in their duration and output, sudden adjustments to the scope of theprojectcannecessitateadditionalsprints.TheseinstantaneousmodificationsareinherentintheAgilemethodologyandso,insteadofstabilizingthebudgetandturnaround time, the Agile approach could actually serve to expand them.However,asalways,thatexpansionisonlygoingtobetranslatedintoapracticaloutcome if the customer permits it. If the customer decides to staywith theiroriginalbudgetandduration,theymaybeobligedtoacceptaproductthatislesssophisticated or less developed thanwhat they had hoped for or subsequentlyrealizedtheyneeded.

WaterfallThisbookhasalreadymentionedtheprojectmanagementstrategyknownas

Waterfallandhasprovidedaroughoutlineofhowitoperates,butforthesakeofconvenience it will now be summarized again. TheWaterfall methodology isregarded as traditional or even “conventional” in that it entails a classic plan–execute–observe approach. The problem ormarket expectation is identified, aresponseisplanned,andthentheprojectworkisperformed.Afterwards,suchasafterthereleaseofanewproduct,theresultsoftheprojectcanbemonitoredandanalyzed.

ThetypicalphasesinaWaterfallprojectareasfollows:

ConceptionInitiationAnalysisDesignConstructionTestingImplementationMaintenance

There is no need to enter into an examination of all the various methodsassociatedwiththedifferentphasesofthisstrategy.Obviously,softwareplaysapart in its execution, but the primary sequence of stages remains unchanged.Some may describe it as adhering to a generic rationale or demonstrating anatural progression, in that itmaps out how informal, unplanned projectswillruntheircourseanyway.WhathasalsobeennotedabouttheWaterfallmethodologyisthatitgenerates

arigidprojectscope,butonlyanestimatedbudgetandtimeframe.Therefore,itispronetocostmoreortakelongerthananticipated.Italsodoesnotnecessarilydeliver a product that is entirely or even remotely adequate for the desiredoutcome.ConsiderationssuchasthesearetypicallyraisedwhenWaterfalliscompared

to Agile. This juxtaposition is an unsurprising exercise in the managementadvisory industry (see Chapter 11), but it is not merely due to professionalrivalry or intellectual one-upmanship. The advantages ofAgile overWaterfallhave been established in practical applications, not limited to the IT industry.Thetwocasestudiesinthistextserveasproofofthat.Whatmay limit theextentof theevidenceat this time is the relativelyshort

historyoftheAgilemethodology.Itwasonlyofficiallyinauguratedasaprojectmanagementphilosophyatthestartofthetwenty-firstcentury,andtheliteratureandoperatingtrackrecordofthesystemarenotasprolificasthoseoftheolder

approaches.Therefore,itispossibleforobjectionstoAgiletoarisebecauseitisa“new”systemofmanagement.Wherevaluable resourcesof timeandcapitalareatstake,someeconomicroleplayersprefertostayawayfromwhattheyseeas unproven or precariously novel attitudes. They may also refer to theirtraditionalorganizationalcultureinmakingthisassertion.However,aftermorethantenyearsinserviceandapubliclyreportedresume

ofsuccessinbothbigbusinessandgovernment,thisobjectionisstartingtoseemincreasingly false and inflexible. As more enterprises adopt the Agilemethodologyinoneformoranother,thosewhoremainsteadfastinWaterfallorotherapproachesmaystart tolosemarketshareorindustrystature.Thosewhodonot remain adherent to traditionalmethodsmay experience progress in theoppositedirection,either through increasedcustomernumbersand retentionorbyassociationwithotheresteemedcompaniesthatuseAgile.Whatfollowsisashort summary in table form of the main differences between Agile andWaterfall. It is probably one of the most published diagrams in projectmanagement literature at this time, but no publication on the subject ofAgilewouldbecompletewithoutit.

Thesystemthatisuseddependsonthenatureoftheprojectandtherequiredstaff. There is no purpose in trying to ascertain the superiority of one systemover theother.Projectmanagerssimplyhave to try tomatcha system to theirspecificprojectcharacteristics.

ChapterRecap

DuetothemercurialqualityofcustomerdemandinIT,Agile’srelianceoncustomerfeedbackcanproveinconsequential.

Agile’sbreakdownofcustomaryhierarchiesmaycomeintoconflictwithanorganization’sprofessionalaesthetic.

Agile’siterativemethodologymayproveincompatiblewithprojectsthatrequirespecificsequencesofproduction.

|15|TheAgileSub-Industry

InThisChapter

AgileConsultants,Trainers,Certifications,andLiterature

As is the case with other management systems, such as business ororganizationalmanagementmethodologies,Agilehasattractedasub-industryofexperts, practitioners and product suppliers. These professionals rely on theiradvanced knowledge of theAgile system and itsmethods to provide advisoryandimplementationservicestotheircustomers.SomeofthesefirmsalsodesignandpublishAgiletools,suchasthesoftwaredescribedinChapter10.

TheSub-IndustrySome experts offer Agile techniques as part of their entire portfolio of

managementoptions.OthersarededicatedexclusivelytoAgile.Thissolefocusis seen among those who established the paradigm, such as Kent Beck, thefounding authority on XP (Extreme Programming), who has a websitecommittedtoXPandAgile.Theextenttowhichthissub-industryhasachievedsuccessorisproliferating

is a matter of future observation. In relative terms, Agile is a very newmanagementdisciplineand,althoughithasbeenadoptedbythousandsoffirms,itstruevaluewillonlybecomeapparentafteramatterofdecades.Thereare twopossible impediments to itsprogress.Thefirst is thatAgile is

notabroadenoughdiscipline tomeritofficialacademicstatus. Itcannotstandon its own as a subject. It is merely one of a variety of project managementapproachesanddoesnotindependentlypossessthemagnitudeorcomplexityofsubjectmattertoconstituteaseparatefieldofstudy.At the same time, because it is so lacking in complexity andminimal in its

philosophyandmethods, it canbe assimilated into anorganization's processes

without outside assistance. Management can easily examine and apply itsprocedures.Thefactthatthesoftwaretoolsareopenlyavailableonthemarket,sometimesatnocharge,enablesthefrequencyofthisoccurrence.Contrastthisto businessmanagement systems such as SixSigma,which requires advancedstatistical expertise to master, or the Toyota Production System (Toyotism),whichaffectstheentireorganizationtoptobottom.The absence of more official academic recognition deprives a subject of

supporting infrastructure. Its promotion and development then relies on thecontributionsofitsloyalproponents,whicharemoresporadicandundevelopedthan the regulated,officiallysanctionedandsponsoredstudyand improvementenjoyedbymoretraditionaldisciplines.Thereare,however,organizationswithauthorityintheindustry,theforemost

ofthesebeingtheAgileAlliance,anonprofitorganizationthatoffersregisteredmembershipandaimsatan internationalsubscription.TheAllianceundertakesacademicresearchprojectsandendorsesworkshopsandconferences.Another option, which is focused specifically on Scrum, is SCRUMstudy

(http://www.scrumstudy.com).SCRUMstudyadministerscertificationprogramsfor those who wish to practice as Scrum experts, either as employees in anenterpriseorasmanagementadvisers.Traineesarerequiredtopayfeesandpassexaminations. These courses can be undertaken through the internationalnetworkofpartnerswithwhomSCRUMstudyisassociated.

LiteratureLiterature onAgilemight not be as substantial or easy to obtain as that of

other management systems. The new nature of the paradigm translates into ashortage of published subject matter. Most of the literature, therefore, iscomprisedofarticlesandpapers.However,afewbooksareavailableforthosewho desire to conduct further reading, and we recommend starting with animportantworkbyoneof the seventeen founders, JimHighsmith, heading thelistbelow:Agile Project Management: Creating Innovative Products (2nd edition) by

JimHighsmith(2009).

CoachingAgileTeams:ACompanionforScrumMasters,AgileCoaches,andProjectManagersinTransitionbyLyssaAdkins(2010).AgileTesting:APracticalGuideforTestersandAgileTeamsbyLisaCrispin

andJanetGregory(2009).TheEnterpriseandScrumbyKenSchwaber(2007).Scrum ShortcutswithoutCuttingCorners: Agile Tactics, Tools and Tips by

IlanGoldstein(2013).Schwaber (author of The Enterprise and Scrum, above) is another of the

seventeenAgilefounders.Besidestheseworks,readersareadvisedtoperusetheperipheralmaterialavailableonline.

ChapterRecap

AnabundanceofAgileresourcesexistacrossamultitudeofmediums.

Conclusion

Thesoftwareindustryisamodernphenomenonand,assuch,thetechniquesofmanagementandproductdevelopmentthatitentailsaresomewhatuniquetoitscharacter and product. To say thatAgile couldonly have originated from thisindustry is not entirely accurate, but it is a partially cogent statement.PerhapsAgilemerely required the environment presented by the IT sector to bemoreformallyadopted.Asamemberofthemoregeneralcatalogofprojectandbusinessmanagement

techniques,Agilehasaworthypositionandoffersaneffectiveapproachtothemanagement of suitable projects. Its efficacy has been proven by its diverse,extensive application in practice and its stature in discussions ofmanagementsystems.Theextent towhich itprogresses into thefuture, in termsofbothexpansion

and refinement, remains to be seen. However, the simplicity and universalrelevanceofitsprinciplesandinnatephilosophywouldappeartosuggestthatitwill be present in management textbooks for some time. Agile may start toacquireanevengreaterpresenceasmoreandmore industrialactivityreliesonITandthedevelopmentofcustomsoftware.Oneshouldalsorememberthatsomeprinciplesinmanagementaretimeless.

Justasthosetwentiethcenturyimmigrantsslowlybutpatientlyconstructedtheirhomespiecebypieceintheirnewcountry,sotoodoesAgilerepresentsomeoftheoverridingconceptsinbusiness,management,andthedesignandreleaseofnewproductsinanyindustry.Perhaps,ratherthanjustatrendycatchphraseoratemporary phase, Agile is representative of the culmination of a long-termevolution, supported now by technology that more fully enables its effectiveimplementation.Asfarasitssuccessisconcerned,onlytimewilltell.

ThankyouforchoosingClydeBankMediaasyoursourcefor information.Wehope you enjoyed the book and that you have found it a valuable aid in youreducation.

Our company survives based on feedback from customers like you. Yourfeedbackhelpsinformthepurchasingdecisionofcustomerswhocomeafteryouandmostimportantly,allowsustoconstantlyimproveourproducts.

Ifyouhaveanyquestionsorneedsupportforyourorder,pleasecontactusatsupport@clydebankmedia.com

Glossary

AgileProjectManagementFramework-AlsoreferredtoastheAgileProjectManagementLifeCycle.Thistermreferstoafive-step,iterativeproductdevelopmentprocess:Envision,Speculate,Explore,Adapt,andClose.Contrastwith“Waterfall.”

Dependencies-Ageneralprojectmanagementtermusedtodescribetasksthatmustberesolvedinaspecificsequence—taskAmustbedonebeforetaskB.

Feature-Aparticularserviceorfunctionalitythatasystemprovidesandthatisvaluedbyaclient.

OnlineCollaborationTools-NicknameforthevarietyofapplicationsthatareInternet-accessibleandcanbeusedtofacilitateworkandcollaborationbetweenmultipleteammembers.Onlinecollaborationtoolsareoftenusedtoboostproductivityinvirtualenvironments.

ProductBacklog-UsedinScrumtolistandorganizedesiredfeaturesofaproduct.

ProductDataSheet-Aconciseandmetrics-focuseddocumentthatoffersasummaryofprojecttargetsandprogress.

ProductOwner-AroletypicallyseeninScrum,theproductownerisusuallytheproject’schiefvisionaryandprincipalstakeholder.

ProductRoadmap-Atoolusedtoassessandvisualizerequirements,timetables,andtaskprioritylevelsforaproject.

ProjectCharter-Ageneraldocumentthatdefinesthepurposeandsuccessstandardsofaproject.

ProjectManagementTheprocessofcoordinatingandregulatingacollectiveapproachtotheexecutionofatask.ProjectManager-Overseestheday-to-dayoperationsofaproject,addressesquestionsofpriority,scope,andresponsibilities.

ProjectSponsor-Obtainsfundingandotherresourcesforaprojectandensuresthatthedevelopmentteamandprojectstakeholdersareonthesamepage.

Scrum-Aspin-offofAgileProjectManagementthatincorporatessprints,productbacklogs,retrospectivemeetings,andseveralotherAgileutilitiesandprinciples.

Sprints-TheessentialdevelopmentunitsinAgileProjectManagement,typicallyoneweektoonemonthindurationandfocusingonthedevelopmentofacertainsetoffeatures.

SprintVelocity-Theaveragenumberofstorypointsresolvedduringasprint.

SprintStructure-Theprocessofplanningsprintsbyestimatingworkloadsassociatedwithvariousfeatures

anddistributingsimilarworkloadsbetweensprints.

StoryPoints-Ametricusedtoquantifythecomplexityofuserstories.

UserStory-Ashort,one-ortwo-sentencestructuredtestimonialthatprovidesacustomer’sperspectiveontheneedforaproduct.

Waterfall-Sometimesreferredtoasthe“Waterfallmethod”orthe“Waterfallapproach.”AtraditionalprojectmanagementmethodologythatemphasizesaplananddefinitionofsuccessthatissubstantiallymorerigidthanthatoftheAgileapproach.ThefivestepsofWaterfallprojectmanagementareInitiating,Planning,Executing,Controlling,andClosing.

AboutClydeBankMediaWe are a multimedia publishing company that provides reliable, high-qualityandeasilyaccessibleinformationtoaglobalcustomerbase.Developedoutoftheneedforbeginner-friendlycontentthatisaccessibleacrossmultipleformats,wedeliver reliable, up-to-date, high-quality information through our multipleproductofferings.

Throughourstrategicpartnershipswithsomeoftheworld’s largestretailers,we are able to simplify the learning process for customers around the world,providingthemwithanauthoritativesourceofinformationforthesubjectsthatmatter to them.Our end-user focused philosophy puts the satisfaction of ourcustomers at the forefront of our mission. We are committed to creatingmultimedia products that allow our customers to learnwhat theywant, whentheywantandhowtheywant.

ClydeBank Business is a division of the multimedia-publishing firmClydeBank Media LLC. ClydeBank Media’s goal is to provide affordable,accessibleinformationtoaglobalmarketthroughdifferentformsofmediasuchaseBooks,paperbackbooksandaudiobooks.Companydivisionsarebasedonsubjectmatter,eachconsistingofadedicatedteamofresearchers,writers,editorsanddesigners.

Formoreinformation,pleasevisitusat:

www.clydebankmedia.com

orcontactinfo@clydebankmedia.com

REMEMBERTODOWNLOAD

YOURFREEDIGITALASSETS!

VisittheURLbelowtoaccessyourfreeDigitalAssetfilesthatareincludedwiththe

purchaseofthisbook.

DOWNLOADYOURSHERE:

www.clydebankmedia.com/agile-assets

ExploretheWorldof

BUSINESS

TOEXPLOREALLTITLES,VISIT:

www.clydebankmedia.com/shop

Gettitleslikethisabsolutelyfree:

TogetyourFREEaudiobook,visit:

www.clydebankmedia.com/free-audiobook

ClydeBankMediaisaProudSponsorof

AdoptAClassroom.org empowers teachers by providing the classroom suppliesandmaterialsneededtohelptheirstudentslearnand

succeed.As an award-winning 501(c)(3),AdoptAClassroom.orgmakes it easyforindividualdonorsandcorporatesponsorstodonatefundstoK-12classroomsinpublic,privateandcharterschoolsthroughouttheU.S.

Onaverage, teachers spend$600of their ownmoney each year to equip theirclassrooms–20%ofteachersspendmorethan$1000annually.

Since 1998 AdoptAClassroom.org has raised more than $30 million andbenefitedmorethan4.25millionstudents.AdoptAClassroom.orgholdsa4-starratingfromCharityNavigator.

TOLEARNMORE,VISITADOPTACLASSROOM.ORG

Copyright©2016byClydeBankMedia-AllRightsReserved.Thisdocumentisgearedtowardsprovidingexactandreliableinformationinregardstothetopicandissuecovered.Thepublicationissoldwiththeideathatthepublisherisnotrequiredtorenderaccounting,officiallypermitted,orotherwise,qualifiedservices.Ifadviceisnecessary,legalorprofessional,apracticedindividualintheprofessionshouldbeordered.FromaDeclarationofPrincipleswhichwasacceptedandapprovedequallybyaCommitteeoftheAmericanBarAssociationandaCommitteeofPublishersandAssociations.Innowayisitlegaltoreproduce,duplicate,ortransmitanypartofthisdocumentineitherelectronicmeansorinprintedformat.Recordingofthispublicationisstrictlyprohibitedandanystorageofthisdocumentisnotallowedunlesswithwrittenpermissionfromthepublisher.Theinformationprovidedhereinisstatedtobetruthfulandconsistent,inthatanyliability,intermsofinattentionorotherwise,byanyusageorabuseofanypolicies,processes,ordirectionscontainedwithinisthesolitaryandutterresponsibilityoftherecipientreader.Undernocircumstanceswillanylegalresponsibilityorblamebeheldagainstthepublisherforanyreparation,damages,ormonetarylossduetotheinformationherein,eitherdirectlyorindirectly.Respectiveauthorsownallcopyrightsnotheldbythepublisher.Theinformationhereinisofferedforinformationalpurposessolely,andisuniversalasso.Thepresentationoftheinformationiswithoutcontractoranytypeofguaranteeassurance.Trademarks:Alltrademarksarethepropertyoftheirrespectiveowners.Thetrademarksthatareusedarewithoutanyconsent,andthepublicationofthetrademarkiswithoutpermissionorbackingbythetrademarkowner.Alltrademarksandbrandswithinthisbookareforclarifyingpurposesonlyandareownedbytheownersthemselves,notaffiliatedwiththisdocument.ClydeBankMediaLLCisnotassociatedwithanyorganization,productorservicediscussedinthisbook.Thepublisherhasmadeeveryefforttoensurethattheinformationpresentedinthisbookwasaccurateattimeofpublication.Allprecautionshavebeentakeninthepreparationofthisbook.Thepublisher,author,editoranddesignerassumenoresponsibilityforanyloss,damage,ordisruptioncausedbyerrorsoromissionsfromthisbook,whethersucherrorsoromissionsresultfromnegligence,accident,oranyothercause.SecondEditionCreatedDecember8,2016Editor:MarilynBurkleyCoverIllustrationandDesign:KatiePoorman,Copyright©2016byClydeBankMediaLLCInteriorDesign:KatiePoorman,Copyright©2016byClydeBankMediaLLC

ClydeBankMediaLLCP.OBox6561

Albany,NY12206PrintedintheUnitedStatesofAmerica

Copyright©2016

ClydeBankMediaLLCwww.clydebankmedia.com

AllRightsReservedISBN:978-1-945051-34-0