Agile for DHS 2017 June26

Agiledevelopmentmethodologiesemergedinresponseto

failingsoftraditionalsoftwaredevelopmenttoreliably

produceresultsinapredictabletimeframe.

CriticismoftheRequirementsEngineering(RE)practicein

traditionalorganizationsisprominentamongthe

motivationsspurringtheAgilemovement.

Astudyof8,380ITprojectsrevealstwomainreasons

projectsfail:(1)lackofuserinputand(2)incompleteor

changingrequirements.

WhenusinganAgileSoftwareDevelopmentMethod

(ASDM)usersdescribethetaskstheymustbeableto

accomplishwiththesystem,buttheycan’tidentifyallthe

specificfunctionalandnon-functionalrequirements

neededtoimplementedtoletthemaccomplishthose

tasks.

Intraditionalprojects,theresponseistoabetterjobof

requirementsengineering.InCommercialASDM,the

responseiscontinuous,on-site,customercollaboration

withthedevelopers.Asworkprogresses,additional

requirementswillemergeandwillberapidlyaddressedby

thecustomeranddeveloper.

InFederalITacquisition,thismaybeproblematicdueto

organizationalissues,remoteusercommunities,andother

structuralissues.

Estimatingtheneededworkinthepresenceofthese

issuesisdifficultintraditionalproject.WhenASDMare

usedtheseestimatesbecomemoreproblematic,duethe

emerging natureoftherequirements.

1

7/29/17

ThomasJ.Coonce/GlenB.Alleman

DHSEstimatingandReportingAgileProjects

ALL PROJECTS OPERATE IN THE PRESENCE OF UNCERTAINTY

Uncertaintycomesintwoforms:

§ AleatoryUncertainty‒thisisthenaturallyoccurring

statisticalvariancesintheunderlyingprocesses,

environment,andtechnology.

§ EpistemicUncertainty‒thisaprobabilisticeventthere

willoccursomethingthatiscurrentlyuncertain.

Boththeseuncertaintiescreaterisk:

§ Irreducible riskfromaleatoryuncertainty– whichcan

onlybemanagedwithMargin.

§ Reducible riskfromepistemicuncertainty‒whichcan

bemanagedwithriskbuydownactivities,fundedon

thePerformanceMeasurementBaseline.

RiskManagementisHowAdultsManageProjects– TimLister

Beanadultandmangetheprojectasariskmanager.

DHSEstimatingandReportingAgileProjects7/29/17

ThomasJ.Coonce/GlenB.Alleman,July2017 2

TheacquisitionordevelopmentofSoftwareIntensive

SystemofSystems(SISoS)inthecurrentparadigmismade

bothcomplexandcomplicatedbyexternalinfluencers.

§ Technologicalchangeisaccelerating,possiblefaster

thantherequirementscanbestabilized.

§ Commonalityofsystemsisnowthenorm,withpossibly

unknowninteractionbehaviors.

§ NeedtohaveaGlobalunderstandingsofhowsystems

workisnowthenorm.

§ Informationisacommodityandrequiresmanagement

onitsown.

§ Collaboration outsideourcomfortzonesisrequired

§ Economiesofscaledrivenewtechnologyandrapid

change,reducingtheabilitytobuildpurposebuilt

productsorservices.

§ CommercialOffTheShelfeverythingwithreducing

controloverthebehavioroftheseproducts.

§ Weneversawitcoming isnowthenorm.


ThomasJ.Coonce/GlenB.Alleman 3

WhyAgilityMatters?Wetendtotakethefactthatagilityisimportantasa

given,whentherealityisthatnoteveryoneinthe

businessworldhasreachedthesameconclusion. Thus,

it’simportantsometimestotakeastepbackand

examine why agilityactuallymatters,sothatwhenwe’re

facedwithpeoplewhoaren’tasconvincedasweare,we

havesalientpointsthatwecanraisetohelpthem

understandthevaluethatagilitybringswithit. Herearea

fewimportantthingstorememberwhenthinkingabout

whyagilityisimportantinourjobs

†TheCleverPM,July20,2017

http://www.cleverpm.com/2017/07/20/why-does-agility-

matter/



