“How do I get started?” Key steps to improving your end-to-end DevOps process

There is an extraordinary variety of DevOps solutions available on the marketplace — so much so that choosing the right portfolio can be daunting. Often, comparing solutions can get murky because top-rated solutions won’t necessarily mean the best fit for an organization’s unique needs. Many organizations may wonder: “How can we get started on reaching the intended outcomes without getting lost in a sea of options?”

The key is to start with the outcome — or the challenge to be overcome — and work backward. This can refer to a challenge where a DevOps leader wants to optimize their process, and it can most definitely refer to a situation where a team is looking to select the tool pipeline most likely to help their organization reach their goal outcomes.

Overall, IT decision-makers should focus on the overall sum of parts for their end-to-end DevOps process when considering making changes. This holistic focus will allow them to identify targeted improvements that can have a net positive cumulative effect on the overall process. It will also help them anticipate the outcome of decisions intended to affect individual parts of DevOps but that will have inevitable effects process-wide.

Focus on problems with the end-to-end process in view

Having a view of the organization-wide, end-to-end process needed to achieve the desired outcome is critical. In other words, it’s not enough to imagine what a change in an isolated part of DevOps would look like. IT leaders must also consider how that change would reflect a revised end-to-end DevOps pipeline.

When quantifying problems and searching for their solutions, chart out the entire DevOps process. Isolate the stages of the process the challenge area might affect. Then, consider how possible solutions within this area will affect DevOps as a whole. The big picture should assemble all of the pieces in place necessary to achieve the desired outcome, creating a new process. In other words, the goal outcome is a new, revised process for the entirety of the product pipeline, even if the change feels like a small one.

Focusing solely on the choice of individual solutions and their effects on individual stages of DevOps fragments your view of the given problem. The limited views offered means your efforts to achieve the outcome will be constrained by whether or not individual choices happen to fit together into the whole. 

Siloing also presents smaller challenges within the end-to-end process. For example, without consideration of how a new development environment integrates automated code integrity checks, new unexpected security vulnerabilities could arise after implementation.
The siloing challenge is why it is so beneficial to visualize your entire DevOps toolchain/pipeline. End-to-end process visualization allows you to make intentional, broad-reaching changes needed to achieve the desired transformative effect.

Gartner, in the context of value stream delivery platforms, describes this cohesive end-to-end view as a means to “enable organizations to simplify building and managing DevOps pipelines,” while minimizing “the overhead involved in orchestration, integration, and governance, thus maximizing value by providing visibility, traceability, and observability into the flow of work.”

Thus, according to Gartner, building a deliberate end-to-end process means less effort is required during daily work and better results are attained. Also, product managers, as well as security/compliance/governance leaders, gain more control over the outcomes of that work.

With the goal of having a holistic view of the problem/challenge and channeling solution/tool choices towards a specific outcome, businesses can get started improving using the following steps:

1. Identify the problem (ones with the biggest impact, potential benefit)
2. Pick the solutions/tools you need to address the problem
3. Over time, you can improve your overall end-to-end process (from planning to production)

It is important to note that visualizing the new end-to-end process can kick off iterative improvements towards that ideal. There’s no reason to assume the transformation overhaul has to happen all at once! Start with small wins in the biggest problem areas, and be prepared to continually revise what your expected end-to-end DevOps process will look like.

1. Start by isolating your most important problems

Organizations have to begin finding solutions with the answer to the question: “what problem am I looking to solve?”

There’s no need to solve all problems at once — an overwhelming prospect that often leads to delays in process improvements.

Scott Erlanger, Director of Product Marketing Agile & DevOps at Digital.ai suggests to  “Start with the ones that are the most important problems”

For example:

• Which problems cost time? i.e. Where can we achieve greater efficiency?
• Which problems reduce reliability or quality? i.e. Where are bugs/quality issues arising?
• Which problems limit release frequency? Look to manual approvals, inelegant handoffs
• Which problems introduce risk?

Gather a team of DevOps leaders to brainstorm and then rank problems. Be sure to get input from multiple stakeholders sources from across the organization, not just within DevOps leadership silos. Collectively, look for opportunities to categorize problems into common organizational areas, root causes, or impact effects. 
Isolate problems that offer the biggest quick wins, and focus on these areas to begin revising your process towards the desired outcome.

