L.Castro.W.Smith.Infusing an Agile Requirements Backlog in ......SWAT team” concept previously...

InfusinganAgileRequirementsBackloginaLargeDepartmentofDefense(DoD)Program LYMARICASTRO,DepartmentofDefenseWARRENSMITH,WRAYN,LLC

Unlike commercial Agile practitioners, the Defense sector hasmore restrictionswhen restructuringmilestones for an Agile approach.However, by leveraging techniques fromAgile software development into the Systems Engineering domain, it is possible to overcomethose constraints and bring the benefits of Agile to one of the largest,most needed areas of development. This report documents thepracticalapplicationofAgiletechniquestocreatearequirementsbacklogforalargeDoDproject,withinDoDconstraints,andbeforetheteamevenknewabouttheexistenceofAgile.ThereportalsohighlightsthecharacteristicsofAgileSystemsEngineeringlearnedfromtheexperience, the organization of the teams, and the MBSE technical storyboarding and allocation approaches that resulted in theaccelerationof theprogram’sSystemsRequirementsReviewmilestoneby70%.The reportpresentskey considerations for scaling thetechniquesusedduringtheexperienceforalargeadoptionofAgileinDoD.

1. INTRODUCTION

The Defense sector presents unique challenges for the adoption of Agile techniques. Defense programs aretypically characterized by the presence of multiple and diverse sets of stakeholders, each with differentrequirements for performance, funding, and schedule. Often, end-users are co-located with the systemsoverseasandarenoteasytoreachtogathertheirfeedback.Inmanyinstances,DoDhasseparate“Oversight”and “Development” organizations, which adds levels of bureaucracy, slowing down communicationsthroughouttheprogram’slifecycle.

Today,mostDoDprograms are implementing some type ofAgile software developmentmethodology toaccelerate their deliverables. However, these programs may be overlooking the benefits of adopting Agilebeyondthesoftwaredevelopmentdomain.

This experience report dives into the practical implementation of Agile in the Systems Engineering (SE)domaintogeneratearequirementsbacklogwithintheconstraintsoftheDoDacquisitionlifecycle.Theproductdeveloped was a complex system-of-systems comprised of both hardware and software components. Thisexperience report dates to 2009, thus preceding the 2015 release of the DoD 5000.02 instruction whichprovides guidance for iterative and incremental releases of capabilitieswithin theDoD acquisition lifecycle.Moreover,thetechniquesandaccomplishmentsreportedhereinwereachievedwithouttheteambeingawareoftheexistenceofAgiletechniques,ortheirpotentialuseinSE.

This experience therefore presents an authentic validation of Agile SE. The approach led to a 70%accelerationof theDoDSystemsRequirementsReview(SRR)milestone. It validates that shifting fromusingAgileforrapidproductdeliveryintoanend-to-endassetdoesinfactenhanceteamproductivity,processes,andeffectiveness,aswellaspromotesfrequentcollaborationandcommunication.

The experience report elaborates on the application of Agile techniques used by Mr. Smith’s team toaccelerate the SRR milestone of a major DoD acquisition program, and provides insights about how Ms.Castro’sDoDorganizationwillleveragethisapproachtosupportalargeadoptionofAgileinDoD.

2. BACKGROUND

Mr.Smith isaSystemsEngineeringPartneratWRAYN,LLC.Hehasbeenutilizingsystemsengineering toolsand methods his entire career. He has worked as a Systems Engineer, a Program Manager, a University

LymariCastro,DoD,FT.Meade,MD,[email protected],WRYAN,LLC,[email protected],[email protected].

InfusinganAgileSystemsEngineeringBackloginaLargeDepartmentofDefense(DoD)Program:Page-2

Instructor,aFieldEngineerandentrepreneur.His30yearSEcareerhasspannedsystemsdevelopment,test,and working for tool vendors. As a long-time entrepreneur, he has developed re-use methodologies anddeployed Agile techniques in seemingly inflexible organizations. Currently, he is providing SystemsEngineering to convert piloted helicopters to autonomous flight. His company’s primary focus is supplyingexperience-basedon-lineand live-learning inAgile,MBSE, andRe-Use.Whilehehasworkedonavarietyofsystems including Military Vehicles, Rotary and Fixed-wing aircraft, Spacecraft, Training Systems, MedicalDevicesandIT,hesaysworkingonamusementparkrideswasthemostfun.