Whilethe6stepsaboveareCriticalSuccessFactorsfor

increasingtheProbabilityofProgramSuccess(PoPS),

therearefourimmutabletruthsinthedevelopemntof

softwareusingagileinsidetheFARprocurement

framework.

1. Onsoftwareintensivesystemofsystems,capabilities

maybefixed,buttechnicalandoperational

requirementsemerge.

2. Astheprogramevolves,changeswilloccur.Thisisa

desiredconditionforAgiledevelopment.

3. Withemergingrequirements,boundedtimeandcost

willconstraintheabilitytorespondtotheseemerging

requirements.

4. Estimatinginthepresenceofuncertaintyand

emergencemeanscontinuousupdatingthatestimate

inresponsetothesechanges.



EMBRACING AGILE MEANS

Applyingthesesixcriticalsuccessfactorstoincreasethe

probabilityofprogramsuccess

1. StartwiththedescriptionofwhatDONElookslikein

theConceptofOperations,butbepreparedfor

emergingrequirementstochange thedescription.2. BuildtheIntegratedMasterPlanandidentifythetop

levelrisksfromtheGovernment’spointofviewbefore

issuingtheRFP,andupdatethatplanwhennew

requirementsappear.

3. Awardacontractbasedontheassessmentofthe

vendorsProbability ofmeetingstheMeasuresof

EffectivenessandPerformance,ontheneeded

completiondatafortheneededcost.

4. AssessthePMBattheIBRandrequireanIMP,a

technicalplan,ahighintegrityWBSandWBS

Dictionary,andaProgramManagementPlan.Confirm

thesearebeingfollowedandupdatethenwhen

changeoccurs.

5. UsethesedocumentsasProgramPerformance

Managementprocessesinthepresenceofuncertainty

andemergence.

6. MeasurePhysicalPercentCompleteagainsttheRisk

AdjustedPMBonamonthlybasiswithpossibleaMid-

MonthFlashReport.Nevermeasureprogressasthe

passageoftimeandconsumptionofmoney‒working

productsontheplanneddatefortheplannedcost.

TakecorrectiveactionstoKeeptheProgramGreen



Inthefederalacquisitiondomain,thePerformanceMeasurementBaseline(PMB)andContractBudgetBase(CBB)aretheanchordocumentsforthecontractualwork.

TheseTraditional documentsdescribewhatisbeingdeliveredandwhattobudgetisforeachdeliverable.

IntheAgileacquisitiondomain,definitizedrequirementsarenotavailable,noraretheyencouraged.

Whatneedstobeonbaseline isthesetofCapabilitiestheprojectwillproducewhenitisdone.

Capabilitiesdescribeasolutionindependentrequirementsfortheneededsystem.AbovetheLINE,capabilitiesarebaselinedforthecontractualcompliance.BelowtheLINE,therequirementscanemergeastheprojectprogresses.

AstheCapabilitiesarefulfilledbyemergingRequirementsintheformofFeaturesandStories,theuserofthesystemcanassessthematurityofthoseCapabilitiesusingPhysicalPercentCompleteMeasuresofEffectivenessandMeasuresofPerformance.

Thisidealized viewofsystemsdevelopment,mustbemanagedwithtraditionalChangeControltoavoidtheDeathMarch

projectswhereboththeCapabilitiesandemergingrequirementshaveopenendedsolutions.

ThisissueisaddressedinAgileSoftwareDevelopmentwithaCapabilitiesBasedPlanningprocess[1]inthesamewayRequirementsManagementisusedontraditionaldevelopmentprojects.

Thismeanscontinuousdeterminationofwhatcapabilitiesareneededatwhattime,whatisthefundingforthosecapabilities,whattechnicalrequirementsareneededtofulfilthosecapabilities,andhowtobalancetheseneededcapabilitiesacrosstheuser’sneeds,withintheconstraintsofthebusiness,technical,andoperationalenvironment.

[1]“CapabilitiesEngineering– AnAnalysisofPerspectives,INCOSEInternationalSymposium,Volume21,Issue1,June2011,Pages:712–727.

7

7/29/17



GOVERNMENT PROGRAMS ARE NOT LIKE COMMERCIAL PROGRAMS

