The Critical Role DevOps Plays in Agile Transformation

In my agile transformation coaching practice, I have seen firsthand how difficult it can be for organizations that are not addressing DevOps to be successful in their agile transformation efforts. Agile and DevOps, as well as their methodologies, are inextricably linked. Both require cultural, mindset, and behavioral changes, and both put the customer and delivering customer value at the forefront. Agile is focused on helping teams of developers speed up their development processes and minimize issues, so they can get better-quality, code-based features and enhancements to market faster. But it does an organization—and its customers—little good if the operations teams can’t release it. That’s where DevOps comes in, with its focus on the tight relationship between development and operations, and emphasis on automation of release processes.

I wrote briefly about the relationship between agile transformation success and DevOps in my previous blog post, Agile Transformation: Three Key Factors that Determine Your Success, but in this post, I’d like to dig into it a bit deeper.

The Customer Value Conundrum

The challenge that I see most often looks a bit like this: business teams and product owners are rightfully focused on customer value. They’re prioritizing the right features and enhancements—things that will bring the most value to customers—and developers are running sprints to bring them to fruition. Sounds great, right? However, the challenge I see is that organizations don’t always have the right applications and tools in place to deliver those features. Their legacy tech environments do not support releasing at the necessary speed or volume. The pre-release and post-release activities soon become overwhelming, the company decides to do it less often because it’s a hassle, the developers and the release team are at odds with one another, all that well-intentioned focus on delivering customer value goes to waste, and the business suffers.

The good news is, by putting the right tools in place, much of the hard work around releases can be automated, and these issues can be avoided or overcome. In fact, by automating many of these processes, development teams can test, deploy, release, and even do post-release validation all on their own. So why aren’t more of them doing it? Well, one reason I often come across is that as organizations were introducing agile to their teams, they failed to prioritize the application landscape improvements necessary to put the associated practices into place. Without the right tools, development and operations teams have no visibility into shared work, no way to collaborate, and no way to test and release regularly, so they continue to work in silos using their existing, complex, and slow processes. “Human processes” (human behaviors, manual processes, human activities) and tools need to be introduced at the same time.

Overcoming Barriers When Updating Your Application Landscape

While it’s always best to introduce agile mindset, methodologies, and underlying tooling at the same time, if an organization hasn’t done this, it’s not too late. Still, it’s often easier said than done, and organizations may encounter some internal barriers that need to be overcome, including overly restrictive governance, the inability to relinquish centralized decision-making power, lack of budget, and lack of cross-functional cooperation.

In prioritizing the application landscape, organizations should be aware of common barriers: overly restrictive governance that prevents necessary tool adoption; lack of governance that means tools are adopted willy-nilly and don’t work together; and inability to relinquish centralized decision-making power so teams who use the tools do not have a voice in their selection. In terms of budget, the tools don’t always necessitate big platform upgrades and need not be expensive. I’ve seen open source tools and even homegrown solutions make a big difference.

• Overly restrictive governance: Governance is critical, especially as organizations scale, to ensure focused, streamlined, adoption of integrated tools and to minimize silos, but it’s important to get the balance right. Organizations need to innovate around tools and processes as much as they do around product; there needs to be latitude for experimentation and change.
• Centralized decision-making: Agile transformation entails a shift from centralized decision-making to decentralized decision-making, so that the people with the deepest understanding and experience are making, or at least influencing, the decisions that impact them. It’s critical that software teams have a voice in the selection of tools that will help expedite every stage of software development and release.
• Lack of budget: Testing and implementing new DevOps tools does not necessarily require a massive investment in new platform infrastructure, or even a significant upgrade, although new tools may require some budget over time. There are many free, open source tools that organizations can get started with, including Jenkins, Kubernetes, and Terraform, to name a few. I have even seen homegrown solutions make a big impact.
• Lack of cross-functional cooperation: If your organization uses the Scaled Agile Framework (SAFe), or even if you’re familiar with it, you’ll know that it advocates for a CALMR approach to DevOps. And in that approach, the C stands for “culture of shared responsibility,” and that’s the first step to overcoming cross-functional resistance to adoption of critical, new tools. Organizations need to foster a culture that embraces change, especially changes that a given team did not initiate but will be impacted by.

Establishing a DevOps Center of Excellence

The application landscape is incredibly dynamic, and new innovations are coming at a rapid pace. Organizations that can keep up with these advancements and leverage the strongest ones, while avoiding getting bogged down in trying them all or having teams “go rogue” and start implementing their own tools, will have a distinct competitive advantage. That’s why I often encourage the companies I work with to establish an internal DevOps Center of Excellence. A DevOps Center of Excellence is essentially a small, nimble steering committee focused on fostering an environment of openness, prioritizing the exploration of new processes and tools, and consistently and iteratively examining and refining the way code is moved through the development, release, and feedback cycles.

In keeping with the necessity of decentralized decision-making, DevOps Center of Excellence members should be individuals from within the organization’s DevOps community who have an understanding of the strategic and operational goals of the company, and are passionate about exploring and implementing new, more effective and efficient processes and tools.

How Isos Technology Can Help

As a premier Atlassian Platinum and Enterprise Solution Partner with an Agile at Scale specialization, we’re experts in change management for people and processes, as well as tool adoption to support agile practices. Our comprehensive agile consulting services help organizations increase customer and employee satisfaction, improve operations, and enhance their ability to deliver. We offer support for agile transformations, agile coaching, agile training and certification, agile software implementations, maturity assessments, and agile staffing.

To learn more about Isos Technology’s agile services, including Enterprise Agile Coaching, visit isostech.com/services/agile-services.