(see more of our opinions on the death of Agile here)
There’s an interesting article on the “death of Agile”. With some great points. But not original.
Like many individuals in our “development” industry, they seem to be looking at Agile as a “thing”, which it isn’t. Agile is a “philosophy”, a management philosophy, and, yes, like many philosophies it has its zealots. But those of us who have been working in both the “command and control” cultures, as well as “agile” cultures for some time, have a slightly different understanding of the values of certain aspects of Agile.
I’ll try to respond with topics that I view as most important. Sorry, this may get lengthy.
Agile is an umbrella term used to identify certain values and principles critical to the way things are developed, such as customer collaboration, prioritized work, responding to change, tasks that are achievable in a short period of time, trust, team ownership and commitment, and skill mastery. Many of these have been captured in the Agile Manifesto.
Agile is actually growing
“Agile” is not dead. In fact, in my opinion, the values and principles are beginning to expand and gain favor in broader industry segments (see this article from Harvard Business Review). If we look at broader acceptance and adoption across other business segments, then Agile continues to grow in influence.
Underneath Agile are several “frameworks” that have been refined to specifically address certain work flows and domains, e.g. development, while maintaining the focus on the principles. Amongst these are Scrum, Kanban, DSDM, etc. Each of these frameworks have specific strengths and weaknesses as applied to specific problems, but that is a topic for a different day. I only mention it here because frequently people confuse “Agile” with a specific framework implementation such as Scrum.
And there are certainly processes and capabilities that need to be adopted by organizations to keep up with the rapid pace of development and deployment. But processes, frameworks, and tools can be implemented poorly. And there are terrible Scum or Kanban implementations. And these poor implementations unfortunately give a bad name to the process in general. But that blame is often misplaced. Another topic for a different discussion.
To address the specific item the author brings up: Continuous Delivery and DevOps.
DevOps, CD, and CI
DevOps is specifically an extension of the Agile principles, where we have learned that the definition of teams must include our counterparts in IT operations. Expanding this definition of team becomes inclusive of all the participants in not only “deploying” completed products but also in earlier phases where we enable the team to shorten development cycles by removing blockers early, e.g. infrastructure set up, production environments ready to receive the product, etc.
Continuous delivery is ensuring that the people, process, and technology are aligned in a manner that allows organizations to continuously “deliver” the product to a production environment. The definition of the “production environment” can vary by organization and product. Continuous delivery is a natural extension of Continuous Integration. One can work without the other, however the greatest value is achieved when both capabilities work hand in hand.
So let’s revisit the original question: Is Agile dead? IMHO absolutely not. It is a principle-based management approach that seeks team enablement to deliver the most value in the shortest period of team while eliminating waste and work that adds no value. Is it being replaced by Continuous Delivery? IMHO absolutely not. It is true that I can implement continuous delivery without Agile, however I may not be managing the overall value of the product. In other words, I can continuously deliver bad products. But the question is “is that what I should be doing?” Not in my opinion.
Are there bad implementations of one of the Agile frameworks? Absolutely. But those companies that successfully deploy Agile management principles consistently kick the tails of those that aren’t successful.
It is difficult, at least for me, to try to summarize all the learnings and evolution of how we have to come to be where we are at. So I encourage anyone reading this to reach out to me if you’d like to continue this discussion. We have really only touched upon the surface of some fairly deep management philosophies.