ThebudgetforGovernmentprogramsbelongstoa

sovereign.

SpendingthatbudgetissubjecttoFARclauses.

ThePerformanceMeasurementBaseline(PMB),withit’s

timephasedcosttoproducethecontractualoutcomesis

thecoredocumentinGovernmentSoftwaredevelopment.

IntegratingAgilewithFARprocurementisstraightforward

andatthesametimedifficult.

TheAgileManifestoassumessmall,self-organizingteams

andlowformalitycontracts.

DataandtheresultingInformationisthebasisofall

decisionmakinginthepresenceofuncertainty.

Softwaredevelopmentandacquisitionprojectsarehighly

uncertain.

Weneedanintegratedsetofdatafromwhichtoextract

informationtomakeinformeddecisionsinthepresenceof

uncertainty.

Here’sthestructureofthisdata,startingwiththeRFPand

movingtoProgramExecution.

BothhorizontalandVerticalintegrationofthedatais

needed.Withoutthisintegrationthereisnointegrityis

theinformationproducedbythedata.

VerticallywegofromRFPCapabilitiesdowntotheWork

PackagesthatimplementtoFeaturesofthesoftwarethat

implementthoseCapabilities.

HorizontallywegofromRFPtoprogramexecution.



Thereare10stepsinestimating,developing,managing,

anddeliveringasoftwareprogramusingAgilemethods.

Thistalkfocusesondevelopingthe❶ Engineering

Estimateandtheuseofthatestimateinthemeasurement

ofprogresstoplan.

Theother9stepsareneededofcourse,butarethe

subjectofanothertalk.

Thiseffortneedstoproduceacredibleestimateforthe

neededCapabilities.

WecanstartthiseffortbydecomposingCapabilitiesthose

intoFeaturesandstartingdevelopingthesoftware.

TheseCapabilitiesaredescribedintheProductRoadmap

andReleasePlan.

TheFeaturesaredescribedintheProductBacklog.

TheStoriesthatimplementtheFeaturesaredescribedin

theSprintBacklog.

Allthesecontainers (backlogs,roadmaps,andplans)of

informationprovideinputtotheestimatingprocess– up

anddownthechainofdeliverables,forCapability

estimatesatthehighestleveltoTasksatthelowestlevels.

ThecollectionofthisdataisthefoundationforReference

Classes.

ThisisthestartingpointforestimatingAgiledevelopment.



§ ConOps‒describesthecharacteristicsoftheproposed

systemfromtheviewpointofanstakeholderswhowill

usethatsystem.Itcommunicatesthequantitative

(Performance)andqualitative(Effectiveness)system

characteristics.

Ournewwarehousemanagementsystemwill

improveresponsetime,reducewaste,andincrease

efficiencyandeffectivenessofourcapitalassets

andstaff

§ Capabilities‒ahigh-levelsolutionbehaviorproviding

theabilitytoaccomplishsomebusinessfunctionorfulfill

amission.

Weneedtheabilitytoprocess100Ktransactionsa

dayforournational-widewarehouseinventory

trackingsystem

§ Feature‒adistinctelementoffunctionalitythatfulfilla

stakeholderneed.

Weneedtoaddanewsuppliertothewarehouse

inventorycontrolsystem

§ Story‒auserorienteddescriptionofenough

informationsodeveloperscanhaveareasonable

understandingofhowtheywouldneedtoimplement.

Asawarehousemanager,Iwanttotrack

movementofshippablegoodsinrealtime,soIcan

scheduleforktruckandloadingdockpersonnel

§ Task– asmallactivitythatisrequiredtogettheStory

done.

Createdatabaseentriestocapturetheavailability

offorktruckdriversbyspecificshiftandgeographic

location



Estimatingingeneralishardwork.

EstimatingonAgileprojects,whererequirementsare

changing,usersarenotclearonthedetailsoftheneeded

softwareisevenharder.

Butestimatesareneeded,nomatterwhatdomainwe’re

in.

IntheFARacquisitiondomain,estimatingisnotonlya

criticalsuccessfactor,butitisacontractualobligation.

Whenwedon’thaveReferenceClassesofFeature,we

havetostartbuildingourestimatingdatabaseusing

