WIXLIB

Giving Back to the CommunitySparkle Corp Dev and Ops AffinitySummary16016116110. Affinity: Misconceptions and Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Affinity MisconceptionsOps Engineers Aren’t as Valuable to the Organization as Developers AreSharing Too Much Outside the Company Might Weaken Our CompetitivePositionAffinity TroubleshootingOne or More Individuals Are Interrupting Group Flow DynamicsOne Team Keeps Blocking Other TeamsSome Teams Are Feeling UndervaluedPeople Don’t Seem to Trust Each OtherPeople Are Concerned Solely About Technical Aspects of Work, NotInterpersonal OnesDifferent Teams Seem Like They Won’t Ever Be Able to ReallyWork TogetherPast Interpersonal Conflicts Are Causing Present Interteam ConflictsTeam X Seems to Want to Be Their Own SiloPeople Are Blaming Mistakes on DevopsPart IV.163163164165165166167168169170171172173Tools11. Tools: Ecosystem Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Software DevelopmentLocal Development EnvironmentVersion ControlArtifact ManagementAutomationServer InstallationInfrastructure AutomationSystem ProvisioningTest and Build olution of the EcosystemSummaryx Table of 191192

12. Tools: Accelerators of Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193The Value of Tools to PeopleWhat Are Tools?The Right Tools for Real ProblemsEmbracing Open SourceStandardization of ToolsConsistent Processes for Tool AnalysisExceptions to StandardizationIrrelevance of ToolsFailures of Process, Not ToolsConway’s Law for Tool SelectionThe Impacts of Tools on CultureTools Impacting CommunicationTools Impacting Broader BehaviorsSelection of ToolsProduct DevelopmentCommunity HealthIn-House CustomizationExample: Comparison of Version ControlExample: Manual Infrastructure Configuration over AutomationAuditing Your Tool EcosystemElimination of ToolsImprovements: Planning and Measuring ChangeCase StudiesExamining DramaFeverImpact of Existing TechnologyContinuous Impact of Emerging TechnologiesAffinity Empowering Adoption of PracticesTool Selection at DramaFeverExamining EtsyExplicit Versus Implicit CultureA Culture of CompassionA Culture of BlamelessnessBeing Remote-FriendlyTools Enforcing PracticeBuy or BuildConsidering AutomationMeasuring SuccessMotivations and Decision-Making ChallengesSparkle Corp Effective Tool UsageSummaryTable of 6218219219220222223224225226 xi

13. Tools: Misconceptions and Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Tools MisconceptionsWe Use Technology X, but Everyone Else Is Using Technology Y; We MustChange to Technology Y as Soon as PossibleUsing Technology X Means We’re Doing DevopsWe Have to Make Sure We Don’t Choose the Wrong ToolYou Can Buy Devops-in-a-Box or Devops-as-a-ServiceTools TroubleshootingWe’re Trying to Find the Best Practices for Technology XWe Can’t Get People to Agree on One Particular ToolWe’ve Decided to Adopt (or Retire) Technology X, but People AreResisting Using It (or Giving It Up)Part V.229229230230231232232233234Scaling14. Scaling: Inflection Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Understanding ScalingConsidering Enterprise DevopsGrowing or Shrinking the Organization Strategically with DevopsConsiderations of Deliberate ScalingPlanning for ScalingOrganizational StructureLocalityTeam FlexibilityOrganizational LifecycleElimination of Vampire and Zombie ProjectsThe Impact of Release CyclesComplexity and ChangeScaling for TeamsGrowing Your Teams: Hiring as ScalingRetentionCase Studies: Growing and Scaling TeamsGrowing and Building Operations TeamsProblems with “Hero Culture”Job Postings and Recruitment IssuesDeveloping Individuals and TeamsDeveloping and Growing Team MembersTeam Scaling and Growth StrategiesKeeping Teams Small and FlexibleFostering CollaborationManaging Conflictxii Table of 250259260261263266266268268270275

Scaling for OrganizationsCentralized Versus Ad Hoc TeamsBuild Out LeadershipCase Study: Government Digital Service, GOV.UKExplicit CulturePlanningChallengesBuilding AffinityCase Study: TargetExamining TargetStarting with Desired OutcomesAffinity Within the EnterpriseTools and Technology Within the EnterpriseSharing Knowledge Within the 28929029229315. Scaling: Misconceptions and Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Scaling MisconceptionsSome of Our Teams Will Never Be Able to Work TogetherWe Need Total Executive Buy-In to Start Making ChangesWe Don’t Have the Budget to Do Any Hiring Right Now So We Can’t StartDoing DevopsScaling TroubleshootingManagement Is Insistent That We Stick With X, and Doesn’t See the Valueof DevopsTeams Are Spread Too ThinDecisions Aren’t Being Made WellWe’re Having Problems Attracting the Talent We WantMorale Is Suffering After a Reorganization or Staff ReductionWe Don’t Know If We Need a Full Team for XPart VI.295295297297298298299300301302303Bridging Devops Cultures16. Building Bridges with the Four Pillars of Effective Devops. . . . . . . . . . . . . . . . . . . . . . 307The Significance of StoriesExplicit and Implicit StoriesDevops in Theory and in PracticeReal-World Case Studies: Stories Showing PracticeLearning from StoriesBuilding Connections with StoriesSummary308308310310311312312Table of Contents xiii