Ms.Castro is aLeadSystemsEngineerworkingatDoD. Inher14yearsworking there, shehasbeen theLead Systems Engineer of a major DoD program, a Product Owner and team lead of a SCRUM softwaredevelopment team delivering capabilities for a major DoD program, and a subject matter expert in herorganization on the topic of Agile systems engineering. She is currently championing efforts for a largeadoptionofAgileatherorganization.

Throughout the years, the authors have worked on large multi-year DoD programs and experiencedcustomerdissatisfactionfortworeasons:(1)Thedeliveredsystemstypicallydonotmeetexpectationssincesystem requirements negotiated early in the program’s lifecycle are never revisited or updated to assesschangingcustomerneeds,and;(2)TheSEphasehasbeenlengthy,oftenwithdetaileddesignstartingpriortocompletionofSE’ssystemspecification.Traditionally,SEfollowsasequentialwaterfalllifecycle,whereoncealifecyclephasehasbeencompleteditisnotrevisitedagainduringtheprogram’slife.Inmanyinstances,SEandsoftwaredevelopment teamsareseparateworkunitswithminimal interactionwitheachother, leading toadisconnectbetweenimplementationandthesystem’srequirementsthatwereidentifiedearlyintheprogram.Thisoften results in the reworkof SEproducts.Evenworse, SEartifacts andprocesses canbeperceivedasbeingdoneonlytocomplywithpolicy,andnotasanactivitythatdeliversvaluetotheentire lifecycleof theprogram.

Intoday’sdynamicenvironmentwheretechnologyisconstantlychanging,requirementsarenotexpectedtobestaticduringthelifecycleoftheprogram;andthereisademandforflexibleSEprocessesandprogrammilestonestoincorporatenewrequirementsidentifiedthroughcustomerandend-userfeedback.

This experience, performedduring the infancyof formalizedAgile SE concepts, superbly alignswith andvalidates what have become currently-accepted Agile SE techniques. We offer up alternatives wheredifferencesdoexist.

3. DEPLOYINGANITERATIVESYSTEMSENGINEERINGAPPROACHINALARGEDODPROGRAM

3.1 Scopeofeffort ModernizemajorArmyvehiclesystem-of-record:AcomplexSystemofSystemsIn the 2000s, the US Army initiated a large program to modernize one of its combat vehicle systems. Theprogramconsistedofa complexsystem-of-systemscomprisinga familyofvariantvehiclesbuiltoncommonarchitectures.For thisprogram,bothhardwareandsoftwareupgradeswereplanned.Theupgrade includednew systemsoftware, processors, sensors, controls, displays and communications.This reportdiscusses theperiodoftimeleadingtotheSystemRequirementsReview(SRR).

Mr.Smiths’sportionoftheprojectwastobeexecutedinthreestages:Stage1: PreparingfortheanalysiseffortduringNovemberandDecember;Stage2: Performingtheactualworkofanalyzingover50systemcapabilities, fromJanuarythrough

May,and;Stage3: SuccessfullycompletingaSRRinJune.

Thesecondstagecompressedwhatnormallywouldhavebeen18monthsofanalysisintoamere5months,aseemingly impossible70%reductionof theschedule.This typeofreductionhadneverbeenperformedbythe organization before. None the less, it had to be done: the SRR is a high-stakes review inDefensework,usually tied toprogresspayments from the customer.Failurewasnot anoption.Without thebenefitof anyspecificmethodology to fall back on, the teamwas forced to come upwith a new approach to achieve thisobjective.

During theDoDSRRMilestone, the systemdeveloper (the “PrimeContractor”, or “Prime”)demonstratesunderstanding and mastery of the system requirements to the Customer (the U.S. Army in this case), andallocates those requirements to the implementation teams. It is important to deliver the work productsrequired;otherwisetheresultscouldberejected.


The system functional requirements describewhat the systemmust do to satisfy itsmission objectives.“Allocation”ofthosesystemrequirementsinvolvesderivingasetofsubsystemrequirementswhichtogethercollaboratetosatisfythesystemrequirements.Therequirementbacklogsareprovidedtoindividualteamsforimplementation.