FunctionPointsasdefinedinIFPUGguidance.



ThebasisofsuccesswithReferenceClassForecastingisto

buildadistributionalinformationdatabaseinsteadofa

singularinformation estimate.

Singularinformation iswhatweknowaboutanindividual

case ‒aPointEstimate.

Distributionalinformation,bycontrast,consists

of knowledgeaboutthedistributionofoutcomesinsimilar

situations.

Asthedatabaseofcomparablecasesgrows,thepredictive

accuracyofnewproductfeaturesimproves.

Thiseffortstartswiththedevelopofcategorical tagsand

applyingthembothtocompletedandnewbacklogitems.

Productfeaturetags and process featuretags canbe

assignedtocapturethewaysthatagivenfeatureinvolves

complexityordependenciesonexternalfactorsoractors.

Product featuretags focusonwhattheplannedfeature

does(e.g. “hasafront-enduserinterface” or “connects≥2

databases”)while process featuretags focusonwhatthe

productdevelopmentteamdoestodevelopthefeature.

Processfeaturetags arederivedfromaskingthefollowing

questionsduringestimation:

§ Doesexternaldependencyonotherteamsexist?

§ Dowedependoncodethatdoesnotrelyonthesame

standards(e.g.RubyonRails,APIs)? Isresearchneeded

tocompleteaproblem?

§ Dowehavetowritetests?

§ Arethereinterdependencieswithinthecodebase?

§ Arewetouchingnewterritoryinsomeotherway?



13

DevelopingtheEngineeringEstimateisthestartingpoint

formanagingtheAgileSoftwareDevelopmentprogram.

ThisestimateisrequiredtorespondtotheRFP..

Thisisdifferentfromthecommercialsoftware

developmentdomain.

InourFARdomain,weneedtoprovideaPerformance

MeasurementBaselineontheproposal.Theawardofthe

contractisbasedonthecost,schedule,andtechnical

performanceproposal‒longbeforethewritingofcode.

Here’sthestepstodeveloptheEngineeringEstimate.

7/29/17



Amajorsourceofriskinprojectmanagementis

inaccurateforecastsofprojectcosts,demand,andother

impacts.

Forecastsofcost,demand,andotherimpactsofplanned

projectshaveremainedconstantlyandremarkably

inaccuratefordecades.Noimprovementinforecasting

accuracyseemstohavetakenplace,despiteallclaimsof

improvedforecastingmodels,betterdata,etc.

ReferenceClassForecastingwasfirstdescribedby

KahnemanandTverskyin1979tocompensatefor

cognitivebiastheyfoundintheirworkondecision

making.

Theyfoundthatmanyerrorsofjudgmentaresharedby

expertsandlaypeoplealike.Theyfoundthaterrorsremain

compellingevenwhenoneisfullyawareoftheirnature.

ReferenceClassForecastinghasthreesteps:

1. Identifyarelevantreferenceclassofpast,similar

projects.Theclassmustbebroadenoughtobe

statisticallymeaningfulbutnarrowenoughtobetruly

comparablewiththespecificproject.

2. Establishaprobabilitydistributionfortheselected

referenceclass.Thisrequiresaccesstocredible,

empiricaldataforasufficientnumberofprojects

withinthereferenceclasstomakestatistically

meaningfulconclusions.

3. Comparethespecificprojectwiththereferenceclass

distribution,inordertoestablishthemostlikely

outcomeforthespecificproject.



SinceStoryPointsareOrdinalnumbers– relative

measures,withnocalibrated value‒weneedameasure

thatisOrdinal.

TheSRDRusesStoriesandStoryPoints,whicharenot

calibrated anddonothavethesamemeaningforeffortor

complexityashoursanddollarsdo,outsideofasingle

developmentteam,letaloneacrossmultiplecontractors.

HoursandDollarsareCardinal.

Butestimatinginhoursordollarsisdifficult,when

definitizedrequirementsarenotpresent

FunctionPointCountingcanbeawaytoestimateagile

developmentefforts,andstillhaveacardinalmeasureof

costandschedule.

Thereisresearchandexperiencereportsonconnecting

agileestimatestoFunctionPoints.



