DevOps requires teamwork, tools, techniques, and above all, tenacity
DevOps helps coordinate the output of developers with production and release schedules, ensuring that things are available when needed. DevOps, however, means making a lot of changes in the organization. How do you get started and make things stick? It requires teamwork, tools, techniques, and above all, tenacity.
These elements are explored in a new book, The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. The co-authors, Gene Kim, Jez Humble, Patrick Debois, and John Willis, outline the strategies essential to initiating a DevOps operation, which they point out, "can enable the creation of dynamic learning organizations, achieving the amazing outcomes of fast flow and world-class reliability and security, as well as increased competitiveness and employee satisfaction."
It comes down to great leadership and teamwork, Kim and his co-authors explain. Here are a few salient points to get started on a DevOps journey:
Target DevOps efforts to the parts of the business that deliver the most impact. Kim and his co-authors label these more important parts of the enterprise as "value streams," which derives from the Lean movement. A value stream focuses on the downstream implications of IT -- right out to the end customer.
As with any technology initiative, avoid, like the plague, any "big bang" approaches and "focus efforts in a few areas of the organization, ensuring that those initiatives are successful, and expanding from there." This can apply to both brownfield and greenfield projects.
Understand the work that needs to be done in DevOps value streams. The onus is on DevOps organizers to "gain a sufficient understanding of how value is delivered to the customer: what work is performed and by whom, and what steps can we take to improve flow."
The workflow -- and nature of team members' work -- also needs to be understood and documented, Kim and his co-authors explain. It's important not to get too mired in the process, however. Pick out the areas that matter. The authors illustrate a typical DevOps workflow:
"Work likely begins with the product owner, in the form of a customer request or the formulation of a business hypothesis. Some time later, this work is accepted by development, where features are implemented in code and checked in to our version control repository. Builds are then integrated, tested in a production-like environment, and finally deployed into production, where they (ideally) create value for our customer."
Identify DevOps teams and leadership. Rather than imposing DevOps on random groups, find those individuals who are already showing the most enthusiasm for a DevOps approach, Don't spend time in the early stages "trying to convert the more conservative groups," Kim and his co-authors state. Then organize them into small teams, not exceeding five to 10 members.
Build critical mass as you go. As the effort progresses, "expand DevOps practices to more teams and value streams with the goal of creating a stable base of support," the authors advise. It's better to be able to show small but accelerating successes, which helps get around organizational politics.
Assign members of the dedicated team to be solely allocated to the DevOps transformation efforts -- not as a one-off side project. Make the DevOps effort special. Create a separate physical space for the dedicated team. This helps "maximize communication flow within the team, and creating some isolation from the rest of the organization." Keep the DevOps effort separate from organization, and make it the entire job of members.
Have specific, measurable goals for the DevOps team. For example, a working goal can be to "reduce the deployment lead time from 'code committed into version control to successfully running in production' by 50%."
Select team members who are generalists, who have skills across a wide variety of domains. "When departments over-specialize, it causes siloization," Kim and his co-authors warn. "We don't want to create specialists who are 'frozen in time,' only understanding and able to contribute to that one area of the value stream."
Use a common, shared DevOps toolset. Along with a kanban board that helps keep everyone in sync, having the same toolsets keeps everyone on the same page in terms of priorities, and keeps everyone aware and prepared as issues arise. This is just as critical as having common, shared goals.
"By doing this, development and operations may end up creating a shared work queue, instead of each silo using a different one (e.g., development uses JIRA while operations uses ServiceNow)," the authors state.
Fund services and products, not "projects." Under a project mentality, "development and test teams are assigned to a project and then reassigned to another project as soon as the project is completed and funding runs out.
This leads to all sorts of undesired outcomes, including developers being unable to see the long-term consequences of decisions they make (a form of feedback) and a funding model that only values and pays for the earliest stages of the software life cycle -- which, tragically, is also the least expensive part for successful products or services.
Create loosely coupled architectures. This may have a familiar ring to SOA veterans. Indeed, it borrows from the SOA-inspired notion that changes or issues in one part of a system won't bring down the other parts.
"When we have a tightly coupled architecture, small changes can result in large-scale failures," the authors state. "As a result, anyone working in one part of the system must constantly coordinate with anyone else working in another part of the system they may affect, including navigating complex and bureaucratic change management processes. Having architecture that is loosely coupled means that services can update in production independently, without having to update other services."