The Ugly Reality of Agile and DevOps

Introduction

The Agile and DevOps world is plagued by confusion, misinformation, and #FakeNews due to the industry’s obsession with tools and processes which have led to a grave misunderstanding of these concepts. Further exacerbated by snake oil salesmen and the certification industry. In this article we expose the fallacy of treating Agile and DevOps as mere checklists for “best” practices, and urge you to break free from the tool trap in order to embrace the true essence of agility.

The Great Deception: Scrum Is Not Agile

If you say you are Agile because you work in Sprints, you are not Agile. In fact, I bet you are not even leveraging Scrum appropriately. The reality is that Scrum is a framework, which means that it is purposefully incomplete. This means that even if you implemented the Scrum Guide verbatim, you likely would still not be Agile. In fact, you will not even find the word “agile” anywhere in the guide. That’s because Scrum actually predates the term “Agile” and is based on Empiricism or the Lean Cycle. 

Agile is short for The Manifesto for Agile Software Development and is a collection of four values and twelve principles as defined by software developers for software development. Scrum has been simplified over the years and purposefully is industry agnostic. While it mostly is used in IT and can be effective there, the fact that it has no guidance around software specific practices should be a red flag to anyone looking to leverage it in that capacity. This has also left it wide open to be adopted by traditional process management institutions as a synonym for project management, which couldn’t be further from the truth. Sadly, Scrum has become the vehicle in which PMI has co-opted and perverted Agile similar to what Six Sigma has done to Lean.

Evidence of this perversion can be seen by searching for the word “Agile” on any job board. The results will be pages of Project Management job postings. This is similar to looking for a dietician to help you lose weight and only finding pastry chefs. Misery loves company, and any people manager looking for a job has likely encountered the same frustration with the “project manager” title.

Clarifying Agile Values: Are You Doing it Wrong?

Let’s examine the four Agile values briefly (you can read them all and their accompanying principles at www.agilemanifesto.org): 

• • Individuals and interactions over processes and tools:
    If you are treating Scrum as a process for project management, you have already failed this value. You will know this is the case if you force all teams to use Scrum. Scrum is a great option, in the right situation, but a team can be agile without doing any of the practices found within the Scrum Guide.

• • Working software over comprehensive documentation:
    If you are worried about status reports, project colors, or team metrics then you likely are focused on documentation over working software. Likewise, if you still operate in a project funding model, I would bet money that you are not demonstrating this value.

• • Customer collaboration over contract negotiation:
    If you or your engineers have never spoken to your customer, or maybe they don’t even know who they are, then you cannot collaborate. If you or the business are telling your engineers to build a website, mobile app, powerapp, etc. then they are not collaborating.

• • Responding to change over following a plan:
    If you plan out your entire year, then when your actuals don’t match that plan, you try to figure out how to get back on plan instead of adjusting the plan to match the current reality, then you are more focused on following a plan than responding to change. Additionally, have you ever built something that you know is a waste of time because it’s in the project or the business asked for it?

The Great Deception Part Deux: DevOps Is Not Automation

DevOps is a movement guided by The Three Ways—maximizing flow, feedback loops, and continuous improvement. While an automated toolchain aids in achieving these ways, the essence of DevOps can be embraced without any automation. It’s similar to thinking that working in Jira makes you Agile or buying cleats makes you an athlete.

Unraveling the Myth of Cross-functional and Full-stack Teams

The concept of cross-functional and full-stack teams is very popular in the Agile and DevOps space. It aims to increase efficiency and reduce dependencies by having all of the necessary skills to develop a solution within a single team. Multiple operations engineers have claimed to have killed Agile or DevOps because they report that there is too much operational work to be consumed by a product team or that they end up being the only ones on the team to do the Ops work because developers don’t like doing those things, or even that there are cost inefficiencies with each team having their own products, licenses and subscriptions.

While the name DevOps is a union of “Dev” and “Ops” to represent bringing different capabilities together into a single team, and while doing so often results in increased flow, tighter feedback loops, and overall operational improvement, the concept of a cross-functional t-shaped team is not one of the ways, values or principles. Therefore, it is not a requirement of DevOps or Agile.

Additionally, a cross-functional team does not imply that every team member must possess all skills but rather that the team collectively possesses the necessary skill sets, with a preference towards some redundancy to reduce internal bottlenecks. Self-service tools can be leveraged to eliminate external dependencies and reduce the cognitive load of your team. No one expects your team to program the IDE they use for programming, or the OS they are working on, or administer the ALM the requirements are stored in, likewise, no one expects them to be an expert in all technology used in the creation of the product, just that they can safely and securely deploy solutions into production without a service ticket or spot on someone’s roadmap.

The End of an Era: Should We Bid Farewell to Agile and DevOps?

As the industry continually struggles to grapple with these concepts, due to leaders, project personnel, and edge-lord engineers constantly pushing processes and tools on organizations, have we come to the point of no return? Must we confront the unsettling question: Has the time come to pull the plug on Agile and DevOps? Afterall, one of the original authors of the Agile Manifesto has already declared it dead back in 2015.

Unleashing Your Inner Change Agent: Owning Our Future

Rather than abandoning Agile and DevOps due to misconceptions, we should take pride in these concepts and assume ownership. Labels may change, but the core values and principles remain valuable. And the reality is that no matter how many different names we invent for better ways of working, they will always be susceptible to being co-opted, tainted, and misrepresented. It is the responsibility of true practitioners to promote understanding, overcome challenges, and drive positive change in the industry. To finish Pragmatic Dave’s quote, “Agile is dead, but the spirit of agility lives on. Agile experts sell you the methodology, not value.”

In Conclusion

The Agile and DevOps industry is facing challenges due to misconceptions and misrepresentations. It needs passionate and responsible stewards to care for it. By understanding the core values and principles, clarifying misunderstandings, and promoting genuine practice, we can ensure the continued success and relevance of Agile and DevOps in the industry today and tomorrow. 

For more thought provoking conversations and deep dives into these values, principles, ways, and their associated practices and tools, tune in to The Agile For Agilists Podcast available on your preferred streaming provider.