the convergence of scrum and devops for an agile it ... · pdf filea minimum the...

devopsinstitute.com,©2017AllRightsReserved |1

W hitepapers

“Softwareiseatingtheworld.”1

Software is pervasive; it influences every aspect of ourmodernworld. It enablesorganizations todeliver better products, faster and with higher quality. It enables organizations to create new,smarter products that deliver better customer outcomes. It also enables organizations to betterunderstanduserneedstobecomebetteratdeliveringbetteroutcomes.

Software isalso thesourceofdisruption.Organizationswhocanuse it toadaptandevolve fasterout-perform their non-digital counterparts.2 The formula is simple, yet hard to embrace:organizations that harness the power of software master rapid empiricism, the ability to quicklyform hypotheses, try them, gather and analyze the results of these experiments, and use theinformationtoimprove.

Theworldischangingatanincreasinglyfasterrate,drivenbytheincreasedvelocityoftechnology,marketsandclimatechange.3Theonlywaytorespond,survive,andthriveistoembracethechangeandbecomebetteratturningitintoanadvantage.

TwoMovements,OneGoalAgile andDevOps are the primarymeans bywhich organizations are driving these changes. Theysharemuch in common: faster delivery cycles, smaller increments (or batches) of releases, usingfeedbacktoimprove,removingwasteandimpediments.Theiremphasisvaries,andthissometimesleadspeopletobelievethat theyaredifferentthings.Agileemphasizesteaminteractions,culture,andvalues,whileDevOpsemphasizesdeliverypipelinesandflow.But,Agileisalsoconcernedwithautomation,andDevOpsisalsoconcernedwithcommunicationandculture.

1Andreessen,Marc."WhySoftwareIsEatingTheWorld."TheWallStreetJournal.August20,2011.https://www.wsj.com/articles/SB10001424053111903480904576512250915629460.2"2017StateofDevOpsReport."Puppet.https://puppet.com/resources/whitepaper/state-of-devops-report.3FRIEDMAN,THOMASL.THANKYOUFORBEINGLATE:anoptimistsguidetothrivingintheageofaccelerations.S.l.:PICADOR,2017.

DaveWestCEOScrum.org,JayneGrollCEODevOpsInstitute

TheConvergenceofScrumandDevOpsforanAgileITOrganization

September2017


ThinkingofAgileandDevOpsasdifferentthingsisamistake.

Both aspects are essential. Both communities have great ideas and abundant enthusiasm.Organizationsneedbothtosucceed;tothedegreethattheyseethemasseparatethings,orfocusononeattheexpenseoftheother,theyfail.

It is almost ironic for anyone to say that Agile and DevOps are opposed to each other or evenshouldn’tbethoughtoftogether.Themostpopularformtakenindeliveringsoftwarewithgreateragility is Scrum, some estimate over 18million software professionals 4practice Scrum every daymakingScrumandthereforeAgileakeycomponentofhowteamsdeliversoftwareandthereforeataminimumthe“Dev”inDevOps.

Bothmovementspursuethedesiretodelivervaluetocustomersinamoreeffectiveway,butfromdifferent starting points; Agile with the developer, and DevOps typically from operations. Theseapparentdifferencesareamplifiedbymisunderstandingsincluding:

• SomeAgiliststhinkALLprocessisbad,whileOpsissteepedinahistoryofstabilitythroughprocess.

• DevOpslookstotoolsandautomationtoincreasespeed,whilesomeAgilistsviewtoolsasanecessaryevilatbest,andadistractionatworst.

• DevOpslookstoholisticsystemsthinkingtosolveproblems,whileAgile lookstopeopletodrivechangeanddiscoveritthroughwork.

PoliticsandOrganizationalSilosWidentheGapLasting change requires strong leaders. They provide not only clarity and direction, but provideincentivesandpermission to change.Organizational changealsoattracts strongpersonalitieswhoget recognized forbeing a force for change, andwhoget rewardedwhen those changesproduceresults.Whentheirsuccessistiedtothesuccessofthatprogram,competingprogramsareathreat.WhenAgileandDevOpsinitiativesareledbydifferentpartsoftheorganization,competingpoliticalgoalsleadtoconfusion:

• Different tool strategies being adopted between the competing initiatives. How manytimeshaveyouheard,“theagileteamsuseJIRA,buttheopsteamsareusingServiceNow”?Those tools and the vendors selling them focus on a change initiative to drive purchases.This makes it harder and harder to integrate those groups of people as their data andprocessesarehiddenwithindifferenttools.

