5 best practices for getting started with DevOps


(as originally shared at OpenSource.com)

Are you ready to implement DevOps, but don’t know where to begin? Try these five best practices.

DevOps often stymies early adopters with its ambiguity, not to mention its depth and breadth. By the time someone buys into the idea of DevOps, their first questions usually are: “How do I get started?” and “How do I measure success?” These five best practices are a great road map to starting your DevOps journey.

1. Measure all the things

You don’t know for sure that your efforts are even making things better unless you can quantify the outcomes. Are my features getting out to customers more rapidly? Are fewer defects escaping to them? Are we responding to and recovering more quickly from failure?

Before you change anything, think about what kinds of outcomes you expect from your DevOps transformation. When you’re further into your DevOps journey, you’ll enjoy a rich array of near-real-time reports on everything about your service. But consider starting with these two metrics:

  • Time to market measures the end-to-end, often customer-facing, business experience. It usually begins when a feature is formally conceived and ends when the customer can consume the feature in production. Time to market is not mainly an engineering team metric; more importantly it shows your business’ complete end-to-end efficiency in bringing valuable new features to market and isolates opportunities for system-wide improvement.
  • Cycle time measures the engineering team process. Once work on a new feature starts, when does it become available in production? This metric is very useful for understanding the efficiency of the engineering team and isolating opportunities for team-level improvement.

2. Get your process off the ground

DevOps success requires an organization to put a regular (and hopefully effective) process in place and relentlessly improve upon it. It doesn’t have to start out being effective, but it must be a regular process. Usually that it’s some flavor of agile methodology like Scrum or Scrumban; sometimes it’s a Lean derivative. Whichever way you go, pick a formal process, start using it, and get the basics right.

Regular inspect-and-adapt behaviors are key to your DevOps success. Make good use of opportunities like the stakeholder demo, team retrospectives, and daily standups to find opportunities to improve your process.

A lot of your DevOps success hinges on people working effectively together. People on a team need to work from a common process that they are empowered to improve upon. They also need regular opportunities to share what they are learning with other stakeholders, both upstream and downstream, in the process.

Good process discipline will help your organization consume the other benefits of DevOps at the great speed that comes as your success builds.

Although it’s common for more development-oriented teams to successfully adopt processes like Scrum, operations-focused teams (or others that are more interrupt-driven) may opt for a process with a more near-term commitment horizon, such as Kanban.

3. Visualize your end-to-end workflow

There is tremendous power in being able to see who’s working on what part of your service at any given time. Visualizing your workflow will help people know what they need to work on next, how much work is in progress, and where the bottlenecks are in the process.

You can’t effectively limit work in process until you can see it and quantify it. Likewise, you can’t effectively eliminate bottlenecks until you can clearly see them.

Visualizing the entire workflow will help people in all parts of the organization understand how their work contributes to the success of the whole. It can catalyze relationship-building across organizational boundaries to help your teams collaborate more effectively towards a shared sense of success.

4. Continuous all the things

DevOps promises a dizzying array of compelling automation. But Rome wasn’t built in a day. One of the first areas you can focus your efforts on is continuous integration (CI). But don’t stop there; you’ll want to follow quickly with continuous delivery (CD) and eventually continuous deployment.

Your CD pipeline is your opportunity to inject all manner of automated quality testing into your process. The moment new code is committed, your CD pipeline should run a battery of tests against the code and the successfully built artifact. The artifact that comes out at the end of this gauntlet is what progresses along your process until eventually it’s seen by customers in production.

Another “continuous” that doesn’t get enough attention is continuous improvement. That’s as simple as setting some time aside each day to ask your colleagues: “What small thing can we do today to get better at how we do our work?” These small, daily changes compound over time into more profound results. You’ll be pleasantly surprised! But it also gets people thinking all the time about how to improve things.

5. Gherkinize

Fostering more effective communication across your organization is crucial to fostering the sort of systems thinking prevalent in successful DevOps journeys. One way to help that along is to use a shared language between the business and the engineers to express the desired acceptance criteria for new features. A good product manager can learn Gherkin in a day and begin using it to express acceptance criteria in an unambiguous, structured form of plain English. Engineers can use this Gherkinized acceptance criteria to write acceptance tests against the criteria, and then develop their feature code until the tests pass. This is a simplification of acceptance test-driven development (ATDD) that can also help kick start your DevOps culture and engineering practice.

Start on your journey

Don’t be discouraged by getting started with your DevOps practice. It’s a journey. And hopefully these five ideas give you solid ways to get started.

Advertisements

2 comments

  1. Great post! I’m so glad you didn’t get caught up in tools, titles, and job positions. So many people think that DevOps is a job title or a methodology when it’s really more of a philosophy.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s