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