• Politics rather than value being used tomake decisions. The saying, “it is not what youknow,itiswhoyouknow,”isnotjusttrueinnationalcapitals,butinanyorganization,thathasgrownlargerthan20people.Politicsistherealityofmostorganizationsandthatmeansthattheassociatedinitiativesnotonlycomewithbaggageoftheworkbutalsothepoliticsofwhoisdrivingthem.

• Increaseddivisionandorganizationalconflict.Ironically,theDevOpsandAgilemovementscall for unification and collaboration betweendifferent groups but often,whenpracticed,leadtoevendeepergapswithtraditionalgroupsbecauseoftheirdifferentterminologyand

4https://www.infoq.com/news/2014/01/IDC-software-developers


ideas.That isalsoevident in theevent,publicationcommunitywithVERYdifferentshows,magazinesandblogsitesbeingvisitedbymembersofthesecommunities.

DevelopmentandOperationsHaveDifferentCulturesAgilistscanseemdogmatictoDevOpsprofessionals.“Oh,youareoneofthoseAgilepeople,”isaphraseoftenusedtodescribethegrowingresentmentthatdevelopersandotherITprofessionalsfeeltowardstheAgilecommunity.ThisresentmentisperhapsdriveninpartbythesuccessofAgilewhichhasledtolargenumbersofAgilecoaches,somewhoarefantastic,somegood,andlikewithanymassnumberofpeople,somenotsogood.

Also,agilityisoftenunderminedbytheorganizationitself,whichreducescredibilityandsuccess.

DevOps professionals can seem too process and tools focused to Agile proponents. The slogan,“don’tdoAgile,BEAgile,”isusedtodescribethepeople-centricfocusthatAgileencourages.Insteadof complex, detailed processes, Agile would encourage organizations to provide a lightweightframework,suchasScrum,andthenaddanyprocess theteamfeelsaddsvalue.Agileproponentsconsiderprocesstobe“emergent”inresponsetotheneedsofthesituation.Teamsareempoweredtomakedecisionsabouthowtheywork.Operationstraditionallytakesadifferenttactwithdetailedchecklists, process controls and tools. Change, after all, brings instability and needs to beappropriatelymanaged.

Language doesmatter, and teams need consistent language and concepts towork together. Thebetterteamsworktogether,thebettertheworkandvaluedelivered.Whencommunicationbreaksdown,collaborationsuffers,whichleadsto:

• Alienated stakeholders. Business partners and managers see the conflict and loseconfidencethatanyoneknowswhattheyaredoing.

• CultureclashbetweenDevandOps.The“touchyfeely”people-orientedAgilecommunityisverydifferentfromtheprocess-orientedIToperationsgroup.

• Increased fear and defensive behavior. No one wants more risk but they respond to itdifferently.Agileapproachesreducingriskbymakinglotsofsmallbutlowriskchanges,butOpsseeslotsofchangeasinherentlyriskyandrespondsbyincreasingprocess,controlandgovernance.

• Developers view DevOps as a stop-gap; they see the goal as “NoOps”. NoOps refers tocompleteautomationofOpswork,allowingdeveloperstoruntheproductionenvironment.Whetherthisispossibleordesirableisbesidethepoint;mostorganizationsaresofarfromeffectiveDevOpsthatNoOpsisavagueandunhelpfulgoal.

The reality is that delivering value to customers through software includes elements that requiredetailed,comprehensiveprocess,andotherelementsthatarefluidandrequiretheteamtoworkinadynamicmanner.Automationistheultimatestableprocess,butformanysituationsautomationisnot possible, or the cost outweighs the benefits. Balance between automation, process, andempoweredteamsisessential.Ifyoufocusonanyoneandignoretheothersitleadsto:


• Poorquality.Asystematicapproachtoquality iscrucialforthequalityofanyproduct,butformanyteams,qualitycontinuestobespottyatbestwithmanualtestingsurroundingtheircontinuousintegrationprocess.

• Nevergettinganything“reallydone”.Byhavingtoomanycomplexprocessesthatrequireexternalvalidationorverification,itisalmostimpossibleforateamtodeliverabacklogitemtoDone.

• Lackof transparencyandvisibility.Manyprocesses are so complex that the intent is lostanditisimpossibletomakebalance-baseddecisions.