ForallcontractworkintheFederalGovernment,someset

ofcapabilitiesandsupportingFeaturesneededtobe

statedintheRequestforProposal.

TheConOpsandtheStatementofWorkaregoodspotsto

capturethesecapabilities.

IntheAgileparadigm,thesecanbedecomposedto

Features



These10stepsareneededtoproduceacredibleestimate

onanyprogram‒agileortraditional.

Thestepsdon’tactuallyproducetheestimate,theyare

preparationsforproducingtheestimate.

Thesestepsaretypicallymissingwhenweseepoor

estimatesorestimatesthatarenotcredible.

Withthisinformationinplace,wecanstarttheestimating

process.



Here’sanexampleofaworksheetforcapturingestimates

onaagileprojectintheFederalSpace.

SincetheFARrequiresusknowinghowmuchitwillcost

indollars‒contractbudgetbase‒andhowlongitwill

take‒periodofperformance‒inhours,theestimates

submittedbythecontractortothegovernmenthastobe

inthoseunitsofmeasure.

StoryPointsandFunctionPointsarenotunitsofmeasure

inthecontractawardawarddocuments.

SowehavetoproducethisEngineeringEstimate inthose

units.

But,thoseunitscanbederivedfromFunctionalPoints,

Featureestimates,andreferenceclassesforecasts.

Thisisthecurrentchallengeindeployingagile

developmentinthefederalspace‒theunitsofmeasure

ofagilefromthecommercialworld,don'tmatchupwith

thefederal(FAR)procurementworld.

Thereisnosimplesolution,butatransitionfromthe

currentsituationtoonewhereagilecanprovide

informationforthedollar/hourestimatescanbe

developed,startingwithReferenceClassForecasting



Thecriticalsuccessfactorforallprojects‒agileor

traditional‒istomeasureprogressasActualPhysical

PercentComplete againstthePlannedPhysicalPercent

Complete atthePlannedTime.

Here’sanexamplefromanAgiletool(rally)wherethe

plannedpercentcompleteisdefinedinhoursfortheTasks

thatimplementeachStory.

ThestoriesimplementtheFeature,andtheFeaturemay

(inthisexample)spanmultipleSprints(threehere).

InagilenewworkcanbediscoveredaftertheSprintstarts.

Thisemergent workispartoftheagileprocessesandin

encouraged.

Thekeyhereis,whenthenewworkisdiscoveredtheTO

DOfieldisincreased.Thisindicatedmoreworkis

identifiedandthecurrentPhysicalPercentComplete goes

DOWN.

Intheinitialplannedeffort,100hourswereassignedothe

Feature.DuringtheexecutionoftheSprint25morehours

ofworkwerediscovered.Thatisrecordedinthesystem

andusedtocalculatePhysicalPercentComplete.

WhentheTODOequalsZERO,theUserStoryisdone.

WhenalltheUserStorieshavetheirTODOZERO,the

Sprintiscomplete,assumingtheSprintdidnotcometoan

endbeforethat.

TheformulaforPhysicalPercentComplete(P%C)is

P%C=(PlannedWork– TODO)/PlannedWork

IfthePlannedWorkgoesuptheP%Cgoesdown



WhileEarnedValueManagementmayappear

burdensomeandoverlycomplex,itisactuallyverysimple.

§ WhatisthePlannedBudgetforthedevelopmentofa

productorserviceataspecificpointintime?

§ WhatisourplannedPhysicalPercentCompleteatthat

pointintime?

§ WhatisouractualPhysicalPercentCompleteatthat

pointintime?

Withthosemeasures,wecandeterminehowfarbehind

weareinschedule,andhowfaroffweareofourbudget.

Withthosemeasures,wecandeterminewhatitwillcost

intheendandwhenwe’llactuallybedone,comparedto

whenweplannedtobedone.

EarnedValueisactuallyamisnomer‒itshouldbecalled

EarnedBudge.

WebudgetX$,didweearnedthatBudgetattheplanned

time?



WithaBudgetSpreadforthedevelopmentandsupport

staffandanyotherdirectcosts,themeasuresofPhysical

PercentCompletecanbeusedtocalculatetheearningof

value intheEarnedValueManagementsense.

