Agile Transformation and DevOps: Beyond the Buzzwords

As someone who has been in the consulting and software delivery space for more than a couple of decades, I have seen approaches to building software come and go. Mostly go, really. However, the ones that have stayed are part of the evolution of how we do our work in this industry. Things will, no doubt, continue to evolve, but I want to look at today’s snapshot.

In today’s landscape of building software, there are many buzzwords that get bandied about. Two of the heavy hitters are “Agile Transformation” and “DevOps.” Terms about software development are often vague and mean different things to different folks, and these two are no exception. Also, these terms are synonymous to some people and complimentary to others. As a result, when someone claims they are “doing Agile” or “a DevOps engineer,” what does that mean?

Let’s answer the questions of what Agile Transformation and DevOps mean and how they do or do not relate to each other.

What is Agile Transformation?

First and foremost, Agile and Transformation are two buzzwords that have come together to form a super buzz phrase rivaled only by giants, such as “Thought Leadership” and “Leveraging Synergy.” However, once you’re done rolling your eyes, there is definite meaning in the phrase. Being agile evokes Spiderman deftly soaring about the city from web to building to web. Our friendly neighborhood hero has the ability to gracefully adjust his path based on the obstacles as they appear. Transformation is about change, in this context change around how you work in order to build software.

The use of the word “agile” has its roots in the Agile Manifesto (released in 2001!) which is a list of 4 value statements:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

Being agile is about what you value more.

So, Agile Transformation is the ability to change your values to drive the way you build software in order to effectively handle changes and obstacles as they surface. Let’s use that definition for the sake of this post.

What is DevOps?

DevOps is a portmanteau of “development” and “operations.” Presumably, the person who coined this phrase used this word to indicate that developers and operations people were working closely together. In days gone by, developers would develop and throw their code over the wall to operations who then had to deploy the application. This lead to many long nights, even longer meetings, and the longest lead times. The separation of groups promotes competing priorities, namely, delivering features vs maintaining stability. What it does not promote is fast, stable, sustainable software delivery.

Some very smart people came together and created a set of principles that, in my (and others’) opinion, form the foundation of DevOps:

• Maximize flow
• Minimize feedback loop time
• Share learnings
  

There are variations on the theme, but these are the three pillars of DevOps. So, (deep inhale) if you are reliably and securely deploying changes to production and receiving feedback from end users which you integrate back into the product through quick iteration cycles while also improving your software delivery process as issues arise, then you are “doing DevOps”(whew.)

DevOps is a set of ideals or principles that you can back with process and practices to deploy software in the true spirit of the Agile Manifesto.

What I Didn’t Mention

In coming up with definitions of these two items, you’ll notice I did not:

• Mention any tools
• Mention any specific practices
• Use words like “scrum,” “kanban,” or “cloud”
• Specify solutions like “microservices” or “nodejs”
  

  There is a reason for that. When done properly, Agile Transformation and DevOps are about outcomes. It is not about what tech you use or if you have a monolithic, ancient application. It is about focusing on capabilities to drive outcomes and using evidence to continuously improve those outcomes.

That’s not to say that tools are not important; in many cases you will find that tools must be adapted or sourced in order to enable new capabilities. When enabling capabilities is the focus, however, we may be more likely to see that a business process or team composition change can be a more effective solution than adding a tool to our delivery pipeline.

So, Are They the Same Thing?

There is a school of thought claiming that Agile processes are focused entirely on software development, ending when the code reaches the deployment stage. Subscribers to this belief postulate that DevOps fills the deployment gap, as it makes deployment and operation of software a consideration of all other upstream tasks. If you want to put these two concepts together like puzzle pieces, this is one way to do that.

Another way to look at it is Agile processes focus on human-centered, problem solving areas while DevOps focus on computer-centered,automated tasks. There is, of course, some overlap, as shown in the following figure.

Agile Transformation and DevOps are not the same things, but they do enable each other. Without transforming to Agile development, the industry may not have embraced improvement so wholeheartedly. Without DevOps, Agile may not have ever been deemed a success because deployment is such a huge part of measuring software delivery success.