• Whentheteamchanges,everythingchanges.Withoutaclear,definedprocessitisdifficulttomanagechangesinpeopleorhaveanychancetoscale.

• Work is hiddenbecause theprocess does not explicitly support it. As processes becomemoredetailedandcomplete,outlyingworkfallsthroughthecracks.Thiseitherleadstolotsof‘hidden’workand‘work-arounds’ortheworkismissed.

BringingTogetherScrumandDevOpsImagine a world where cross-functional, business-oriented teams deliver working software continuouslyandwherework flowsseamlesslybetweenall therightstakeholders in real time. Add to that where value isclearly understood, measured and reported on. Thisvisionistherealityformanysmallerstartupsthathaveblended business and technology with customer andmarkettoworkinaholisticwayofdeliveringcustomervalue. Scrum Teams are accountable for deliveringsoftware and operations teams are responsible forputting theenvironment inplace thatenables them todoitinasecure,safe,highqualityway.

Cross-FunctionalTeamsWithAlltheRightSkillsDeliver“Done”Software,FasterBuildingcross-functionalteamsisnothingnew.HirotakaTakeuchiandIkujiroNonakadescribedtheimportanceof flexible,cross-functional teams in“TheNewNewProductDeliveryGame” in1986.5But,makingtherightdecisionsaboutwhoshouldbeinoroutofateamisdifficult.Modernproductscompriseadazzlingarrayofdifferenttechnologiesthathistoricallyhaverequiredspecialistskillsandinfrastructuretosupport.And,adeliveryteammusthavealltheskillsnecessarytodeliveraworkingproduct.ThisisdescribedintheScrumGuide6as:

“Cross-functionalteamshaveallcompetenciesneededtoaccomplishtheworkwithoutdependingonothersnotpartoftheteam.”

5Nonaka,HirotakaTakeuchiIkujiro."TheNewNewProductDevelopmentGame."HarvardBusinessReview.August01,2014.https://hbr.org/1986/01/the-new-new-product-development-game.6TheScrumGuide™.http://www.scrumguides.org/.

Figure1.DevOpsCycle


Cross-functional teams need to have the right skills to get the work done. When a team istransitioningfromatraditionalrole-basedapproach,themembersneedtobroadentheirskills.Theyalsoneedtobuildempathyforthecustomertohelpthembuildbetterproducts.Thisdoesn’tmeanthat an individual can only be on a single team. There aremany instanceswhere someonewithoperationsexpertisecansitonmultipleteams(actingalmostlikea“service”totheteam),bringingtheir expertise and knowledge to the team(s), enabling better delivery while helping to educateother teammembers so that they canbroaden their skillsets.But, thathas tobalancedwithhowtheiravailabilityeffectstheteam’sabilitytodeliveryproductbacklogitems.Theyalsotypicallyneedto:

• Reducethenumberofhand-offs.Hand-offs increasewaittimeandreduceownershipandaccountability.Hand-offsmaybeunavoidablewhenteammemberslackalltheskillsortheauthoritytheyneedtodeliveracompletesolution,butiftheseaccountformostoftheworkbeingmanagedbytheteam,thenthosepeopleshouldbepartoftheteam.

• Developalltheskillstheyneedtodelivervalue.Whenteamsdon’thavealltheskillstheyneed, theywill need support from specialists.Over time, they should strive to learn fromthese specialists so that they increase their independence. For example, all applicationsneed security to be considered from the start. A team can be supported by the securitycommunityfromwhomtheycanlearn,reducingtheirdependenceandimprovingthequalityofthework.

• Increasetheautomationintheirprocesses.Automatingthemanymechanicaltasksteamsneedtoperformtodeliversoftwarefreesthemtospendmoretimeoncustomer-orientedvaluework.Examplesincludecontinuousintegration,testing,deployment,andprovisioningenvironments,tonameafew.

DevOpsandScrumSucceedWhenImpedimentsAreRemovedQueues break agility because they remove theability of the team to be in control of thesituation. When support organizations areconnected to Agile teams, via queues, it is verylikely that the team as a whole will be lesseffectiveastheywaitfortheiriteminthequeuetoreachthetop.

When building the future delivery organization,you should incrementally remove queues andreplace them with self-service capabilities.Traditional IT functions such as environmentprovisioning, database, security, network and