Thisexperiencereportfocusesontheworkperformedtogeneratethesystemfunctionalrequirements,andthe subsystem functional and interface requirements.The “requirementsbacklog”was the set of “allocated”subsystemrequirementsreceivedbyeachimplementationteam.

3.2 Stage1:Preparation,Planning,CoordinationandTraining:NovemberandDecemberInSeptember,Smith’scompanysubmittedacompetitiveproposalwhich includeddeployingan“EngineeringSWATteam”conceptpreviouslyusedatthePrime.TheSWATapproachbroughtinaspecializedteamwithtoolskills fordocumenting, leadershipskills for facilitating,anddomainexpertise for focus, to rapidlyacceleratetechnical progress. Previous beneficiaries at the Prime had described Smith’s Engineering SWAT team as“…doing the impossible…”. In lateOctober, thePrime awarded the subcontract to lead the SRR effort to hiscompany.

Withnomethodologicalbasistobuildfrom,thefirsttaskwastodeterminekeysuccessfactors,anddeviseaworkable approach to complete this work. November and December were consumed with planning, andbuildingtheteam.

TheApproach:PlanningforsuccessPlanning Success Factor 1: Eliminating the Review Cycle.One primary factor that could thwart the

effortwasstakeholderbuy-in.OnDoDprogramsthenandnow,thereview/signoffprocesstypicallyinvolveshavingmanypeople reviewand commenton a completedworkproduct such as specification,after a smallteamhas invested significant timedeveloping it.This time-killingprocess involves creating aworkproduct,elicitingcomments,negotiatingupdatestotheworkproduct,thenfightingfor(orcajoling!)signofffromallofthestakeholders.Worse,multipleiterationsandadditionalnegotiationsareusuallyrequiredaspeoplelearnofthechangesothershavemade.Thereview/signoffalonewouldcausethescheduletounravel.

Theonlyway toavoid thisdire fatewas toobtain concurrenceaspartof theworkcycle.This requiredincluding all stakeholders during the analysis. Therefore, Smith decided to develop the analyses with allstakeholderstogetherintheroom.Whendisagreementssurfaced,thestakeholdersthemselveswoulddirectlynegotiate the resolution, collaboratively resolvinganydifferences.Once theanalysis satisfiedall theplayers,concurrencewassimplyabyproduct,notanadditionalstep.Intheend,theeffortwassuccessful,provingthistheorycorrect.DuringNovemberandDecember, thePrimecoordinatedandobtainedcommitments fromallthestakeholders toparticipate in theanalysismeetingsstarting in January.Thesestakeholders included thecustomer,thedevelopmentteamswhowouldbereceivingtherequirementsbacklogs,andthetestingteams.The Prime also coordinated to have the customer invite system users, in this case soldiers, to the analysismeetings.

Oncethedecisionwasmadetoperformtheanalysesinteamsettings,somesimplemathdeterminedhowmany would be required. In the 20 weeks between January and May, three teams each with 17 analysestotalingmorethan50,wouldneedtobecompleted,atarateofaboutonefullanalysisevery5to6days.Thatmeantthatallstakeholderswouldneedtolendupto3peopletotheeffort:oneforeachteam,for1to2hoursper day for nearly the entire 5month period. Smith selected his three team leaders largely based on fourqualities: leadership skills, communications skills, facilitation skills, and tools skills. Each team leader wasprovided a list of system capabilities to analyze and prioritize. The capabilities were prioritized based onavailabilityofsubjectmatterexpertsandcomplexity.

Theconsiderablecoordinationeffortcannotbeunderstated.ThePrimeobtainedbuy-inonourapproachfromthemanagersandcustomer.Skepticalmanagershadtobepersuadedtocommitsignificantresourcestotheeffort.Becausetheimperativeofmeetingtheshortschedulewassocritical,andtheconsequenceoffailuresogrim;managersagreedtotaketheriskonthiscompletelynewapproach.

PlanningSuccessFactor2:ModelBasedSystemsEngineering(MBSE).ASEModelwouldsourceandwarehousetherequirements.Atthetime,themodel-basedsystemsengineering(MBSE)conceptwasgainingwideracceptance.ThetoolusedbytheCustomerwasRhapsody,atthetimeownedbyTelelogic.InNovemberandDecember,Smithprocuredcopiesofthetool,andtrainedthethreeteamleadstoactastooljockeysaswellasleaders.ThetoolframeworkwasalsostructuredbythePrime’smanagertosupportthemodelintegrationthatwouldberequiredasmultipleteamsbuilttheirmodels.