17. Bridging Devops Cultures: Learning from Our Stories. . . . . . . . . . . . . . . . . . . . . . . . . . 315What Stories Can Teach Us About CultureValuesProhibitionsMythsRitualsIdeas and KnowledgeInterorganizational InteractionsConferences and TravelOther Community EventsEngineering ExchangesEncouraging Interorganizational AffinityDiscouraging Fixed MindsetsStart with Small 33233318. Bridging Devops Cultures: Fostering Human Connections. . . . . . . . . . . . . . . . . . . . . . 335Individual Stories and Narratives around WorkTaylorism and the Value of Individual StoriesCelebrating IndividualsGoing RemoteLeaving a CompanyCultural DebtThe Health of SystemsExamining Sick SystemsCreating Healthy SystemsOrganizational and Individual HealthIdentifying Healthy and Unhealthy 119. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Your Next StepsCreating Effective Devops35435520. Further Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363xiv Table of Contents

Foreword by John AllspawThere is a sea change happening in software development and operations, and it isnot simply the introduction of a new word into our lexicon—it’s much more thanthat. It is a fundamental shift of perspective in the design, construction, and operationof software in a world where almost every successful organization recognizes thatsoftware is not something you simply build and launch—it is something you operate.What makes this shift unique is that it’s more encompassing, more holistic, and morereflective of the reality that engineering teams face on a daily basis. Long gone are thedays that manufacturing and assembly-line metaphors could be used in softwaredevelopment and operations. Long gone are the days that products are things that aredesigned, planned, and then finally launched. There is no “finally” anymore. There isonly an endless cycle of adaptation, change, and learning.What Ryn and Jennifer have laid out in this volume is a myriad of threads to pull onas engineers in teams and organizations cope with the complexity that comes withtrying to make their work “simple.”Ryn and Jennifer do not paint a picture of one-size-fits-all or deterministic solution‐ism. Instead, they describe a landscape of topic areas, practices, and observations ofteams and organizations that understand the idea that at the heart of good products,good user experiences, and good software is the elegantly messy world of humancooperation, thoughtful critique, effective collaboration, and judgment.In 2009, my friend Paul Hammond and I gave a presentation at O’Reilly’s VelocityConference entitled “10 Deploys a Day: Dev and Ops Cooperation at Flickr.” Whilesome of the material was about perspectives on continuous deployment, many choseto focus on the “10 Deploys” part rather than the “Cooperation” part. I believe it is amistake to think that the technology or “hard parts” can be seen as somehow distinctor separate from the social and cultural “soft parts”—they cannot. They are inextrica‐bly linked and equally critical to success. In other words, people and process influ‐ence tools and software in more ways than most are willing to admit or even know.xv

My strong advice to readers: do not make the mistake of thinking that technology isnot about people and process, first and foremost. Your competition will eat you alivethe second you start thinking this.These topics of concern are not found in typical computer science curriculums, norare they found in typical professional leadership and development courses. Thesetopics are born out of the pragmatic maturity that only hard-won work in the fieldcan produce.Ryn and Jennifer have given you an in-depth set of signposts in this book. My genu‐ine request to you, dear reader, is to use these signposts to think with, in your owncontext and environment.— John AllspawChief Technology Officer, EtsyBrooklyn, NYxvi Foreword by John Allspaw

Foreword by Nicole ForsgrenIn 2003, Nicholas Carr declared to the world that IT didn’t matter—and because hesaid it in Harvard Business Review, organizations (and the executives that run them)believed him. Well, times have changed, and so has IT. Since 2009, the most innova‐tive teams and organizations have shown that technology can play a key role in deliv‐ering real value and competitive advantage. This technology revolution is known asDevOps, and this book can show you how to join those innovative companies todeliver value with technology as well.Here, Jennifer and Ryn draw on their experiences at innovative companies as well astheir backgrounds as prominent experts in the community to highlight what it reallytakes to do DevOps—or as they call it, devops—effectively. This vantage point bringsunique insights that can be applicable and useful to any reader, because they combineknowledge from several companies and across industries. This gives readers some‐thing to take away regardless of where you are in your journey, no matter how big (orsmall) your organization is.The tales and advice found in Effective DevOps parallel those I’ve seen in my ownwork for the past decade. As a leading researcher in the field and the lead investigatoron the State of DevOps Reports, I know that a strong organizational culture that pri‐oritizes information flow and trust is a key component of any DevOps transforma‐tion, and the factor that sets the DevOps movement apart from traditional IT. DataI’ve collected from over 20,000 DevOps professionals also shows that this culturedrives IT and organizational performance, helping the best IT organizations seedouble productivity, profitability, and market share when compared to their peers. It’sno mistake that Jennifer and Ryn start the book with a discussion on aspects of cul‐ture, communication, and trust, and devote a good portion of their time addressingthe importance of these factors to any transformative work. As technologists, we loveto start with the tools and maybe even the processes, but time and again, the datashows that culture is essential for tooling and technology success in addition to theaforementioned IT and organizational performance. Parts II–III on collaboration andaffinity, respectively, are must-reads here, whether you are just starting your DevOpsxvii