Probably the single thing that Agile Transformation and DevOps have most in common is how they are done wrong much more often than they are done right. Having said that, how do you do them right?

Doing It Right

There is no formula for how to have a successful Agile Transformation that applies to every company. The journey to Agile development and DevOps is different for different teams in different situations. Now, before I start calling you “grasshopper” and answering all your questions with questions, there are cultural ideals and capabilities you can work towards to start your journey.

Know and Share the Reasons

Any successful change in how a team works needs to be powered by solid, well-understood reasons. So many companies start down the path of Agile Transformation or DevOps because they feel like they are late to the game or they are currently on fire and think “doing Agile” will put out the flames. The developers are told they are going Agile and given a set of rituals to follow with no idea what the purpose of the rituals are.

When you start the journey, the team needs to understand why Agile Transformation is the way and how it will be measured. Pick metrics and set goals that align with strategic outcomes. Share them with the team. Make the outcomes time-bound and achievable.

Don’t go Agile by copying and pasting someone else’s process or tools. It won’t work.

Stop Thinking of It as a Quest with an End

A foundational pillar of Agile Transformation is continuous improvement. The goal is to continually get better at what you do. The only way this effort ends is when you stop trying to improve. When done right, a team that has a solid Agile software development process and good DevOps practices will understand this.

Create a Learning-focused Workplace

Most of our learnings in life come from failure. If you’re focused on learning new ways to improve that means you need failure. Are people in your organization afraid of failing? If so, you’ll have a hard time getting better.

So, what if you could create a framework where small experiments resulting in small successes and failures gave your team learnings they could feed into their jobs? Good news, you can do that. Encourage experimentation to test out improvements. Make failure OK. Can you use trunk-based development to go faster? Can you carve out a single application and automate daily/hourly/on-demand deployments?

Measure It

When we’re talking about outcomes, we’re talking about measuring results. So many companies start down the path to Agile Transformation by getting Scrum training, planning sprint-ish things, and not writing any documentation. Unsurprisingly, this is not the way.

Picking outcomes that move the needle and measuring progress against those outcomes is how it should start. For example, in the book “Accelerate” (see Resources section below,) four base metrics around Continuous Delivery are mentioned. The first one is “Delivery Lead Time”, which is the time between when code is committed until it is deployed to production. Once you’re measuring this value, you are driven to find ways to improve it. It’s tangible and leads to really digging into the software value chain and finding constraints.

This may lead to Agile rituals, but these rituals will be tailored to how your team works. When you’re tailoring the Agile approach to your team, you are moving the needle.

Limit Work in Progress and Make It Visible

Limiting work in progress is another way to ensure that your team is working in small batches. If you’re working in small batches, then you’re getting more feedback quicker. If you’re getting more feedback quicker, you’re learning quicker and can apply those learnings to your process and your software.

Also, using swimlanes to show the team (and other stakeholders) what work is currently happening holds people accountable and shines a light on constraints in the software value chain. You can perform Value Stream Mappings to find what parts of the chain are most ripe for improvement.

Empower Your Team

Your people are, by far, the most important aspect of implementing a successful software delivery and deployment process. Trust them to make intelligent changes to specs and pick their own tools. Give them time to experiment and forums to collaborate. Recognize and reward individuals for their efforts. Encourage automation to reduce deployment pain.

Build a cross-functional team that can handle every task required to build and deploy the software. If developers are throwing features over the wall to testers who then pass the buck to the Ops team, then it is highly unlikely your team is delivering at a high level.

When your leadership transforms the way the team works, they will run toward success at a full sprint.

Conclusion

At the outset of this post, my goal was to define Agile Transformation and DevOps and show how they relate to each other. I have seen people misuse these terms repeatedly in my career. These concepts are not about a methodology or a tool, but a set of cultural values that can be difficult to implement but are wholly enjoyable to do correctly.

Resources

If you are looking to go deeper into these subjects, there are a couple of books I can recommend.

• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Dubois, and John Willis
• DevOps In Practice by J. Paul Reed
• Accelerate by Nicole Forsgren, PhD, Jez Humble, and Gene Kim
• The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford
  

  These books (many with the same authors) focus on many of the themes I discussed in this post. I hope you find them as useful as I did.