Planning Success Factor 3: Easy to Understand Storyboards. The final critical factor was ensuringpeople could easily understand the analyses. To be successful, only easy-to-understand analyseswould do;understandingoverlycomplicateddiagramsorlengthypagesofdrytextwouldsidelinetheeffort.Therefore,Smith chose to use a technique unknownwithin thismilitary-vehicle community called, “Storyboards”. Thismethod involves creating images on individual sheets representing scenes in a sequence of events. In afunctional analysis, this would allow functional sequences (at the system level) to be quickly drafted,reorganizedandvisualized.Thistechniquebridgedthedividebetweenthesoldier’soperationalworldandtheengineer’s development world, thus becoming one of the key pillars of success for the effort, and wasenthusiasticallyreceivedbyallparticipants.Inaddition,storyboardsgreatlyreduceddiscussionbecause,asitturnsout,apicturereallyisworthathousandwords!

3.3 Stage2:Analyzingover50systemcapabilitiestocreatetherequirementsbacklog:JanuarythroughMay

ByJanuarytheworkwasreadytobegin.Theinfrastructurewasinplace,theteamsandcustomerwerealigned,andcritically,monthsofscheduledmeetingswereestablished.

We began by analyzing a relatively simple capability to ease into the “daily meetings”. Smith and thePrime’smanager led the first assessment. Since thiswas the first timeworking thismethod, all three teamleadersattended the firstassessment toensureconsistency inourapproach.The firstparticipantswere thecustomer,thePrime’sdevelopmentteams,andtheSWATteamleaders/tooljockeys.

Iteration 1 – System Level Capability Analysis using Activity Diagrams. SysML “Activity Diagrams”were chosen as the primary artifact for capturing the system functional analyses. As the team progressedforward,thecustomerswoulddescribetheirvisionofthecapability.TheleaderquicklydocumentedthedialoginRhapsodyusingActivityDiagrams.Asthefunctionalsequencewasdescribed,theactivitydiagramsevolved.Sequentialandsimultaneousbehaviorswerecaptured.Anincrediblenumberofnotescapturingthethoughts,concernsandexperiencesoftheparticipantsfoundtheirwayonthepage.Atthisstage,“pretty”pictureswerenotapriority:simplygettingthewealthofinformationintothemodelwastheprimaryobjective.

BuildingEffectiveTeams.Akey leadership factorwasastrongknowledgeofSE. Itwascrucial that theSWATteambeabletoquicklyoperatethetooltosummarizediverseperspectivesintowordsandpicturesinthe model. The SWAT team members all came from Systems backgrounds, which leant itself to valuablecategorization of information. Organizing the deluge of data in real time was a key skill. Recognizing thedifference between functional, interface or constraint requirements meant more focused discussion.Understandingthesystem’slevelsofabstractiontoproperlyassigninformationreassuredtheparticipantsthatkeypointswouldn’tbelost,eveniftheyweren’timmediatelypertinent.Interpersonalskillswerealsokey.Aswithanygroupendeavor,somepeoplehadatendencytomonopolizetheconversation,ordrivethefocusonnarrowaspectsof theeffort. ItbecameclearthattheSWATteamswouldalsobe“facilitators”. Itwascriticalthatallvoiceswereheardandthatworkprogressedapace.SelectingtheSWATteamfortheirleadershipskillsturned out to be a fortuitous decision. Key skills in this area included active listening, articulating back topeoplewhoarepassionateabouttheirpointsthattheywereheard.

DailyRhythm:MorningMeetings.Themeetingmechanicswerestraightforward.Themeetingswereheldeverymorning for 1 to 2 hours. The facilitator coordinated themeeting, startingwith a specific topic to beaddressedby the stakeholders.Often thediscussionwouldexplore tangential topics,whichwouldbe run toground.Throughouttheentireeffort,theleaderswouldcapturetheinputs,thoughtsandinsightsoftheteammembers in the model as quickly as possible. Where possible, specific verbiage for function (i.e. activity)names,descriptionsandrequirementswerehashedoutinthemeetinguntilallparticipantsagreed.

