Micro Focus is now part of OpenText. Learn more >

You are here

You are here

DevOps by the numbers: 5 key questions to ask

Anne Hungate President, Daring Systems

"Know Your Numbers" is more than just an effective campaign by the American Heart Association (AHA). That initiative improved the lives of millions of people by influencing their diet, exercise, and lifestyle choices to reduce the risk of heart disease.

Likewise, accelerating DevOps is all about the numbers. Where do you start with DevOps, and how do you show the business value if you don't know your numbers to begin with?

The current state

The noise around DevOps amounts to a constant and relentless throbbing of tools, automation, transformation, and efficiency claims. The pipeline of DevOps tools is confusing on a good day, and overwhelming on most.

Tools are useful, but tools before rules is a mistake. Understand the problem and process you are trying to fix and how you will measure whether you have fixed the problem, then implement the tool with the rules that help you realize your intended impact.

Organizations that are getting value from DevOps are applying process improvement and automation.

The DevOps opportunity

Small teams can most easily isolate problems, and they know when the get relief. But to make their efforts more visible and more likely to gain broad support, they must capture useful insights that relate to one of the four reasons why they pursue projects:

  • Growing the business
  • Protecting/enhancing the brand
  • Reducing risk
  • Cutting costs

Eric Ries coined the term vanity metrics in his book The Lean Startup to help people understand that metrics about DevOps need to tell a real story, not fuel the noise and confusion that already exist around DevOps. Metrics need to speak to at least one of the reasons projects are tackled.

Consider this: If you increase the number of builds per day but don't increase the speed at which new products get to market, you have not had an impact. And if you increase code coverage but still release a product filled with bugs, you have not had an impact.

There is opportunity here to start small and focus on what matters most.

Know what is in your control—and what is not

When you start DevOps at a grass-roots level, you may not be able to control enterprise technology standards or the priorities of another team. But you can control how you operate as a team—how to measure, isolate constraints, and use the tools in the reference architecture.

Any team interested in advancing its DevOps practice can benefit from a session where you identify what's helping and what's getting in the way. Once you've made these lists, break them down further into what's in your control and what's not.

Focus on those items that are within your team's control and are getting in the way of progress.

If there are items within your team's control that can help you succeed, add some easy measurements to understand how helpful they actually are. This is an opportunity to share the learning and impact. And this is how you can use what is in your control to drive lasting change and make the most of the limitations of a software delivery ecosystem.

Most of the resources you need to effect change with DevOps are within your control, and you should see them as such. You can streamline your tool set, get training, isolate bottlenecks, and manage your technical environment.

Answer five key questions

In software delivery, there are five core questions you need to answer to determine whether you are at risk of missing out on potential improvements.

  • Which software applications are the most important for the business?
  • Which projects are most important to do?
  • Do you have the right people in the right place at the right time to support your production systems and deliver your projects?
  • How much technical debt is affecting your production systems, and how is it trending?
  • Which step in software delivery takes the longest, and in which step are the most problems introduced?

If a technology team has clear answers to those five questions and reviews them consistently (on a monthly basis), it can focus its DevOps efforts on what matters most. Answers to these five questions can guide both tactical and strategic decisions.

The answers to these questions may be the same for months at a time—but looking at them every single month is critical. These questions apply at every level of an organization, from the C-suite to the distributed team.

Every person on the team should know which applications are most important to the business and which projects are the most important to do now. Having one priority list is essential. Too often, teams feel as if they are failing because they have too much work in flight—too many projects, conflicting priorities, and constant context switching. That's a productivity killer.

Establish a priority scheme and enforce it. Revisit it monthly to make sure you are still working on what matters most. Create a forum and practice for team members to say when they are confused about priorities or experiencing too many interruptions.

Know your people

The people question recognizes that teams have both specialized skills and general skills that are essential to running and delivering software solutions. Those skills change over time, and the training and development necessary for everyone needs to be clear. By asking this question every month, the team or organization can focus on cross-training, learning, resource sharing, and key vendor partnerships.

This question implies that teams and organizations have a good grasp of who they have and what special skills or talents each person brings to the team. This question also implies a thorough understanding of what is needed today—and a directional idea of what will be needed tomorrow.