even deployment functions should be developed and supported as a series of self-servicecapabilities. These capabilitieswill lookmuch like the services from companies like AmazonWebServices(AWS),MicrosoftAzureandGoogle,andoftenwilltakeadvantageoftheseexternalcloudservices,addingtheorganization-specificintellectualpropertiestomakethemcompanycompliant.

Figure2.DeploymentCommunityExample


Legacy applications can also kill agility because, over time, these legacy systems have grown socomplexthatnooneunderstandsthem.Thiscomplexitymakesitveryhardforasingleteamtohaveall the skills necessary to deliver value. For example, the amount of work and skills required toproduce an end to end integration test makes it almost impossible to include in one Sprint!Unfortunately, there is no secret in solving this problemand instead requiresorganizations to re-architectthesesystemstoenablemoremodulardevelopment,deploymentandtesting.

Helpinggrowteamcapabilitiesmeans:

• Empowering teams to “do” what needs to be done to release the product. Instead ofcreatinglargeamountsofredtapetoprotecttheteamfromthemselves,empowerteamstomake decisions and deliver the product. But, ensure that the amount of change is smallenough that it can be easily backed out of, coupledwith environments and architecturalpracticesthatarerobustenoughtohandlechange.

• Reducingexternaldependenciesthroughself-serviceautomation.Ratherthanconnectingtheagile teamtocomplexprocesses,provideself-servicecapabilities thatallowtheScrumTeam to drive their own outcomes. Examples include provisioning virtual machines, orgettingaccesstotestdata.

• Supporting teamswith shared technical services, availablewithoutqueuing. The simplerthe software is, themore Agile the team can be in developing and supporting it. As thecomplexityandvalueof the software increases itbecomesharderandharder foranyoneteam to have all the right skills to support it. But, any dependency on external skills canbecomeabottleneck.By concentratingon supporting ScrumTeamswithexpertswhocancoach or mentor teams on a particular technology or approach, you both remove abottleneckandincreasetheskilloftheteam,makingthemmoreflexibleandAgile.

• Simplifyingandmodularizing legacyapplications. Looktorefactor the legacysystemsandsupporting infrastructure such as environments and tests to better support Agility. Thatmeans focuson reducing theoverheadof testing, providerbetter support for decoupling,andspreadlegacyknowledgethroughouttheteamsratherthanleavingitinonespecializedarea.

Automation,AutomationandMoreAutomationContinuous Delivery is one of the most important sets of DevOps practices. At its most maturepractice,thismeansthateverytimeadevelopercommitscode,itgetsbuilt,tested,anddeployed(ifitmeetsallreleasecriteria)withlittletonomanual intervention.Notonlydoesthelackofhumanbeingsmake for faster release processes, but it also increases quality by removing the chance ofhumanerror.

The first step to automation for a team is reviewing the process for waste and non-value addedwork. At the same time, they also review the application architecture. The result may be newbacklogitemsfocusedonrefactoringandtechnicaldebt.Somegoodtipsforautomationinclude:

• Simpleprocessesarebest.Removecomplexityandover-engineeredprocesses.• Start from thebackand the frontandwork toward themiddle.Unit testing and release

deploymentareasareperhapsthebestplacestostartprovidingnumerousopportunitiestocreatescripts.


• AutomationshouldbepartofthenaturalworkoftheScrumTeams.Itiseasytothinkthatthere should be a separate team building automation and creating standardizedinfrastructure. Experience shows that these centralized tools teams tend to build foreveryoneandservenoone.FocusoneachScrumTeambuildingtherightstufffortheirownuse.Theseteamsshouldworkwithoperationstoensurethatanythingtheybuildisusableinbothdeploymentandproduction.

SoftwareDeliveryProfessionalsAttheheartofanymoderndeliveryorganizationareskilledprofessionalsthatcanapplyanempiricalprocessandhave theengineering/operations skills toensure that thework theydo isof the rightquality.

Scrumbelievesthatprofessionalismissoimportant,thattheScrumGuideincludesthefivevaluesoffocus,openness,respect,commitmentandcourage.

These values can help an organization think about their delivery capability in a holistic manner,adding a different dimension to the delivery process. There are several tangible waysprofessionalismcanbeencouragedinamoderndeliveryorganization:

• Introduceanapprentice,journeyman,mastermodeltopersonneldevelopment.Basedonthemedievalmodelofknowledgetransfer,thisapproachtocareerdevelopmentcreatesacommunityoflearnersandteachersconsistentwithleanthinking,whereleadersgetoutoftheconferenceroomandtheofficetoworkwiththeteaminGemba,ortheplacevalueiscreated.