2. Evaluate available tools and solutions

The solution to your problem can involve a new tool and/or a process improvement. Just like with isolating specific problems, the selection of solutions should be done with input from across DevOps and the organization as a whole. Collectively, brainstorm your options and evaluate them on a case-by-case basis.

As mentioned earlier, there’s an overwhelming amount of DevOps tools solutions available. Digital.ai provides these organizations with a platform that catalogs solutions according to their role within DevOps as well as their specific characteristics and features. IT leadership can rely upon the Periodic Table of DevOps Tools to isolate options, evaluate them, make comparisons, and most importantly chart how the solution would fit within their existing end-to-end process.

Importantly, the periodic table doesn’t just catalog tools but also provides a means to see how those tools would fit within your existing end-to-end process. It is possible to build a mockup pipeline using a combination of your existing tools and proposed new ones selected from the periodic table. The mockup allows IT leaders to look for gaps in continuity and ascertain a big picture for what the end-to-end process will look like after the introduction of new solutions.

Process improvements can be evaluated similarly. For example, when the proposed solution is to implement new scaled agile principles, IT leaders can construct a new pipeline with this goal in mind. Note, though, that changing process often comes down to a combination of changing tools and changing culture. Changes can be something as simple as adding a minute to stand up meetings for staff to disclose the biggest pain point of their past 24 hours, but the change must be measurable and discernible to the employees who will be involved.

On another note, it often helps to consider the impact of proposed changes or new tool/process adoptions from the perspective of key value metrics. E.g. Will this new testing tool allow us to release faster with fewer bugs? Considering the entirety of the DevOps toolchain and pipeline allows you to pursue these metric-based outcomes with more clarity and control.

3. Build a new process — revisit continually, and revise as needed

Once new solutions are proposed, take the time to visualize what a new end-to-end process will look like. This step is what differs when taking a holistic, end-to-end approach to solving DevOps challenges compared to a siloed approach. It is typically not enough to simply identify a fix for an isolated pocket within DevOps. Instead, envision “the new normal” and consider what the revised end-to-end process will look like.

After all, “solving” one problem within a silo can sometimes lead to unexpected consequences arising in other silos. E.g. a new gated evaluation tool in development could lead to an overall increase in lead times. Teams can also run into issues pertaining to discoordination/dysfunction between silos when the new internal process in one silo runs into legacy process in another silo. Taking an overarching process view attempts to anticipate these challenges and smooth them out in advance while priming all teams to coordinate towards the goal outcome.

Anticipating the “stitch” points representing handoffs between tools, workflows, or teams can allow you to seek as seamless of a solution as possible to resolve the prioritized pain point. E.g. how will this new release tool affect change approvals and operations?

It is important to recognize that once the new end-to-end process is made a reality, the organization will now want to move on to tackle new challenges lower on the priority list. They can go through the same cycle to iterate on the new process further, achieving incrementally better outcomes with each pass. It is true that the focus may change as new solutions are implemented or time passes, but the environment will change, too. This reality is why, overall, it is critical for new and legacy solutions to be evaluated in light of your current environment and current challenges.

Unsilo your view of proposed changes to achieve positive new outcomes across DevOps

Whether you call an organization’s framework agile or DevOps or VSM, the overall goal is to be more intentional with outcomes and to remove barriers to value creation. 

When wondering where to start improving, organizations must consider both the problems they want to solve and the big picture of “before vs after” for what the end-to-end process will look like once the solution is implemented. This holistic view prevents new silo creation while aiming to achieve unity behind all teams and activities towards a specific outcome, thereby (hopefully) eliminating the problems of the past. 

It’s acceptable in most cases to focus on isolated problems and quick wins, but always keep an eye on the holistic end-to-end process effects so that everyone can work towards a common goal without unexpected barriers arising.

Tools like the Periodic Table of DevOps Tools can allow you to visualize a revised end-to-end process while exploring some of the best-of-breed available solutions.

Once a challenge has been overcome, the process can restart. Revisiting the end-to-end pipeline and asking “what problems can we solve now?” allows an organization to respond flexibly to evolving conditions while continually improving upon past wins. 
Learn more about optimizing your process and selecting the right solutions in our recent webinar: “Demystify the DevOps Landscape with the Periodic Table of DevOps Tools & DevOps Diagram Generator“