DailyRhythm:Preparing forTomorrow.After themeetings, themajorityof the teamwould return toworkattheir“dayjobs,”attendingtowhatevertaskstheyhadontheiragendas.FortheSWATteamleaders,the remainder of thedaywas spent organizing the flurry of notes that hadbeen taken at themeeting. Thisprimarilyconsistedofcleaningupthediagramcontent,ensuringsemanticallycorrectmodels,andintegratingthe model elements created that day with previous models. For example, normalizing “sendmessage” and“transmit message” with the correct parameters. In addition, when concurrence on verbiage for therequirements was lacking, the leaders would apply their SE skills and craft well-written requirements.Completingthisclean-uptaskoftentooktheSWATleadersalldayandwellintotheevening.

Theresultswereimpressive,however.TheneteffectwasholdingtothethreedaysofSystemAnalysis,andthreedaysofAllocationanalysis,percapability.


CustomerandEnd-UserEngagement.Fromthebeginning,weobtainedcustomerbuy-inandreasonableparticipation. This ensured thatwe incorporated the input from the Government engineering civil servantsmanagingthecontract.Whilenotparticipatingdaily,theU.S.ArmyCustomerparticipatedenoughtofeelverycomfortablewithoursystem’soperationalanalysis.OurearlyrequestforActive-Dutysoldierswhoknewthesystemresulted inoneveryproductivevisit.However, theirparticipationwasrestricted.To fill thisgap,weturnedtothePrime’sworkforceitself.Dozens,ifnothundreds,ofReservesoldiersworkedattheplant,manywith recent deployment experience working with our system. We elicited those with recent combatexperience, in using, maintaining and supporting our system as crew, logisticians, and mechanics. Weenthusiasticallyengagedtheseusers,whoparticipatedinourdailymeetingsandaddedtremendousvaluetoouranalyses.

Early in the effort, we discovered that graphics could be attached to the model activities, taking fulladvantageoftheStoryboardconcept.Smithaddedtwopart-timeartiststothemeetingstoproducethestoryartwork. By understanding the behavior, they developed rough, but descriptive sketches representingeverythingfromconceptdrawingsofnewequipment,todepictionsofsoldiersoperatingtheequipmentwhichprovidedavery-understandableflow.

Figure 1 displays a close-up, sanitized example of one of themodels showing how the graphics helpeddescribe the system operation. The red box shows the context of this segment in the broader model. Thebroadermodelshowsthehighdatadensitydevelopedduringtheeffort.Eachyellow“note”istiedtoactivitiesordataflows,andrepresentsarequirementderivedfromtheActivityDiagram,operationalcapabilities,designdata or architectural constraints. As the anticipated issues arose, and the inevitable engineering changesoccurred,theywerefoldedseamlesslyintothediagrams.

Therequirementswereaggregatedintoasystemspecification,withthemodelsincludedascontext.

Figure1.StoryboardExampleandDataDensity

Iteration2:AllocationofSubsystemsRequirementBacklogs.Thefirstiterationconsistedofasystem-level black-box assessment. It ensured all capabilities of the system, as a whole, were fully analyzed andsystem-levelrequirementsweregeneratedandvalidatedwithallstakeholders.

The second iteration had a white-box subsystem-level focus. Starting with the requirements for eachsystem action, we analyzed the internal system behavior for that action to identify the functions eachsubsystemteamhadtoimplement.Additionally,wedefinedthesubsysteminterfacesrequiredtosupportthatbehavior.Itwasinthisiteration,thatweactuallygeneratedtherequirementsbacklogs,whichweinfusedintotheorganizationusingournewSEapproach.

The hardware/software subsystem architecture receiving the allocated behaviorwas defined previouslyand owned by the implementation teams. Therefore, by defining the functions and interfaces for eachsubsystem,wewereabletohand-offarequirementsbacklogtoeachimplementationteam,withthebacklogsdirectlytraceabletosystembehavior.

Hadwe not inherited the architecture, a similar approach could have been used to develop the systemsarchitecture. In future publications, the authors anticipate describing how to apply Agile SE techniques todevelopthesystemarchitecture.