• Reward teams, not individuals. There are few things in most organizations that a loneindividual can achieve. Many different people must work together to deliver bettercustomeroutcomes. Individual incentivesaremisplaced,and individualrewards ignoretherealitythatnoindividualachievesverymuchpurelyontheirown.

• Rewardpeopleforcreatingvalue,notmerelykeepingbusy.Focusonimprovingcustomeroutcomes and removingwaste, not on keeping people as busy as possible.While labor isexpensive, no one benefits when busy people deliver the wrong solution. And keepingcriticalpeoplewithscarceskillsasbusyaspossibleoftensimplymeansthatmanyotherswillendupwaiting.

• Makevaluesasimportantastheoutcome.Howmanytimeshaveyouheardsomeonesay,“Well, he delivered, but it was a blood bath”? That heroic approach to product deliveryworks well occasionally, but is unpredictable and ultimately destroys the organization byburning out people and creating large amounts of technical debt. By encouragingprofessionals to live the Scrum Values7 of focus, openness, respect, commitment andcourage,youcreateanenvironmentthatnotonlysupportsagility,butisaplaceyouwouldliketowork.Ifthesevaluesaresharedbydevelopment,operationsandthebusinessteams,

7AgreatoverviewoftheScrumValuescanbefoundhere:"There’svalueintheScrumValues."Ullizee.May03,2013.https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/.


trust isnatural.Ultimately,byfocusingonsharedvaluesacrosstheorganization,youbuildqualityproducts,notjustintermsofdefects,butintermsofcustomervalues.

Integrate,Focus,andWinFormany, thebarriers to becoming an integrated, collaborative, cross-functional product deliveryand support organization is almost insurmountable: the status quo seems immovable, legacyapplicationsseemunchangeable,andthecultureseemsunshakeable.Someorganizations’attemptsto change result in littlemore than giving new names to old processes, roles, and organizationalstructures.

Butapragmaticstep-by-stepapproachtobothAgileandDevOpscanprovideaclearpathforwardwhiledeliveringbenefitsalongtheway.Notallpartsofthebusinessrequiretheimprovedagilityandflow affordedby Scrum+DevOps. Thus, incrementally take those parts of the business thatwouldbenefitandchangethem.

Changinganorganizationsoundslikeadauntingtask,anditwouldbeifonehadtochangeanentireorganization,allatonce.

Changestartswithacustomerwhocouldbebetterserved,andaproductdeliveryorganizationthatwantstomakethemmoresatisfied.

Step1:IntegrateYourApproachtoDeliveringSoftwareThissoundssimple,butmanyorganizationsfindtheirapproachisfragmentedintospecialistgroupswhoarealignedaroundreducingcostandrisk,insteadofalignedarounddeliveringcustomervalue.Work flows from a planning function into development, test, release and then maintenance.Developmentteamsandsupportteamsareseparatedandprojectswillevenputdifferentgroupsofpeopleworkingonthesamesystemsandbusinessareas.

Thus, the first stepencourages theorganization to stop thismadnessby takingaholisticproduct-centricapproachtodeliveringbusinessvalue.Projectsmaystillexistbutaresecondarytopersistentteams – that includes operations – that add new business value while supporting maintenanceneeds. Largeproductsdeliveredby teamsof teamswoulduse theNexus™ framework8 for scalingScrumtoorganizetheScrumTeams,whilesmallproductswouldbedeliveredusingScrum.

WhatthismeansforScrumTeamsis:

• Buildingteamsthatarealignedtoproductsandthecustomer.Byaligningtoaproductorcustomers,thatmeansthattheProductBacklogwillincludenewandmaintenancerequests.If the product is large, these teams will be organized around a Nexus which facilitatesmultipleteamsworkingonthesameProductBacklog.

8"ScalingScrumwithNexus™."Scrum.org.https://www.scrum.org/resources/scaling-scrum.


• IncludingtherightpeopletodeliverDonesoftware.AndwhenwesayDonesoftwarethatmeansintoproductionandsupported.Bycreatinga“complete”DefinitionofDone9forthesoftware,thatmeansalltherightpeopleneedtobeinvolved.Operations,security,dataandothergroupswilleitherbeincludedintheteamsortheywillempowertheScrumTeamstoundertakethetasks thatwould traditionallybe theirs.This requires theseorganizations tochangefromdoingtheworkinasilotodoingitaspartoftheteamwhilehelpingothersdotheworkandthenensuringthattheworkisright.