ThisisnotbusinessValue,butitisthebasisofcomputing

theEstimatetoCompleteandEstimateatCompletion.

NormalAgiledevelopmentdoesnotprovidethese

measuresareinunitsmeaningfultothedecisionmakers.

TheseunitscanonlybeDollarsandHours.

ThisistheprimarybenefitofusingEarnedValue

ManagementonAgileprograms.



ManagingSoftwareDevelopmentprogramsisdifficult.It’s

notthesameasmanagingbendingmetalintomoney

programs.

Thedeliverablesareintangibleinthesenseyoucannot

countthem,weighthen,turnwrench'stoassemblethem.

Buttherearetangibleoutcomesofsoftwaredevelopment

programs‒workingsoftwarethatprovidesaFeaturethat

enablesaCapabilitiestoaccomplishabusinessfunctionor

fulfillaMissionneed.

TheseFeaturesandCapabilitiescanbeassessedthrough

MeasuresofEffectivenessandMeasuresofPerformance.

Whatisdifferenceiswemaybeableknowupfrontknow

neededCapabilities,MeasuresofEffectivenessand

Performance,butnowknowthetechnicalrequirements

thatwilldeliverthose.

ThisiswhereAgiledevelopmentcomesin.

ButthePrinciplesofProgramPerformanceManagement

basedonassessingPhysicalPercentCompleteagainstthe

MOE,MOP,TPM,andKPPsisthesameintraditionaland

Agileprograms.

WiththeuseofPhysicalPercentCompleteforthe

FeaturesintheWorkPackagesinthePMB,program

performancemeasurescanproducecredibleEAC,ETC,

andECDusingstandardmethods.

ItgettingthePhysicalPercentCompletethatistheCritical

SuccessFactor.



TheProductRoadmapisthestartingpointforEstimating.

ThisroadmapdescribedtheCapabilitiesneededbythe

customerinexchangefortheFundinginthecontract.

Thisdocumentispartofthetraditionalacquisitionprocess

– ConOps,IntegratedMasterPlanandAgile.

Acriticalsuccessfactorissimple

TheCustomerneedstoknowwhatDoneLooksLikeintermsofbusinessCapabilitiesneededtoaccomplishthe

MissionCapabilities Planning,isplanningunderuncertainty,to

providecapabilitiessuitableforawiderangeofmodern-

daychallengesandcircumstanceswhileworkingwithinan

economicframeworkthatnecessitateschoice.

Withoutthisunderstanding,we’renotonlynotgoingtobe

successfulatestimating,we’renotgoingtoreachDonein

anywaythatsupportsprojectsuccess.

InAgile,FeaturesandtheirStoriesandTasks,implement

theneededCapabilities

Storiesarethecriticalsuccessfactor.Thesestoriessaythe

following:

§ Whoistheuser?

§ Whyaretheyhere?

§ What’sanexampleofthisperson?

§ Whydotheywanttodothisthing?

§ What’sthebenefitofthemdoingit?

§ Howwillweknowitisworking?



InFARprocurement,thebudgetfortheprogramis

establishedatcontractaward.ThiscouldbeaNotto

Exceed,andIDIQ,aCPAwardFee,andavarietyofother

fundingvehicles.

Butthebudgetisonbaseline.Thisbudgetisconsumedin

anAgilesoftwareprogrambythedevelopmentstaffand

theirmanagement.

InAgiledevelopment– Scrum,XP,DSDM,andothers– the

spendprofileisessentiallyflat.NoCurve,nospikes,no

rampupandrampdown– flat.

Thisistheidealsituationtomeasureprogram

performancebymeasuringvalue producedinexchangefor

budget.

PhysicalPercentComplete,definedfortheEffectiveness

andPerformanceMeasures,startingwiththeConOpsand

movedtotheProductRoadmap,canproducetheestimate

toComplete,EstimateatCompletion,andEstimated

CompletionDatainunitsofmeasuremeaningfultothe

decisionmakers.TheseUnitsareDollarsandHours.

Theunitsofmeasureinagile– StoryPoints– haveno

meaningforthosedecisionmakers.



WiththecontractawardedandthePMBestablishedand

verifiedattheIntegratedBaselineReview(IBR),the