transformation and want to know what to implement and watch for, or you are takingyour existing DevOps practice to the next level and looking for ways to optimize andtroubleshoot.As a consultant to some of the most innovative companies, I’ve found that the mostchallenging part of implementing DevOps and planning a technology transformationroadmap is helping teams and organizations understand that there isn’t just one rightanswer—it always depends on what is right for your team and your organization. Ilove that Ryn and Jennifer embrace the ambiguity so well in this book, knowing thatthere is no way to “plug and play” a single solution, and lay out the tools and piecesyou need to construct your own DevOps solution and journey successfully. In addi‐tion to Parts II–III, be sure to check out Part IV on tools, which are essential to anyDevOps transformation. I especially love how they’re framed as not only technology,but also key components of the culture in which they perform.My favorite aspect of this book is how accessible it is to so many different audiences.Part V on scalability is particularly relevant for individual contributors and teamleaders, and I’ll be using it as a reference both personally and for my clients. Chap‐ter 4 on terminology and Chapter 11 on ecosystem overview come in handy both fortechnologists (to make sure we’re all on the same page, as different tribes often usedifferent words) and for executives who could use a current reference. The wholebook is a welcome and much-needed introduction to the field for university studentswho just don’t get this training in their studies, and I wish I’d had it when I wasa professor.We live and work in exciting times, and the integration of technology into our corebusinesses has made every firm a software firm. Technology now provides opportuni‐ties to deliver features to customers in new ways and at speeds not possible before.Organizations often find themselves struggling to keep up. Old IT and waterfallmethods just don’t allow organizations to deliver value fast enough—I’ve seen it inthe data, and I’ve seen it among the customers and companies I work with to createsolutions for their own DevOps journeys. Jennifer and Ryn have also seen the chal‐lenges to technology transformation in the old way, and the exciting opportunitiesthat are possible with DevOps, and they’ve responded by writing this book to guideus all through our own journeys. So read through, and choose your own adventure!Iterate, learn, grow, and choose your own adventure again!— Nicole Forsgren, PhDDirector, Chef SoftwareSeattle, WAxviii Foreword by Nicole Forsgren

PrefaceImagine this scenario: a small web company is starting to run into problems—itswebsite is straining and experiencing regular failures under unprecedented growth.Employees are increasingly unhappy with the number of hours required to maintainservices while also trying to implement and deploy new features. Language and timezone barriers are contributing to friction between globally distributed teams. A cul‐ture of blame has grown around the tense reactions during site outages, resulting inincreased suspicion and decreased transparency between teams.Given these problems, the organization decides that devops sounds like a good solu‐tion. Management hires several new people to join their new devops team. Thedevops team has on-call responsibilities, where the existing operations team can callthem to escalate issues that they don’t know how to address. The devops team mem‐bers have more industry experience than the people on the ops team, so they are gen‐erally better equipped to handle production issues. Without the time or opportunityto learn new skills, however, the operations staff keeps escalating the same issues overand over again.The devops team gets tired of acting as go-between for both the developmentand operations teams. Rather than defusing the culture of blame, management’s “sol‐ution” has produced twice as much miscommunication, because none of the teamsare privy to the planning processes, emails, chat messages, or even bug trackers of theother teams.Thus, management declares “this devops thing” is a failure and is unwilling to investany more time, effort, or money into either the ops or devops teams, viewing them asincompetent people who keep “taking down the site” and “getting in the way” of the“real” development work being done. The members of these two teams who are ableto find better jobs leave for organizations where yelling and blame aren’t acceptableworkplace practices, making the remaining team even less effective.xix

Introducing Effective DevopsWhere did things go wrong here? Devops sounded like a good idea, but creating adevops team led to less desirable outcomes. What could this organization have donedifferently to see meaningful improvements to their situations and actual solutions totheir problems? Throughout this book, we will show you what it looks like to makeeffective changes with a devops mindset.This book is not a prescription for the One True Way of doing devops. We don’t offeryou devops in a box, devops-as-a-service, or tell you that you are Doing DevopsWrong. This book offers a collection of ideas and approaches for improving individ‐ual collaboration, team and organizational affinity, and tool usage throughout a com‐pany or organization, and explains how these concepts allow organizations to changeand adapt as necessary. Every organization is unique, and so while there is no onesize-fits-all way of doing devops, these common themes can be applied in differentways to every organization that wants to improve both the quality of their softwareand the efficiency and well-being of their employees.Efficiency is doing the thing right. Effectiveness is doing the right thing.—Peter F. DruckerEffectiveness is defined as doing the right things and achieving the desired results. Todo the right things, we must understand o

and author of Building a DevOps Culture (O’Reilly) “Everyone knows culture is important in the context of devops, but we’ve lacked a book-length reference into this vital topic. Effective DevOps is a broad, deep inquiry into human factors that should be studied by every manager w