• Taking responsibility for the complete value chain, not just the development bit. AfundamentalchangeformostScrumTeamswhostillliveina‘Water-Scrum-Fall’world,tobeeffectiveanddeliverrealbusinessvalue,theymustbeclearlyresponsiblefortheend-to-endprocess of delivering value as a team, breaking down the silos of ownership andindividualism.

WhatthismeansforOperationsis:

• Restructuringtheportfolioaroundproducts/customers.Thefirststepisapproachingworkon items in the context of thebusiness, and restructuring aroundbusiness outcomes andproducts,notaroundprocessesorspecialistskills.

• Removing queues from the system. When a Scrum Team is not able to do the workthemselves, don’tmake themwait for someoneelse to get help;make thehelp availablewhenever theScrumTeamsneed it. Provide self-service capabilitieswhereverpossible,orstaff the “expert” positions with enough people that there are enough of them to helpteamswhenevertheyneedit.Eitherway,astrongfocusonremovingimpedimentstoflowiscrucial.

• Provide Operations Services to the Scrum Teams. Having separate development andoperationsteamsmaybeinevitable,buthaveteammembersavailabletobeaservicetotheScrumTeam.TakepartintheDailyScrum,beassignedtoasetofScrumTeams,understandwhat is intheProductBacklogandSprintBacklog.Beembeddedwiththeteamsyouareapartofsothatyoucanhelpthemprioritizeasmuchasyouprioritizeyourself.

• Automate,automate,andautomate.FormanyoperationsteamstheonlywaytotrusttheScrum Team is to either be part of the team or automate the work so mistakes don’thappen. To this end, automation plays a vital part in ensuring that a holistic approach todeliveryispractical.

Step2:AddFeedbackLoopsOnce the teams are better integrated and the work is flowing, with regular product-basedretrospectivesandimprovements,thenextstepistofocusoninstrumentingtheprocessestogainbetter insight into both releasing and supporting software, and the business that the softwaresupports.Addingoperationaland lean/businessanalytics to theprocessprovidesa foundation fortheProductOwnertomaketherightdecisionsabouttheirproduct.Italsoequipsthedevelopment+operationsteamtogainbetterinsightstotheirworkingpractices,allowingforimprovements.

WhatthismeansforScrumTeamsis:

9"Definitionof"Done"."TheScrumGuide™.http://scrumguides.org/scrum-guide.html#artifact-transparency-done.


• ReleasingsoftwaremorefrequentlyduringSprints.TheSprintReviewisNOTaphasegate;software canbe releasedas fast as required toproduction, andmany times throughoutaSprint. Improvedfeedback isnot justabout instrumentationandcapturingmoredata, it isalso about capturing data more frequently. If the team or Nexus is delivering softwarefrequently, then the Sprint Review is far more interesting than ‘potentially shippable’,allowingthereviewtobeonsoftwarethatisalreadyinproduction.

• BuildingsuccessmeasuresintoProductBacklogItems.BylookingatProductBacklogItemsin terms of how success could be measured not only ensures that when the teamimplementstheitemtheywillhavesomeinstrumentationinplace,butitalsovalidatestheitemitself.Empiricalprocesscallsforinspectionandadaptationbasedontransparency.Thisrequiresthateachoutcomebemeasurabletoallowforsuchinspectionandadaptation.

• MakingSprintReviewsmorevisibleandtransparenttothebusiness.Dataisonlyvaluablewhentheteamsareusingittobuildunderstandingandallowingdecisionstobemade.Itisimportant for the Scrum Team to radiate information to the stakeholders who can helpthemmake the rightdecisions. TheSprintReview is a regular, formalmeeting thatallowstheScrumTeamandother interestedparties (e.g.,Stakeholders) to inspect the Increment(the work they have done that Sprint which could be a single release,many releases, ormaybe just releasable but not into production). By addingmetrics to the review, you canfocusthereviewonthethingsthatmatter.

• Instrumentsoftwaretogainbetterunderstanding.Underpinningthewholeprocess istheneed to add instrumentation to both the process of delivering software and the actualsoftwareitself.

WhatthismeansforOperationsis:

• Putting inplaceenvironmental support for instrumentationandanalytics.Environmentalandapplicationanalyticsrequireafoundationoftechnologytosupportboththecapturingof information and also the storage and analysis of that data. By providing theseenvironmentsandtheskillsnecessarytounderstandthedata,operationsprovideavaluablefunctionfortheScrumTeams.