programcanstartstobeexecuted.

SuccessonAgileprogramsstartswithlimitingtheplanning

horizon.

RollingWaveplanningisonewaytodothis.Release

Planningisanother,butReleasePlanninghasatendency

tolockintheFeaturestoosoonandcommittothe

contentoftheRelease.

RollingWavesareeasiertomakechangesto,sincethey

arejustcontainersforthework,notthedefinitionofthe

work.

ThatdefinitiontalesplaceintheProductRoadmap,

ProductBacklog,andSprintBacklog.Therollingwaveis

justanartificialboundariestoperformthework,thenstop

andassesstheprogressfortheworkperformed



Inthepresenceofuncertainty– bothaleatoryand

epistemic– requirementsevolveasanaturalprocess.

Inagileweencouragerequirementsevolution,sincewe

arediscoveringtheneedsofthecustomeratthelower

levelsofdetail.ThisideaispartofthecultureofAgile.

ButthereareotherdriversfortheuseofAgile.

Theriskproducedbytheuncertainty,theevolutionofthe

systemfromit’suse.



§ Benchmarking‒thefunctionalsizeprovidedisassumed

tobethesizeofthesoftwaredeliveredattheendof

theproject,regardlessifthesoftwaredevelopmentor

managementmethodwasAgileornot.Itisreasonable

forAgileprojectstoprovidetheFunctionalSize

Measurementoffunctionalitiesdeliveredatproject

end.

§ Upfrontestimation‒programrequireallocating

budgetpriortostarting,basedonitscostestimation.

ThefirstchallengeinanAgilecontextistoobtainthis

estimationforadefinedprojectscope.Attheearly

stageofanAgileproject,scopecanbedefinedasalist

ofneededCapabilities,withtheirfunctional

requirementsbehaviors(FeaturesandStories).

§ IterationPlanningandProjectRe-Estimation‒AtSprint

Planning,withfunctionalsizeestimated,itis

appropriatetoperformaFunctionalSizeMeasurement

onProductBacklogitemsforthecurrentSprint.

§ ProcessImprovementMonitoring‒continuousprocess

improvementthrough“retrospective”isperformedat

theendofeachiteration.



SuccessforAgileprojectsstartswiththeRFP/RFQ.

That’swherethegroundrulesfortheagileacquisitionare

laiddownforthesuppliers.

InthePWSthesupplierneedstodescribetheSoftware

DevelopmentMethodandhowthatmethodimplements

the12PrinciplesofAgile

AProductRoadmapisthefoundationofsuccessforAgile

projects.ItstateswhatFeatureswillbecontainedinwhat

releasesandwhenthosereleaseswillbereadyforuseby

theGovernment.ThereleasescanbeCapabilityReleases

orCadenceReleases.

APerformanceManagementPlanandQualityAssurance

SurveillancePlan(QASP)arethebasisofassessing

programmaticperformanceoftheprogram.Thisiswhere

theMeasuresofEffectiveness,MeasuresofPerformance,

andKeyPerformanceParametersarecollected.

TheseareconnectedtotheReleasedCapabilitieswith

thereFeaturesandformthebasisofPhysicalPercent

Complete.



StartingwithITsystemssubjecttoOMBA-11Part7and

movingontheFAR34/DFARS234systems,agile

developmentprocessesareintegratedwithEarnedValue

Managementinthefollowingway.

EvenwithouttheflowdownforEVM,managingthe

developmentofsoftwareusingAgile,insideaFAR15

contract,canbedonewiththisstructure

§ Definetheneededcapabilities

§ ProduceaProductRoadmapandReleasePlan

§ Assignbudgetforthestaffdevelopingthesoftwareat

theSprintlevel

§ DecomposetheCapabilitiesintoFeatures,theninto

Stories,andassignthedevelopmentworktoSprint.

§ PerformtheworkintheSprint

§ MeasurePhysicalPercentCompleteattheSprintlevel

§ RollthisPhysicalPercentCompletetotheFeaturesand

CapabilitiesandcalculateETC,EAC,andECDfromthose

measures.



Agile for DHS 2017 June26

Technology

Transcript of Agile for DHS 2017 June26