Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The Agile Manifesto at 20: What's still relevant—and what's not

public://pictures/joris.jpeg
Joris Slob Scrum Master, TopDesk
 

The Agile Manifesto, written 20 years ago this month, launched a revolution in the software industry—and beyond.

As initially presented, the agile concept was uncomplicated. Most of the Manifesto's authors worked on lightweight software development methodologies, such as eXtreme programming, Scrum, the Dynamic System Development Method, Crystal, adaptive software development, and specific concepts such as design-driven development, refactoring, pragmatic programming, and modeling languages.

Nonetheless, the agile concept remains elusive for some, ideas about how to achieve agile continuously change, and confusion abounds. Both outsiders and "agile consultants" offer their own versions of agile frameworks, many of which end up being overly complicated bastardizations of the concept. Agile, at times, seemed to have gone off the rails.

Still, no agile leader can achieve success without following at least some of the agile principles. Two decades in, the Manifesto's most critical statements, as articulated in February 2001, still provide value today—even if some parts of it are showing their age.

Here's how the Manifesto's four core values and 12 principles are holding up.

The Manifesto's core values

There are circumstances where contracts, plans, documentation, or tools are needed, which is why agile is value-based, not rule-based. Agile requires adaptability and seeing certain things through a different lens.

Despite ever-present change, it's somewhat surprising that the Agile Manifesto's core values have stood the test of time, even though the first and last line of the Manifesto invite us to keep challenging dogmatic thinking.

Individuals and interactions over processes and tools

In every environment where value creation requires novel approaches, this core value has only increased in importance. As technology advances, so does the power of tools, so it is tempting to follow the guidance of those tools while completely missing the interactions that would give you new insights.

Agile is sold more and more as a product, rolling out processes in a best-practice manner. But best practices work in stable, well-known domains, not where innovative work is needed.

Working software over comprehensive documentation

Because of software systems' increasing ubiquity, usability is much more critical than it used to be. In the past, only highly trained individuals would use most systems. Now everyone interacts with software hundreds of times a day.

Software should just work. It should adapt to human behavior, so developers must keep people in mind when designing systems, instead of focusing on rigorous, formal specifications.

With the rate of change required of products today, the balance keeps tipping toward things that "just work" over good explanations. This core value remains relevant.

Customer collaboration over contract negotiation

Contracts are for risk management, but, in the agile mindset, it's better to mitigate risk by interacting with the customer early and often. Through agile development, organizations can do this, proving that this statement still provides value.

That can be difficult to achieve, however, because non-agile partners often require contracts that leave little space for agility. But even government tenders for a product or service are starting to be specified in terms of customer outcomes more than with specific technical deliverables, which is a step forward.

Responding to change vs. following a plan

Planning is everything, and change is inevitable, because people are terrible at predicting the future. Plans provide a false sense of control, and change happens continuously. Even market segments once considered stable seem ripe for disruption. This value remains as vital as it was in 2001.

The 12 agile principles

While a few of the Manifesto's principles are showing their age, most still apply today.

1. Our highest priority is satisfying customers through early and continuous delivery of valuable software.

The end user, not your shareholders, is whom you need to satisfy. Here, software is valuable only if it meets customer demand; only then can you have a sustainable product. If anything, organizations have become even more customer-centric in the past 20 years.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle shows that the world and our customers are changing. However, if your software doesn't change to meet these realities, it will bring little value. This principle still holds but has proved difficult to sustain, since people cling to agreements made in the past to keep an overview of all the moving parts. Forming trust between parties has been difficult.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The most controversial of the principles among the original authors, this principle didn’t wholly stand the test of time—because development teams exceeded it.

The principle has dated itself due to the explicit statement of frequency of delivery: It references "a couple of weeks" as the shortest timescale. Now, with the rise of continuous delivery, software delivery in many organizations occurs multiple times a day.

4. Business people and developers must work together daily throughout the project.

This principle prevents promises from being made to customers based on misunderstandings and ensures that the latest information is available for developing the product. However, as global markets push software products, collaborating remains a challenge.

With the increase in communication channels available to everyone, people are experiencing information overload and want to make their intake more relevant to themselves. This has caused people to get trapped in echo chambers of like-minded people.

Exposing yourself to different ways to look at your work or company is vitally important in this time. This principle has increased in importance dramatically.

5. Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done. While people focus on agile tips and tricks, the central message of people over process still applies today—and is still just as challenging to get right.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While this principle still applies, modern communication techniques and shared collaborative work environments have made it easier to work remotely. The trend toward more remote interaction and less face time has only accelerated during the pandemic.

But is that a good thing? Most agile facilitators will tell you that face-to-face communication still has a higher chance of getting nuanced information across than do technological surrogates. But I can imagine a future when either the technology has improved or people have become adjusted enough to remote working to be able to communicate with the same fidelity as face-to-face.

 

7. Working software is the primary measure of progress.

This still holds today. Other measures, of velocity, lines of code written, or any other derived metric, just promote unwanted behavior. Businesses don’t fail because too many teams went below any other progress metric than those that really reflect customer value.

The attention for outcomes over output shows that this principle has been adopted by many companies as truth.

8. Agile processes promote sustainable development.

Sponsors, developers, and users should be able to maintain a constant pace indefinitely. This principle is of extreme importance, especially in trying times like these. Pursuing death marches to finish projects on time continues to be extremely expensive. Employers run into burnout issues, and companies pay the price for the negative impact on software quality later in the product's lifecycle.

Today, project thinking is one of the major obstacles to sustainable development. Work on software doesn't stop after project timelines are over. Movements such as #noprojects help organizations balance the needs of different parts of their portfolio in different phases of their lifecycle.

Businesses are adjusting to sustainable development, and the movement to subscription-based software makes it possible to incrementally increase value while removing some of the artificial deadlines imposed by selling fixed versions of the product.

9. Continuous attention to technical excellence and good design enhances agility.

This is a crucial practice for business agility, but it is still not observed well enough. Without constant attention to technical practices, software accrues technical debt, slowing development output to unsustainable levels.

So why do agile consultancies expend so much effort toward developing management-level frameworks while ignoring technical excellence? Inadequate attention to technical excellence is one of the biggest dangers for companies that think they have adopted agile but have failed to take this principle to heart. New businesses can grow extremely fast initially by doing so, only to slow once their software reaches critical mass.

10. Simplicity is essential.

Absolutely still relevant. Every function put into software incurs maintenance costs and reduces the possibilities for later development. Unfortunately, many companies like to invest the time they gained by using agile practices to create more features, which reduces agility. Too many organizations have fallen into this trap.

Focusing on and reinvesting in learning is the only way to keep your competitive advantage. Startups often employ this principle, at least early on.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Software structure reflects the organizational structure of the company building it. If you want to have robust software with components that are not firmly coupled, it is good to aim for self-organizing teams with the mandate to change the part for which they are responsible. This principle is still the key to doing agile at scale.

12. Regularly reflect on becoming more productive, then tune and adjust behavior accordingly.

The feedback loop is just as vital today for learning and evolving as it was when the Manifesto was published. Without feedback, the agile movement is meaningless.

The verdict

Overall, the Agile Manifesto, written in the time of Windows XP, Myspace.com, and Napster, has aged better than most of the software written in that era.

The Manifesto is an extraordinary document, created by very technical people, that stays away from technical solutions and is value-driven. Your agile framework of choice doesn't define whether you are agile, and the number of values or principles you adhere to doesn't make you agile.

In the end, it is about people helping other people. The Agile Manifesto is still the best way to figure out how to do that—until something better comes along.

Keep learning

Read more articles about: App Dev & TestingAgile