There's another reason why this is important: I did a strategic workforce assessment several years ago and learned that 90% of my team-supporting core systems were eligible for retirement within three years. This was a huge eye-opener and caused me to build in job rotation, cross-training, and other risk mitigation strategies. Within six months, we had cut the risk in half. Within 18 months, the risk nearly eliminated.

Know your technical debt

Understanding technical debt begins with knowing which technologies and assets your organization is using. Many teams see this as adminis-trivia—but keeping an up-to-date inventory should be as common as reconciling your checkbook on a monthly basis.

The second step is to know which technologies and assets are supported, strategic, targeted, and approved. Everything else is technical debt. Some types of debt are worse than others; each team needs to understand this and manage it accordingly.

Monitoring technical debt means knowing, at all times, what debt you have and its carrying costs. Sometimes you take on debt as leverage to create an opportunity; at other times it's an anchor keeping you from being successful. Follow it on a monthly basis and optimize it for your organization.

Know your constraints

The final question in knowing your numbers involves understanding where your constraints are when delivering software. This is the fifth question because you might have constraints in processes and applications that are lower in importance, and those may need to wait.

The best exercise to determine where there are constraints is value stream mapping. Follow an idea from conception to delivery and see where the hiccups happen and where the challenge is. Enlist the whole team in the exercise; this is not a management-only activity.

Value stream mapping can help with prioritization; it can help you see where in the system the team is getting hung up and where a little effort can pay a huge dividend.

I recently went through a constraints exercise with a team and discovered that the biggest bottleneck in its system was communication. The team did not need a new tool or technology; it needed to strengthen two-way dialogue on the team. Once the team members understood the workflow between individuals, they increased their velocity just by building empathy.

Take these other actions

The AHA closes out "Know Your Numbers" with the specific actions every person needs to take to lower his or her risk for heart disease. These seem like common-sense ideas, but when written down, repeated, and acted upon, they get results.

Technology teams that want to benefit from DevOps must also take specific actions on a daily basis that help increase business value. These are in addition to the steps already outlined above.

Manage your production environment

This means making sure you are monitoring the usage, performance, availability, and recoverability of your production systems. And this includes understanding criticality to the business, providing the necessary continuity plan, and ensuring that you have a partnership with the business.

Define and support your preferred delivery method

Are you agile, waterfall, Kanban, Scrum, or a hybrid? The only way to answer this question incorrectly is to say yes to all of them. Pick one or two and use them consistently throughout your delivery.

When you know the path that work will follow on its way to production, you can put in processes, tools, controls, and measures to make sure you are delivering the highest-quality product. If you do not have a plan to get from beginning to end, you are likely to get lost—and you are never going to leverage the opportunity DevOps presents.

Engage the team

The team is the process. Use visible charts and signs to highlight successes and misses. The answers do not come from management; the guidance, support, resources, and context do. The answers come from the team. Leaders who tell their team exactly how to work miss the brilliance and insight that come from each person.

Hold a monthly operations review

This does not need to be a long meeting; it is a monthly view of the five key indicators. The team can reflect on what went right, what did not go right, and then adjust. Once you have done this for three months in a row, you can begin to trend and learn from the data.

Remember the endgame

DevOps is not a sudden breakthrough in technology; it's about the timely collapse and automation of your software delivery supply chain. This change needs to happen because organizations rely on software to do everything, from arranging transportation to entertaining a crying baby to figuring out where packages are. To get the best-quality, most consistent software, you need to automate error-prone and repetitive processes.

You start this journey like any other: at the beginning. That means knowing where you are. The AHA "Know Your Numbers" model offers you a guide for accelerating your DevOps journey.

The keys to success are:

  • Distinguish what is in your control from what is not in your control. Know the influencing factors that affect your ability to be successful and take action on only what you can control.
  • Be able to answer the five key questions that clarify priority, urgency, resources, and trends.
  • Follow the four steps above to a more rapid collapse and automation of your software delivery lifecycle.

Good luck getting started. Drop me a note in the comments field below and let me know how you're doing.

To learn more, drop in on my presentation, "A Successful DevOps Initiative Starts with Knowing Your Numbers!" at Agile + DevOps East in Orlando, Florida, November 4-9. See you there!

Keep learning

Read more articles about: App Dev & TestingDevOps