DevOps Handbook Series Part 2: Begin The DevOps Methodology

Missed out on The DevOps Handbook Series so far? Catch up with the previous installments below first:

• Introduction Summary
• Part 1: Establishing the Three Ways
• Part 1: The Three Ways Continued

If you’re all up-to-date with the previous summaries, let’s dive into today’s installment.

Where to Begin with the DevOps Methodology

Part 2 considers where to begin with implementing DevOps within your organization. The Handbook aims to answer the following questions in this section that will undoubtedly arise for any organization considering the DevOps methodology:

• Where do we begin?
• How do we identify and select the best value stream to transform?
• Who should we involve?
• Finally, how do we organize our teams? While at the same time protecting their capacity for work and optimizing their chances of success.

Choosing a Value Stream

This part of the DevOps adoption process deserves careful attention. Choose specific areas with which to begin the initial DevOps transformation, rather than attempting a top-down big bang overhaul. Selecting the ideal value stream to involve is key to ensuring primary successes and laying the foundation for expansion from there.

As Michael Rembetsy, Ex-Director of Operations at Etsy, advises,

“When we’re in trouble, we don’t get very many shots. Therefore, we must carefully pick and then protect those improvement projects that will most improve the state of our organization.”

In addition, the selection process will identify the “who” involvement in the DevOps transformation process.

Examine the following factors in your evaluation of candidate value streams:

• “Greenfield Vs. Brownfield Services.” Terms levied from the urban planning sector, greenfield development are brand new software services/products. Brownfield projects are existing services/products which have served customers for years. Greenfield projects can be easier, as the operations begin from scratch, but DevOps has proven successful for several brownfield transformation projects already. Even despite the technical debt these tend to come with.
• “Consider Both Systems of Record and Systems of Engagement.” Systems of record are ERP-like processes that drive organizations (such as financial reporting and HR), while systems of engagement are processes that interact with employees or even customers (e.g., e-commerce, etc.). The former are slow to change and must be done right, while the latter are focused on changing fast to meet feedback requirements. DevOps aims to optimize both speed and reliability to encourage the whole organization to achieve goals.
• “Start with the Most Sympathetic and Innovative Groups.” In every business, there are those individuals more receptive to change and innovation. Identify teams who will welcome the opportunity to innovate and improve within a DevOps transformation.
• “Expanding DevOps across Our Organization.” Communicate DevOps adoption successes across the business to enable the scope expansion to other value streams. Begin the transformation with the innovators before increasing to more visible and influential groups. Finally, tackle the holdouts when you have substantial support—and successes—to protect the move.

Study the Work Flow in the Value Stream to Improve and Make It Visible

The next step in DevOps adoption for an organization is to understand where and how value is delivered to the end-user/customer. To achieve this, it is important to understand:

1. Who performs the necessary work in the value stream
2. How it happens
3. Where you can make improvements

The Handbook breaks down this journey into the following tasks:

• “Identifying the Teams Supporting Our Value Stream.” The nature of complex values streams is such that work within a technology value stream involves many different people and teams. Identify all of these in your candidate value stream for DevOps transformation.
• “Create a Value Stream Map to See the Work.” This step does not involve documenting and recording every minute detail the value stream includes. Instead, mapping the value stream endeavors to highlight areas that threaten fast flow, short lead times, and dependable outcomes for customers. In the figure below:
  • % C/ A represents the percentage of complete and accurate work
  • LT depicts Lead Time calculations
  • VA indicates the Value Added time

Example: Value Stream Map

The DevOps Handbook (1st ed. 2016) Kim et al.

• “Creating a Dedicated Transformation Team.” To overcome the challenge of implementing DevOps and continuing normal business operations, create a team who operate outside of the rest of the business. Moreover, free the selected transformation team from the organization regulations. These may limit their functions to inhibit disruptions and enable experimentation.
• “Agree on a Shared Goal.” Clearly outline a fixed deadline for the initiative. Ensure that it is achievable, but that the goal is measurable and leverages a certain level of motivation. Broadcast successes as progress occurs to the rest of the organization. Then set new targets for the next step of the process.
• “Keep Our Improvement Planning Horizons Short.” The initiative should aim for short stints of measurable improvements/actionable data in weeks, rather than months, perhaps in sprints of 2 or 4 weeks at a time.
• “Reserve 20% of Cycles for Non-Functional Requirements and Reducing Technical Debt.” Manage current levels of technical debt by investing 20% of each Development and Operations cycle to pay down the problem. The 20% dedication can alleviate levels of burnout, help create countermeasures to problems, and reduce constraints on feature deliveries.
• “Increase the Visibility of Work.” To improve communication about the project’s progress to the whole organization, it’s important to develop work visibility across all teams and functions by:
• “Using Tools to Reinforce Desired Behavior.” Tools help to support the cultural changes the DevOps transformation implements and expedite the desired behavioral changes by Development and Operations. Collating a common backlog of work over a common work system and shared work queue requires these tools. The tools will empower fast workflow in your team. Chat rooms, for example, are great for enabling team members to help each other and exchange information swiftly. Other tools, such as kanban boards, help to improve work visibility and prevent constraints from holding up the value stream. All of which can improve a team’s dynamic and environment.

If you’re looking for ways to integrate DevOps into your organization, give Caylent a try here.

Up next DevOps Handbook Series Part 2: Defining DevOps Teams

Caylent is a cloud-native services company that helps organizations bring the best out of their people and technology using AWS. We are living in a software-defined world where technology is at the core of every business. To thrive in this paradigm, organizations need to empower their people and processes through technology. Caylent is uniquely positioned to fuel that engine of innovation by bringing ambitious ideas to life for our customers.

Caylent works with customers to build, scale and optimize sophisticated cloud solutions using deep subject matter expertise to deliver world-class outcomes through an agile co-delivery model.

Reference material:
Kim, G., Debois, P., Willis, J., & Humble, J. (2016). The DevOps handbook: how to create world-class agility, reliability, and security in technology organizations. Portland, OR: IT Revolution Press, LLC.

All credit for the book’s material goes to authors and founders of the DevOps movement Gene Kim, Jez Humble, Patrick Debois, and John Willis. I’m simply here to provide the Handbook’s key lessons in summary form for readers who are short on time.