• Buildingshareddashboardsthatshowsuccessindeliveringcustomeroutcomes.Toooften,operations and development groups are using different dashboards to report progress,success or failure. By putting in place a dashboard that is consistent for both groups youbuildacommunicationenvironmentthatallowseffectivecollaboration.

• BeingpartoftheScrumTeam(s),DailyScrum,SprintReviewandSprintRetrospective.Thissounds very simple, butwithout focus onworkingwith the ScrumTeam(s), too often theoperationsprofessionalsareleftoutofthereviewprocess.Scrumisanempiricalapproach;this requires constant testing of ideas through transparency, but tests are fundamentallyflawedwhentherightstakeholdersarenotintheroom.BymakingoperationsprofessionalsapartoftheteamandinvolvingtheminthevariousScrumEvents,insightscanbegathered,allowingthefutureworkinthebacklogtoberefinedandplanschanged.

• EnsuringSprintRetrospectiveissuesaretakenintoanyDevOpsinitiatives.Therearemanyplaces that inspection and adaption happens within the Scrum framework. The SprintRetrospective is a key event for inspecting how the team is working. Out of this


retrospectivecomesopportunitiesforimprovement.Manyofthoseimprovementareasarerelated to the processes of release management, security and operations. It is thereforeimportant that theoperations teamsareapartofongoingSprintRetrospectivesand takethemonboardaspartoftheimprovementwork.

Step3:GrowaCultureofContinualExperimentationandLearning

TheultimateendgoalistonolongerhaveaseparateoperationsandScrumTeam,butinsteadhaveScrumTeamsandacommunitythatsupportsthem.

Thismightsoundlikesemantics,butthismodelimpliesthatworkisonlydoneintheScrumTeams,and community is, as the name implies, a collection of skilled professionals that can work with,support and mentor the Scrum Teams to deliver great software. Each Scrum Team has a directconnectionwiththecustomerand,asdirectedbytheProductOwner,continuouslydeliversvaluablesoftware.Theworkoftheteamisbasedonclearlymeasurableoutcomeswitheach“experiment”orSprintworking toward learning. Supporting theseScrumTeams is infrastructureanda communitythatislightlycoupledtotheworkviaself-servicecapabilities,teammembersandmentorswhohelptheteamdeliverworkandimprove.Todothis,teamsneedto:

• Put in place evidence-based measures to enable teams to improve. Evidence BasedManagement (EBMgt™)10 provides an approach that looks to three groups of value-basedmeasures in areas of current value, ability to innovate and time to market. Viewingimprovement in these three dimensions helps teams focus on where they most need toimprove.

• EmpowertheProductOwnertoimplementchangesandmakeproductdecisions.Noneedfor complex reportingand sign-off committees. TheProductOwner is accountable fornotjust the development of the product, but also its production usage. That accountabilitymeansthatoperationalactivitiesarepartoftheirmandateandneedtobeconsideredinthecontextof their role.TotalCostofOwnership/Operation isno longeranabstractmeasurethat is included in a dashboard somewhere, but the reality of every decision the ProductOwnerismaking.

• Include “experimental” backlog items.Not everythingwill be an experiment; thebacklogwill includework that is drivenbya clear future lookinghypothesis,work thathas clearlydefined value, bug fixes and the resolutionof technical debt. Eachbacklog itemwill driveworkwithintheScrumTeamandtheirsupportsharedservice/communitygroups.Thisworkshouldbebalanced, allowing teams tobuild for today and the future,while also allowingthemtodealwiththepast.

• Createasharedincentivemodelthatalignsteammembersandstakeholders.Dissolvethedistinction between development, operations, and “the business” by introducing a singleincentivemodelforeveryonethatrewardsdeliveringcustomervalue.

10"EvidenceBasedManagement(EBMgt™)."Scrum.org.https://www.scrum.org/resources/evidence-based-management.


SummaryDevOps was born from the pain generated by Agile teams and was initially termed “AgileInfrastructure”. The intent was to better support Agile teams with more flexible approaches toinfrastructure. That intent has become part of a broader movement that is focused, not just oninfrastructure,butdrivingarevolutionthroughouttheITprofession.But,itisimportantthatDevOpsdoes not forget its roots. Supporting customer-centric Scrum/Agile teams is still fundamental forsuccess. And that means radical changes to how change is managed, services are provided andteamsareorganized.TherecontinuestobeaneedfortheDevOpsmovementandScrumTeamstoworktogethertodeliverDONEsoftware,andsupporteachotherintheirconstantneedtoimprovebyinspectionandadaptationthroughtransparency.

