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. 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“