How relevant are the Agile principles today?
An assessment of the current relevancy of the principles of the Manifesto for Agile Software Development
2001 is the official birth year of Agile. It took the world by storm. 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. Nowadays, Agile is a commodity. “Everyone” works Agile these days. Some proclaim we are in the post-Agile era. Others say Agile is dead.
These developments and claims intrigued me, so I revisited the Agile Manifesto to find my answer to the question: how relevant is Agile today? Last week, I assessed the Agile values and gave my impression on how I perceive the current state of these topics. I concluded that these values are still relevant today.
But how relevant are the 12 principles of the Agile Manifesto? This will be the topic of today’s article. These principles provide the necessary context to the Agile Manifesto. They clarify the desired behavior to work in an Agile way.
Before I address the principles, I want to broaden the scope of my assessment beyond software. Many have determined the Agile Manifesto can be applied beyond software. Agile approaches like Scrum have also broadened their scope:
“We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots.” - Scrum Guide 2020
I think this is why Agile is still part of the discussions. So, whenever the principles discuss software, I will take the product as a whole into account.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I argue this principle is central in today’s discussions involving focusing on outcomes (over output) and products people love. This is a response to the so-called feature teams, who became better and better at creating and delivering working products without checking if people liked them.
In other words: teams nailed the continuous delivery of software/products, but they failed to verify how valuable it was and how it satisfied the customer. I experienced it as one of the main gripes of people working in Agile teams that they are under constant pressure to churn out features. By doing so, teams also suffer from ignoring another principle I will discuss, about having a sustainable pace.
Moving the needle from cranking out features to continuously creating products people love is one of the main challenges of today’s product world.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Today’s world is even more volatile than in the early 2100s. It is becoming increasingly difficult to predict the future. Organizations can no longer afford to write elaborate specifications for a multi-year project to deliver products. Requirements will emerge.
This principle is even more relevant than it was in 2001.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This principle clearly shows its age. 20+ years back, delivering working products 10 times a year was considered frequent. Times have changed and we are now talking about days, hours or even continuous delivery.
That doesn’t mean this principle of delivering frequently is outdated. It is just that the frequency is higher these days.
Business people and developers must work together daily throughout the project.
Who are the business people? Are these the owners or executives? Do we include managers, finance, marketing, operations, HR, sales, risk, and security? I am going to include them all in the definition.
When we look at how Agile teams have engaged with business people, then the first person coming to mind is the Product Owner from Scrum. The Product Owner has often acted as a proxy between the business, users and the team. Teams that were lucky engaged with the business people during demos or reviews. Most teams weren’t so lucky, failing to close the value feedback loop and not knowing if their product did what the users wanted.
The product has more aspects than the software (or the core product) only. The user experience also includes sales, support, and other parts of the product. Failing to recognize this leads to silos:
To overcome this, everyone needs to be aligned, collaborate and help remove silos. This principle of the Agile Manifesto is still important.
Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.
This principle exists for an important reason: when you don’t exactly know upfront what needs to be done to create valuable products, teams need to have the freedom to find their best way. To foster the team, they need to be supported. One way to do this is to give the team a compelling purpose, blossoming the intrinsic motivation.
This is as true as it was in 2001. Highly performing teams require trust, a supportive context and coaching.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Face-to-face conversation may be the best way to convey information and collaborate. But in today’s world, this is often not possible. Many people work from home or in another part of the world.
This principle may still hold, but it doesn’t negate that virtual communication, through video calls, is an effective modern alternative.
Working software is the primary measure of progress.
The only way to understand if a product is of value to the user is to know how these users appreciate the product. Do they use it at all? How often do they use it? What parts of the product do they like? What parts do they dislike or miss?
As I stated before, this premise is coming to the forefront. Teams often used to focus on delivering features according to specifics. Delivering X features per month or delivering as promised would be the measure of success. But that is not enough. The real measure is valued working software.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
When people have to perform beyond their capabilities, they eventually make mistakes and perhaps even burn out. This is not good for these people and not an effective way to create products. It is better and economically wise to have a pace people can maintain “forever”.
But also the stakeholders and users should be able to maintain the team’s pace. When the team demands the involvement of stakeholders they can’t uphold or is overwhelming for the users.
The sustainable pace remains an important aspect of modern product creation.
Continuous attention to technical excellence and good design enhances agility.
It is far easier to build upon great quality products than upon products with technical issues. For example, when a team cuts corners and decides not to log why they made certain changes to the software, they may have trouble building on that code next time. When a team decides to skip user acceptance testing to be quicker to market, they may have to do unexpected repair work, slowing them down.
Technical excellence and good design remain a relevant principle.
Simplicity--the art of maximizing the amount of work not done--is essential.
When you don’t know upfront what exactly will bring the highest value, it doesn’t make sense to make your product overly complicated. It is far more useful to focus on the essentials, verify your assumptions, learn from these verifications and then move on. Everything you do that doesn’t help to meet your goals is wasteful.
This is another principle that is as true as it was back then.
The best architectures, requirements, and designs emerge from self-organizing teams.
This principle is very similar to the one discussing giving people trust to get the job done. Today, there’s little debate about it. Organizations may struggle with this, but there’s a general consensus that it’s best to let the teams figure out how to reach their goals by building their products.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
While every Agile approach works with retrospectives, I believe that few teams were able to reach the full potential of this practice. Often they didn’t get any further than tweaking their processes and agreements. But a retrospective has much more to offer.
Retrospectives are a great starting point to address systemic issues within the organization. The thing is though, that many organizations don’t want to change. And with that, Agile teams are bound to hit a plateau where they can’t improve their behaviours as much as organizational changes would benefit them.
I believe the retrospectives should be expanded to the organizational level and organizations should be willing to change. This is the only way to foster true agility.
As relevant as ever
The 12 principles of the Agile Manifesto are as relevant as ever. True, some of these principles seem outdated. Teams are capable of delivering more often than twenty years ago and video calls are powerful new ways to collaborate.
But when we get to the bottom of it, the principles' true meaning is still showing us what really matters to create valuable products.
I believe it is time people say goodbye to rigidly implemented standard Agile approaches and learn what is working for them. And by doing that, discover their own best way to create value. The Agile Manifesto can help you find it.
„How are the Agile principles relevant today?” might be a more generative question - and it could be extended to other domains & timeframes…
Another part where the manifesto's age shows: Today there is less talk about building projects and more about building products and creating experiences.