OrganizationalModelsThere is no one-size-fits-all model for how operations professionals connect to Scrum Teams. Insome situations, operations will be embedded within the teams. In other situations, operationsprofessionalswillbeasharedpersonorpeoplethatworkwithandmentormultipleteamsintheirwork. For more complex products that are using a Nexus approach to organize teams of teams,operationsmayhaverepresentationwithintheNexusIntegrationTeam(NIT),aswellasbeingpartof the individual Scrum Teams.What is true is that each organization will have multiple modelsrunning because their products/customer situations will require different support needs. And,organizations that think that optimizing the efficiency of operations is more important thandeliveringvaluewillneverbecomeAgile.Whenconsideringhowoperationsisoriented,considerthefollowing:

• Doestheamountofcomplexityandtheunknownmakeanysharedmodel impossibletooperate?Inthecaseofsituationswheretherearemanyunknownsaroundtheoperationalnatureofthesolution,puttingoperationsoutsidetheScrumTeamisafalseeconomyasthecostofwaitingforsupport,ortheoverheadofcommunications,willreducetheagilityoftheteam.

• Doesitmakesenseforthesespecialistskillstobelearnedbymorepeople?Agilityrequiresgeneralists and by supporting the transfer of skills to Scrum Team members, operationsbecomes less of a bottleneck and more a part of the team. It also ensures long termflexibilityasmorepeoplehavemoreskills.

• Isitimportantforlegalreasonstohaveaseparationofownership?Thismightnotrequirea separate department, but increased transparency might be people outside of a ScrumTeamhaveaviewofthework.IntheOpenSourcecommunity,asimilarneedhasresultedinautomatedcodereviewtoolsandmobprogrammingmodels.Thiscouldapplytootherlegaltransparencyrequirements.

AccountabilityandResponsibilityTraditional approaches to development and operations have created different areas ofaccountability and responsibility. The DevOpsmovement has focused on removing/changing this.However, without shared measures, objectives and a clear connection to the customer, it isimpossible for this to be successful. It is therefore important to align teams and teams of teamsaroundthecustomerandtheoutcomestheyseek.Thecontaineroftheseoutcomesistheproduct


which might map across several applications and systems. To be successful with this change inorientation,organizationsneedtohave:

• One shared Product Backlog. Today most organizations have several backlogs with eachteam having their own work lists and priorities. To create shared accountability andresponsibility, it is fundamental tohaveONEshared,visible,ProductBacklog.Thisbacklogshould bemanaged by one Product Ownerwho is accountable for ensuring that value isdelivered.Theylikelywillnotdoallthework,buttheyareaccountableforensuringthatitgetsDoneandisprioritizedinamannerthatdeliversthemostvalueintheend.

• Asingle,outcome-baseddashboardthateveryoneworkstoward.Ifyouwanteveryonetowalktothesamedrumbeat,itisimportantthateveryoneknowswhatthatdrumbeatis.Bybuilding a shared dashboard, Scrum Teams and operations will work to the sametransparentmeasures.

• AProductOwnerwhoisaccountableforwhatisdeliveredtocustomers.ItistooeasyforProductOwnershiptobefocusedondeliveringnewstuff,butonlylightlyresponsiblefortheoperational systems,costandquality.DevOpsneeds tobe inclusiveof theProductOwnerandmakethempartofthesolution.

Self-OrganizingandEmpowermentHealthy,high-performingteamsdecidehowtheyareorganized,howtheywork,andwhattoolsandprocessestheyuse.Todothis,theyneedtobeheldaccountableforthevalueandqualityofresultsthey deliver, not micro-managed on how to get those results. No one approach works in allsituations.Thepeopledoingthework,however,aretheonesbestabletodecidehowtodoit.Onesizedoesnot fitall,andakey learning fromtheAgilecommunity is:byprescribinga fixed“Agile”process foreverysituation,youendupwiththeoppositeofagility. Instead, focusonanempiricalapproach that starts from idea and finisheswith customers. Thatmeans, clear alignment aroundcustomersforthewholevaluestream.

the convergence of scrum and devops for an agile it ... · pdf filea minimum the...

Documents