DevOps Technician Training: Think Requirements, Not Solutions

DZone 's Guide to

DevOps Technician Training: Think Requirements, Not Solutions

Learn how to guide your DevOps technicians to turn common behaviors into productive ones, like rephrasing what they want as requirements.

· DevOps Zone ·
Free Resource

This is the eleventh in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner, and Sacha Labourey, CEO, CloudBees.

By nature, technicians are problem solvers. Many companies assess an individual's ability to solve problems as a precursor to an employment offer.

If you are delivering a DevOps transformation, your key customer group will be your DevOps technicians. It is critical you differentiate your customers (DevOps technicians) from your stakeholders and sponsors (the business and executives).

A key point to remember about your customers, or technicians, is that some find it easier to articulate solutions rather than requirements. The desire to resolve problems is critical and should not be discouraged, however in the absence of further information it can be particularly challenging for any organization.

Examples of Common Behaviors

"I don't want this, I want that as it is better/easier to use.''

Anybody who has rolled out an automation solution will recognize this feedback. One of the advantages with today's technicians is they regularly work on their own projects outside of company time. This means your customer group, the DevOps technicians, will have significant knowledge of solutions available and will often have experience using a variety of automation solutions. This is an advantage to the enterprise.

The challenge, if you are delivering automation solutions, is that this knowledge often leads to significant pressure for a multitude of solutions.

We previously discussed how to create a governance structure that enables the voice of the DevOps technician to both be heard and acted upon. (In a forthcoming post, we shall discuss those areas of your automation chain that are more open to diversity and those which better suit a limited range of solutions.) All we can guarantee is that in a large population, you will regularly find a significant minority who request a specific solution on the grounds they prefer it to the current option. One of the great joys of humans is we abhor mass consensus.

While personal preference is a consideration to procurement, we have not met many chief financial officers who will sign the check based on this, alone. It is critical that some business benefit is espoused if an investment is to be obtained.

"I need you to change this product so that it does this, followed by this and connects to that via this."

This is a slightly different situation. It is also very common.

The DevOps technician has a requirement, and rather than raising a discussion about that requirement, has worked out how it could potentially be solved by some specific changes to the automation chain or a tool within it. The solution may be correct, but it may not be optimal. It is critical the requirement is understood before the potential solution is assessed. It may be that the problem has already been solved elsewhere and the requestor is not aware of this. It may be this is a genuine requirement, but the suggested solution will cause unforeseen issues elsewhere that the requestor is not aware of.

Encourage Ideas, but Insist on Requirements

We firmly believe the enthusiasm and ability of the technical community in any enterprise is a critical asset that should be harnessed. We further believe DevOps technicians consuming any automation pipeline or processes daily are best placed to identify the shortcomings and issues. They should be firmly encouraged to articulate any issues or requirements as this is critical to the culture that DevOps relies upon. We would argue that if the organization is not open to feedback, the technicians will find ways around the issues they face within the 'gray economy' of your organization which will create problems in the medium term.

As we synthesize all the issues, any solutions posted into a requirement portal should be pushed back to the requester with instructions that they articulate their requirement first, and then detail their potential solution on the same ticket.

By understanding requirements, the organization can:

  • Better detail the process and any gaps within it.
  • Understand issue and functional gap patterns. Requirements tend to be common and suggested solutions bespoke.
  • Better prioritize solution deliverables by aligning them to business requirements.
  • Create business cases for actions as it is easier to assign value to a requirement. A solution normally involves cost.

By training DevOps technicians to better articulate their requests as requirements, you can increase skills across your organization which can assist in other areas. An individual who thinks in terms of requirements rather than solutions can use this skill to improve their approach to testing their own product.

devops, enterprise devops, governance, software development

Published at DZone with permission of Sacha Labourey , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}