In lightof thewhite-boxapproach, the Iteration2taskswereslightlydifferent.Thetasks involvedtakingeachactivityfromthesystemmodels,andbreakingthemdownintoaseriesofstepsperformedbythesystemusingasequencediagram.Theplayersforthisactivityincludedmembersoftheimplementationteams.

Weused the same team-approach,with the facilitator/tool jockey, the dailymeetings, the “cleanup” andmodelintegrationduringtheday.Butthisiterationinvolveddecomposingeachactiononthesystemactivitydiagramseparately.WegeneratedsetsofsequencediagramsfromeachActivityDiagram.


As depicted in Figure 2, sequence diagrams show blocks at the top, each representing a hardware orsoftwareelementofthesystem.Theverticallinedroppingfromeachblockor“lifeline1”representsthelifeofthat subsystem over time, which flows down the page. Interactions between lifelines represent subsysteminterfaces.Reflexiveinteractions(to/fromitself)arebehaviorsthatthesubsystemperforms.

Duringthe Iteration2meetings,wenegotiatedthe interfacesbetweenthesubsystems,and identifiedthereflexiveiterationbehavioreachsubsystemneededtoperform.Wewroterequirementsforboththeinterfacesandthesubsystembehaviors,andrelatedthemtoeachoperationasshowninFigure2.Theserequirementsthenbecametherequirementsbacklogsforeachimplementationteam.

Thenegotiationprocessbetween the teamsexhibited some interestingdynamics. ItbecameclearduringIteration 2 that some needed behaviors were overlooked during the bidding process. One benefit of thisprocess was that all needed functions were unmistakably obvious. But on several occasions, the cost ofimplementing specific functions was more than a team could afford.Watching the teams hash out variousallocations was a revelation. Typically, omissions of this type don’t surface until well into design, oftenremaining hidden until they reveal themselves during integration or test,when the cost impact is themostdamaging.Anotherunforeseenbenefitwasitsflexibilityinhandlingdynamicrequirementschanges.

Figure3depicts the iterativeprocessourteamused.At thetime,wedidnotknowthatthiswasanAgileprocessverysimilar toSCRUM!Figure3showshowthe50+systemanalysesweredividedamongthethreeteams.Eachteamhelddailymeetings,brokenintotwo,3-dayiterations;thefirstiterationproducedthesystemfunctions,whiletheseconditerationallocatedtosubsystembehaviorsandrequirementsbacklogs.

Figure2.RequirementsAllocatedtoEachTeam(sanitized)

Figure3.TheIterativeProcessUsed

The pace of the entire effortwas grueling. The teammemberswere thrust togetherwith varying inter-personal skill-sets.Somepeople thrived.Tempersdefinitely flaredonmultipleoccasionswheneveropinionsclashed.Therewereevenafewpeoplewhofeltunsuitedtotheintensepaceoftheeffort,andchosetoleave.Theywerereplacedwithindividualsbetterequippedtoparticipate.Thisself-adjustmentresultedinteamsthatoperatedefficientlyandfocusedondeliveringvalue.

3.4 Stage3:SuccessfulCompletionoftheSRR-JuneBytheendofMay,theteamswerewrappinguptheirwork.Therequirementswereexportedfromthemodelandplacedinadocumentfordelivery.Thedocumentwasapprovedbythestakeholders,whichtookonlythetimeneededtoroutethedocument.Asplanned,noadditionalreviewcyclewasneeded.Preparationbeganon

1 Lifeline- Standard SysML term


the SRRmaterial. Thedecisionwasmade topresent the actualActivityDiagrams for eachof the50 systemanalyses to theGovernment.ThePrimedecided tohaveMr.Smith’s teamactuallypresent thematerial, inahumblingdeparture from commonpractice. It is highly unusual for a Prime to invite their subcontractor topresentatreviewsofthistype.Thisfacthowever,validatesanimportant,oftenunder-lookedbenefitofAgile:creationofthe“badgeless”teamasorganizationallinesfallasidewiththistypeofmulti-disciplinaryteam.

The reviewwent verywell. To ensure the audience remained cognizant of the “big picture”,we created“zoomout”slideswithidentifiedzoneswhichcouldbereferencedaswezoomedintothedetails.

