Just like no two playbooks for the NFL or the NBA are alike, the same is true for DevOps playbooks. Playbooks are based on your team, your competitors (opponent), and the role and importance of the application (preseason or playoff game).
Value Stream Mapping
One of the first steps you need to complete before building your playbook is value stream mapping. Value stream mapping is a method to illustrate, analyze and improve the steps required to deliver your application. It allows you to take a look at the inefficiencies that exist in your process today.
Start with the developers, and work your way through the entire process. Where are the wait-states and unnecessary process steps happening? A lot of inefficiencies happen around handoffs between stakeholders.
Once you’ve mapped out and examined the process, you’re ready to develop some plays based on what you’ve learned.
Play 1: Remove The Biggest Bottleneck
Not everyone has the same issues. Maybe you found that handoffs between your developer and your DBA take days. Maybe you find that your developers have to wait a week to get a proper environment set up. Whatever you found to be the biggest bottleneck in your value stream mapping exercise, fix that issue first.
Play 2: Keep Going
Take on the next biggest bottleneck.
Play 3: Don’t Stop
That’s it. In order to drive DevOps success within your organization, you can’t stop.
Many executives fall into the trap of thinking, “We’re done! We’ve completed the DevOps initiative!” They achieve level 5 on their maturity model, and they stop investing in getting better.
DevOps is a lot like getting in shape. You can’t just buy a gym membership and expect results. You need to put the work in. If you want to run a marathon, you need to train. When you train for a marathon, you also need to gather data to make sure you achieve your goals.
Four Key Metrics To Track
There are four key metrics software teams need to continuously track because they directly affect availability, which affects the promises made to your customers:
- Lead time: What should the timeline be to get from code check-in to code in production?
- Frequency: How often do we deploy code?
- Change fail rate: The percentage of changes that miss the mark.
- Time to restore: How much time does it take to get things up and running again if there is an issue?
Keeping In Shape
This is where a lot of DevOps initiatives fail. Once a team hits its goal (“We completed the marathon!”), the members of that team think they’re done. You should definitely celebrate the achievement with your team. But you aren’t done. This is where you need to keep going.
Let’s say you stop and a year goes by without training. Do you think you’ll be able to run the marathon again? Nope. Just because you ran a marathon a year ago doesn’t mean you can run one now without training. And guess what. Your competitors are running this race, and they have been training.
DevOps Has Crossed The Chasm
DevOps is now more mainstream. This means more and more companies are realizing how it can help them.
This is an exciting time because anyone can master DevOps. It’s also a scary time because your competitors are mastering DevOps. They’re purchasing technology that enables their teams to deploy faster and they’re optimizing their processes to ensure they win the next race.
Your goal in using DevOps is to develop and deliver software with speed and stability so that you can deliver value to end users and customers. That never stops.
As the Greek philosopher Heraclitus once said, “Change is the only constant.”
Summing It Up
There is no silver bullet tool that can magically solve all of your DevOps problems. Don’t believe any vendor that tells you they can solve DevOps in general. Look for vendors that help you solve the specific issue that’s in the way of your team delivering software with speed and stability.
Technology changes. Teams change, and competitors change, so you need to keep evaluating your software release process and keep optimizing.