How relevant is Agile today?
An assessment of the current relevancy of the Manifesto for Agile Software Development
Over the past 20+ years, Agile has had a deep impact on the world. Millions of professionals have found new ways of creating software (and other products) using the values and principles of the Manifesto for Agile Software Development (or Agile Manifesto).
At the height of Agile, people saw it as a panacea for all software-related, even all product-related problems. We have moved on since then and learned to appreciate Agile works best in certain contexts when many factors of the journey are unknown and it doesn’t make sense to commit to creating something of unproven value.
Nowadays, Agile is a commodity. “Everyone” works Agile these days. Some proclaim we are in the post-Agile era. Others say Agile is dead. I find these statements intriguing. So I decided to revisit the Agile Manifesto to find my answer to the question: how relevant is Agile today?
I will assess the values and principles and give my impression on how I perceive the current state of these topics. I base this on my experiences working with Agile teams, discussions with peers and articles, talks and other information.
In today’s article, my focus will be on the values. The next article will be about the principles.
The first sentence of the Agile Manifesto arguably is the most important one:
We are uncovering better ways of developing software by doing it and helping others do it
Are we? Or are we simply copy-pasting popular approaches expecting them to solve our issues? More than 80% of the companies using Agile work with Scrum. A large majority of the teams work in two-week Sprints, commit to finishing a planned set of User Stories and have issues finding stakeholders for their Sprint Review.
They did not uncover better ways to develop software. They copy-pasted the most common way of working with Scrum, regardless of whether these align with the true spirit of Scrum. When companies scale Agile, they typically use SAFe in a similarly warped way as how they came to use Scrum.
It is only a recent development in my environment to see teams finding their own best way to create software. They either start using Scrum how it fits them or experiment with other approaches, sometimes even their own unique approach.
My conclusion is that we are still very much in the uncovering phase. More than 20 years after creating the Manifesto, more and more have started looking beyond mechanical Scrum and SAFe. This point from the Manifesto is as valid as in 2001.
That said, we have come to appreciate that the software is only a part of the product. One could argue that the Agile Manifesto is too limiting these days. Focusing on software only is a sure way to create silos where collaboration only happens between the software teams and their stakeholders.
I’m one of those who argue that Agile has gone beyond software. I believe my arguments are strengthened by the fact that Scrum is an approach to creating valuable products and has gone beyond software development. I also argue that the Agile Manifesto can be applied beyond software. Having said this, the Agile Manifesto is still about software development.
Next up we have the four “values”.
Individuals and interactions over processes and tools
Processes and tools have been a thorn in the side of many teams. They typically regularly interact with their stakeholders but also suffer from company processes. The most notable examples I know are all kinds of decision boards, like the Investment Board or Change Advisory Boards (CABs).
Instead of making small investments to verify with your stakeholders if further investments may be wise, Investment Boards decide to spend millions based on year-long plans with unproven value claims. Instead of being involved from the start, the CAB decides at the latest moment if the software changes may be deployed. Processes like these kill Agility.
The same is true with enforcing the usage of tools. The most damming example is a team that could not use their preferred software language to create their products, although the language inarguably was the best choice.
There’s still a long way for many Agile teams and organizations. It is still common that processes and tolls hold them back. This value is still very relevant indeed.
Working software over comprehensive documentation
I have seen a major shift over the years. Many organizations moved away from long-term plans based on extensive analyses to create huge monoliths nobody wanted. They got better at chopping up their software into smaller pieces of functionality. Customers are more and more used to the concept of emerging products, starting small and growing to meet user needs.
Many teams can still improve. And we should also not fall into the trap of dismissing documentation altogether. But overall, I believe this value is widely understood and adopted.
Customer collaboration over contract negotiation
Numerous Agile teams have yet to engage directly with their customers, let alone interact or negotiate with them. This is especially true in mid-sized and larger companies with their roots in the 20th century. The closest they get is speaking with the sales team or customer services. Often the situation is worse: they only engage with a product manager/product owner. The regular moments of reflection, like the Sprint Reviews or Demos, only have internal stakeholders as attendees.
Another major issue is how many teams don’t receive user feedback on their product. They may receive new insights from internal stakeholders to change their priorities, but they don’t know the real value of their product.
While the need for customer collaboration is widely accepted, the reality for many teams is different. There’s still much to gain on this front to create software their users prove to love. This value remains as aspirational as it was in 2001.
Responding to change over following a plan
Most Agile teams know how to respond to change. Often they use a backlog to order their work. Whenever they gain new insights, they may add new items to the backlog, change the order or remove items. Most teams also know how to divide their work into short iterations.
That said, many teams still struggle with creating a supposed Minimum Viable Product over six months or (much) more. These teams still follow a plan but with a fancy name “building an MVP”. I know this is misusing the concept of MVP, but I have seen this a lot.
Another issue I often see is the focus on building features without looking at the desired outcome. Teams are happy when they have deployed their features according to specifications without actually understanding if users appreciate it. The lack of customer collaboration has a direct negative impact on the ability to respond to change.
For me, it is clear there’s much to improve here. This value is still meaningful. Maybe even more, considering how the world has only become more rapidly changing.
Conclusion
The values of the Agile Manifesto are as relevant as they were in 2001. My main issue is that the Agile Manifesto should cover more than software. Software developers were the pioneers in 2001. Nowadays, we have come to realize that the Agile values apply to many other areas too. That said, most organizations can still work on removing silos, seeking interaction with their users and responding to new user and market insights.
All in all, the Agile Manifesto values are still very much relevant. I have often argued that the standard approaches that defined Agile in the past 20 years aren’t always the best choice for everyone. It seems to me many organizations and teams have come to this conclusion too. That doesn’t mean Agile isn’t relevant anymore. It’s the opposite: we finally uncover OUR better ways to create products.