The Government customer typically invites other agencies to these reviews. These other Governmentparticipantsoftenask thePrimeprobingquestions froma freshperspective.Anunintendedconsequence toour Agile-like approach was that our Government customer answered many of these questions. Theirparticipationintheprocess itselfbroughtahighdegreeofknowledgetoandownershipintherequirementsthatreducedtheprogramrisks,andvalidatedourapproachinanunexpectedfashion.

4. WHATWELEARNED

Amongthemanylessonslearnedfromthisexperience,thefollowingarethemostimportant: Storyboards. We were successful in engaging the Customer in this process. By clearly conveying the

nuances of the system operation relative to every stakeholder, the Storyboards were absolutely critical indrawingouttheirinput,andultimately,theirapproval.

ChangeManagement.Requirementschangeswereeasilyaccommodatedusingthisapproach.Thisledtoamuchmorethoroughspecification,andamorecompletedesignactivity.

InformationDensity.Webenefitedfromtwotypesofinformationdensity.First,weperformedtheworkinonly30%ofthetypicaltime.Theteamaddressedissuesastheyarose,makingdecisionsorquickfollow-upsafteronedayof ‘homework’.Problemsnever lingered,andwerequicklyresolved. Insteadofadozenemailsover the course of days, our approach resolved most issues within 20 minutes. Second, the density of theinformation on the model pages was incredibly high as shown in Figures 1 and 2. These work productsincluded:Analysis,Requirements,TraceabilityandAllocation,allwithouthavingtothumbthroughdocuments.

Self-Organization.Ourself-organizingteamsuccessfullyadjustedtoteammember’sneedsaswarranted.MaximumBenefits,MinimumChange. Themost important validation is this: this systemWORKS!We

successfullyaccomplishedtheobjective,whilefittingwithintheDoDmilestones.Theimportanceofthiscannotbeunderstated.Whilemanypeople,correctly,pointoutthatevengreaterproductivitygainscanbemadebychangingtheDoDacquisitionlifecycle,therealityisthatanundertakingofthismagnitudewilltakemorethanachangeto5000.02,asimportantasthatis.Ittakesaculturalchange:achangeintheperspectivesofdozens,ifnothundredsofstakeholders.ThisprocessvalidatesthatgainingAgilebenefitscancomewithoutchangingtheacquisition lifecycle. These benefits can be enjoyed today, while providing a vision of the even greaterproductivitywhichawaitstheorganizationtomorrow.

MBSE. Show me, don’t trust me. This process quickly brought the benefits of MBSE and Agile toorganizations. This effort shows a path that can deployMBSEwith aminimum investment. As the benefitsbecomereadilyapparent through themodels themselves,moreorganizations can invest in theirownSWATteams,spreadingthemethodsthroughouttheorganization,secureintheknowledgethatresultswillfollow.

Relating to Agile. After successfully concluding the SRR, we ran across the software Agile Manifesto,learned of the many Agile software techniques, particularly SCRUM, sprints and backlogs. As we mentallymappedourapproachtoAgile,itbecameclearwehadindependently‘discovered’,andvalidated“AgileSE”.

AgileSEWorkProducts.AkeylessonlearnedisthatAgileSEdoesdifferfromAgileSoftwaredevelopment.Agile SE is characterized by the creation of SEwork products. Unlike Agile software development, whichreleases completed software versions at the end of each sprint, Agile SE won’t update ‘the whole system’.Instead, Agile SE uses Agile techniques to release SE work products such as specifications, systemarchitectures,tradestudiesorverificationplans/procedures.

ValidatingAgileSE.Aswehavementioned, thisexperienceoccurredabsentanyawarenessofAgile,butusedmanyoftoday’sformalizedAgileSEapproachesandtechniques.Inaddition,theeffortfitneatlyintopre-existingDoDmilestones.Therefore,thisexamplecanbeveryusefulinconvincingyourorganizationtoadoptanAgileSEapproach.Why?BecauseitprovidesindependentvalidationthatAgileWORKS,andisLOWRISK!

APPLYING THE LESSONS: We seek to replicate the success of our approach at Ms. Castro’s large DoDorganization. To that end, wewill leveragemany of the techniques proven during our foray into the Agileworkplace,andmodifysomeofourapproachestoaccommodatethewiderdeployment.Table1categorizesthe


techniquesusedduring thisexperience thatweconsideravalidationof theAgileSEconcept.The tablealsoidentifieshowthetechniquescanbeadaptedtoanenterprisedeploymentofAgileSE.

