Skip to main content
DevOps icon showing cogs
Last Updated Aug 02, 2021 —

Building better processes Part I: Should processes be tools-driven or requirements-driven?

This piece will look at why, conceptually, processes should be requirements-driven. It will also touch upon how to set goals for reaching processes that reflect requirements in order to work backward towards an ideal outcome.

DevOps

This piece will look at why, conceptually, processes should be requirements-driven. It will also touch upon how to set goals for reaching processes that reflect requirements in order to work backward towards an ideal outcome. Part 2 will provide some guidance on how to weigh requirements and incorporate them into your vision for what processes should, ultimately, look like.

When constructing agile processes for DevOps and organizations in digital transformation, IT leaders want to focus on optimization. The ideal processes account for all needed deliverables, incorporate priorities like governance, and seek the most efficient value creation possible ⁠— all while allowing for iterative improvements on both the product and the process itself. 

However, many IT leaders can run into a roadblock: the tools DevOps teams use tend to dictate workflow and the architecture of the end-to-end pipeline. They are then left with the question: should I concede and let tool environments dictate our process structure? Or should that structure be continually evaluated in light of our actual goal requirements?

To bluntly answer the headline question: processes should be requirements-driven, full stop. If requirements aren't being met, it can negatively affect the product while preventing the organization from reaching its full productive potential. Staff will encounter frustrations, and copious amounts of energy will be spent simply engaging with the process rather than creating measurable value to end customers and internal stakeholders.

Getting to the point where requirements can drive the process

Saying "everything should be requirements-driven" is easy enough, but this means organizations must take the time to brainstorm, research, and develop a method of actually quantifying requirements. Requirements should also be based upon criteria that ultimately ensure more valued products are created and that internal work can produce quality results on an efficient and consistent basis.

Insisting that processes reflect requirements does not preclude the use of specific tools. This is especially the case in verticals that may need specific tools, such as a compliance monitoring tool for aerospace and defense software development. In these cases, however, the tools themselves matter because there is no other available means of meeting the requirements.

Another challenge organizations may encounter is that it's easier to navigate solutions on a per-product basis rather than by looking for criteria or features that meet specific requirements.  Organizations must often work backward from a requirement to uncover which tool features and criteria are needed so that their requirements can be met. Finally, an organization may have to compromise on some requirements to meet others. 

Even with these admitted challenges, the overall goal of forming a new process or revising an existing one should be to not let tools (or their enticing features) dictate the architecture of your DevOps pipeline. Instead, let requirements control this architecture, and focus aggressively on what outcomes your teams ultimately desire. Then, ask hard questions about what process changes need to be made to uncover which tools can help accommodate teams best.

Organizations face limited choices, forcing them to work backwards from requirements to tool comparisons

Ensuring your processes are fully requirements-driven may not sound realistic in a products-driven world. Pre-built, off-the-shelf solutions typically offer only a specific set of capabilities and features. In cases where a solution can be customized, organizations are typically limited to a menu of options.

Organizations can also decide to build custom solutions from scratch, but this can be expensive if implemented across the board for all processes. The organization may feel forced to "reinvent the wheel" and build a pipeline piece by piece when it should, instead, be building a value-delivering product. 

On top of this, the organization may not know what exact features to build within these proprietary solutions. Unless they are a solutions provider themselves, they cannot invent specifications out of thin air. They must rely mostly on existing solutions to chart the course for how their house-built alternatives will be configured. There are some notable exceptions where a team has invented a completely new architecture (see Slack), but in many cases, companies are simply trying to build their own version of existing solutions, often with mixtures of features from the most popular tools.

Therefore, an organization’s processes will inevitably be reflective of the tools you use, whether bought or built. With this admission, it becomes an uphill battle to keep requirements at the forefront of acquisition choices or process changes — but this is a critical battle to fight. Otherwise, tools end up dictating workflows and setting expectations for performance outcomes. Teams end up feeling like the product of their labor is limited to their tools' capabilities rather than an ultimate vision of the outcome their processes produce.

Make your processes requirements-driven, whether shopping for solutions, building a DevOps pipeline, or revamping your current pipeline

It is admittedly difficult to focus entirely on requirements when options available force you to focus on specific feature sets or capabilities. Even when building from scratch or customizing, organizations often feel limited to specific approaches dictated by what's available — or what's perceived as reasonably accomplishable.

Problems can arise when the feeling of being locked into a specific process delivers unsatisfactory outcomes. Like a home cook whose meal choices feel constrained to a limited set of stock ingredients, organizations may feel unsatisfied when they allow tools to dictate what they are capable of creating.

To ensure requirements are being recognized, let alone met, organizations should regularly take stock of their requirements and ask hard questions about the current solutions being used. They should create a list of features and capabilities that satisfy the agreed-upon requirements, then they must evaluate solutions to work backward and procure/build tools that have the best mix of the needed capabilities. They must also re-evaluate choices regularly to improve processes or change tools as needed. 

Organizational leaders can collaborate to develop a formalized list, framework, or matrix of requirements and use these to evaluate whether solutions or processes can "fit the bill". Example evaluative tools include CMMI — Capability Maturity Model Integration. The organization can also establish a framework similar to the aerospace industry's DO-178B regulatory-based product evaluation tool.

No matter the approach, don't be dazzled by the tools themselves. After all, any organization can pick up and use the same tools. It's like if you went to a craft fair and everyone offered only the same products made with one type of kit purchased off the shelf of a hobby store — no differentiation, and no innovation. It's only when the tools are assembled in such a way to fit specific requirements aligned with a unique vision that an organization can provide something with precious — and irreplaceable — value.

Part 2 of this post will provide insights on how to assemble a list of requirements, prioritize them, and then use them to form a vision for processes that better reflect goal outcomes.

Learn how to evaluate tool options and visualize how your choices affect the end-to-end DevOps pipeline in our recent webinar: "Demystify the DevOps Landscape with the Periodic Table of DevOps Tools & DevOps Diagram Generator"
 

More from the Blog

View more
Aug 16, 2021

A DevOps Pipeline Map Shows What Your Organization Has Been Overlooking

Value Stream Management
Implementing DevOps to streamline software development offers expanded ...
Read More
Apr 21, 2014

The Agile Regression: How to Avoid Moving Backwards

Enterprise Agile Planning
After the Webinar – More Insights from the Experts, part 2  Last week ...
Read More
Jul 21, 2014

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

Enterprise Agile Planning
WARNING: Shameless plug for my session at Agile2014 ahead. I recently ...
Read More
Jun 10, 2021

Desilo DevOps: The power of bringing all your tools and data into one view

DevOps
When discussing value stream management (VSM), our resources talk a lo ...
Read More
Contact Us