Category ValidatedAgileSystemsEngineeringTechniques

ProposedChangesforaLargeDeploymentofAgileSystemsEngineering

BusinessProcesses

Establishfrequentcollaborationmechanismsthatfacilitatecustomerandend-useengagement.

Establishorganizationalprocessesthatprovidetransparencyofinformationandtraceabilitybetweentheorganization’sportfoliorequirementsandthedevelopmentteamsrequirements.

ClearScopeBreakacomplextaskintosmallermanageabletasks.Havecommongoalsandobjectives.

PlantheAgileSEworkitemsinsmalltasksthatprovidethemostvaluetotheorganizationorproject.

CustomerEngagement

Haveacustomerrepresentativeparticipateintheprocessandprovidefeedback.

AssignaChiefProductOwnerwithmultipleProductownersforeachoftheorganizationalproductlines.

End-UserFeedback

Identifyrepresentativesfromtheend-usercommunity.GatherfrequentfeedbackandincorporateaspartoftheAgileprocess.

Identifyrepresentativesfromthemultipleend-useorganizationsacrosstheEnterpriseandmakethemparticipantsoftheprocess.Provideempowermenttotheusercommunitytomakedecisionsregardingthesystembeingdeveloped.

IncrementalDelivery

CreateanddeliverSEproductsincrementally.DeliverincrementalSEproductsataconstantpace.

AlignAgileSEandsoftwaredevelopmentteams’deliverableswiththeDoDacquisitionlifecyclemilestonesandtechnicalreviews.

IterativeAnalysis

Useshort(6days)iterationstoanalyzeandallocatesystemandsub-systemrequirements.

Useshortiterations(lessthan3weeks)todeliverSEartifacts,whichincludethetraceabilityofrequirements,usecases,testcasesandarchitecturalmodels.

Table1.ValidatedAgileSETechniquesandtheirApplicationinaLargeDeploymentofAgileSE

5. CONCLUSIONS

We found the techniques discussed in this experience report instrumental to transition the traditional SEprocess to Agile SE while supporting a large DoD acquisition program. The techniques provided tangibleresultswiththefollowingbenefits:• Theprocessmadeiteasierforthestakeholdersandleaderstoidentifythestrengthsandweaknessesofthe

systemtobedeveloped;• Theteamswereabletostayfocusedonthehighvaluetasksandsharedacommonvisionofwhatneeded

tobedoneandwhy;• The SE teamswere frequently improving their internal processes as they gainedmore experience and

knowledgeaboutthesystemtobedevelopedandtheirownprocesses;• TheSEproductswerekeptcurrentanduptodate;• Acquisition programmilestones and technical reviews could be achieved in a shorter timeframewhen

comparedtothetraditionalwaterfallDoDlifecycle.• The process helped bridge the gap between the software development and SE teams since they had to

frequentlycollaborateandexchangeinformation,inthisnewapproach.

6. ACKNOWLEDGEMENTS

Mr.SmithwouldliketoacknowledgeandthankhisfriendandmanageratthePrimeduringthiseffort,JozsefBedocs. Inadditiontoperformingthenecessarycontractualandorganizationalwork, itwasMr.Bedocswhobuilt the RhapsodyMBSE frameworkwhich enabled the dailymodel integration. Ms. Castrowould like tothankherorganizationforprovidinganindependentreviewofthisexperiencereport.

Whileboththeauthorsarepreviouslypublished,weareprimarilyproductsofthe“schoolofhardknocks”-reallifedeploymentsinhigh-stakesenvironments.Whileverygratifying,ouracademicpublicationdeficiencieshave leftour rawauthoringskills somewhat lacking.Thathasmade theshepherdingprovidedbyMaryAnnLaphamanevengreateradvantage. Inaddition tosuggestingmuch-neededchanges in thereport’s flowandclarity,Ms.Lapham’sincredibleoptimismandherbreadthofexperienceandknowledgeinAgilehasmadeourregulareditingsessionsahighlightofeachweek!Thankyousoverymuch!

L.Castro.W.Smith.Infusing an Agile Requirements Backlog in ......SWAT team” concept previously...

Documents

Transcript of L.Castro.W.Smith.Infusing an Agile Requirements Backlog in ......SWAT team” concept previously...