In the 20 years since the creation of the Agile Manifesto, much has been written and said about the concept of being agile.
Although to many it seems elusive and continuously changes, no business leader can hope to be successful in the current market without using “agile.”
To understand the current confusion surrounding agile, the consulting firm, Deloitte, went so far as to create an overview for people trying to find their way in “The Agile Landscape.”
The result? A “simple” 100-plus-step plan to help you become agile. Of course, there are many consultancy firms that are very happy to help you navigate this difficult terrain, because, as you can see, agile is a complicated subject matter.
Is this truly what agile is about? How did we get here?
To understand the context, let’s dive into the historical context and revisit how the authors of the Agile Manifesto thought it should be applied to projects and organizations.
Most of the Manifesto’s authors worked on various lightweight software development methodologies: Extreme Programming, Scrum, DSDM, Crystal, Adaptive Software Development, and Feature-Driven Development, and with certain concepts like design-driven development, refactoring, pragmatic programming and modeling languages.
Why were all these methodologies popping up around that time?
To better understand, it is good to be familiar with the Cynefin model. In that framework, problems or work are categorized into four domains: Simple, Complicated, Complex, and Chaos.
These domains are characterized by how easy it is to determine the relationship between cause and effect.
With simple problems, actions have a direct, predictable effect (if a lightbulb is broken, you can replace the bulb to restore light). Because this relationship is known, it is easy to set up best practices for dealing with problems in this domain, which are solved by picking the best-practice solution.
With complicated problems, actions have a predictable but separated effect (when the light doesn’t work, but the lightbulb isn’t broken, there might be a problem in the wire or the switch).
These problems are solved by domain experts who know how to analyze the problem.
With complex problems, it’s easier to explain specific actions that caused specific effects, but repeating the same action might yield different results. For example, selling a specific type of lightbulb might generate more profit one year than the other, based on external factors that are not under your control.
These types of problems are usually solved by probing the system and acting on the findings.
With chaotic problems such as emergencies and disasters, there’s no idea how some actions will turn out. These problems require transparent decision-making processes and setting up boundaries to de-escalate.
The Cynefin model further defines the disordered domain when you encounter a problem and don’t know what kind of domain it belongs to. Understanding that information is essential to determining your strategy to tackle the issue.
Using this framework, we can classify software development as a work domain.
When computers were minimal and not connected to networks, the problem of software development was mainly complicated. You needed trained experts that could analyze and predict fairly well how much work is required to make a particular system.
Over time, computers became more complex, and expectations of what software could do became higher. It became unfeasible for one person to create the software that was requested. Single programmers were replaced by teams, which created additional communication and coordination complexity.
Suddenly, the estimates that the experts were giving didn’t reflect the truth anymore.
As projects took longer to complete, the computer environments changed around them, and the requirements of the project changed. Traditional methodologies of software engineering were no longer working.
To celebrate the 20th anniversary of the Agile Manifesto, let’s go through it value by value, principle by principle, and see what it meant 20 years ago and what is still true today.
Let’s start at the beginning.
‘Manifesto for Agile Software Development’
In the title, we see that the original scope of the Agile Manifesto was software development only. While the Manifesto has exciting insights that translate to other domains, the original document should be seen in this context.
‘We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:’
The first line already shows humility by recognizing that the Manifesto is open to improvement. Uncovering better ways is an ongoing process and is never finished. The way to find better ways is through real experience. It doesn’t make sense to start telling people they have to do their work differently if you have never done this type of work.
The Agile Manifesto gets its credibility through experience, not dogmatic theoretical models. Out of this experience come some values that are central to what the signatories call “agile.”
This stands in contrast to what is happening in some companies selling agile. There is a substantial market selling agile certifications. Especially the lower tier of certifications is geared toward book knowledge. This is a real contrast to the spirit of the Manifesto, where gaining knowledge comes from actually practicing the art.
An apprentice-mentor model would be a better fit with the Agile Manifesto, but it’s a more costly approach for companies. Buying training with presentations given to groups of people is cheaper and quicker but doesn’t yield a deep understanding of agile.
‘Individuals and interactions over processes and tools’
Software is written for people by people. The quality of the result depends on the quality of your communication with your customers and within your teams. Although it is tempting to solve problems with processes and tools, carefully looking at individuals and their interactions is far more critical.
Some larger companies have difficulty putting the focus on individuals. The easier route for some of them is to take one of the “agile” frameworks and implement that instead. However, that often leads to process- and tools-driven transformation, which also goes against the original intent of the Agile Manifesto.
‘Working software over comprehensive documentation’
This value has maybe been the most successful. In the past, enormous volumes of system requirements were written and binders full of documentation. Because of the ubiquity of software systems, usability became a much more significant factor than it used to be. In the past, you could expect that only highly trained individuals would use the system, but now every individual in the Western world interacts with software hundreds of times a day.
Software should just work, it should adapt itself to human behavior, and that means that software creators need to have humans in mind when designing systems, instead of rigorous formal specifications.
‘Customer collaboration over contract negotiation’
Contracts are a form of risk management. Contracts are documents that, because of the costs to compose them, usually deal with agreements of enormous impact. In the agile mindset, the risk is better mitigated by delivering in small parts and interacting with the customer early and often.
In a changing world, the wishes of the customer also change, so sticking to past agreements might be a bad option for both parties. This practice is still tricky in markets that are regulated, although there are now new ways to specify in tenders a more general goal, instead of a checklist of specifications.
‘Responding to change over following a plan’
Plans are worthless, but planning is everything. Change is inevitable, and because we are terrible at predicting the future, the value of projects decreases over time. Plans give a false sense of control where we should be investing in a self-correcting system.
‘That is, while there is value in the items on the right, we value the items on the left more.’
Agile is pragmatic, not dogmatic. There certainly are circumstances where contracts, plans, documentation, or tools are essential. That is why agile is value-based and not rule-based. Being agile requires adaptability, but these values help you to see certain things with a different lens. It combats some of the human biases that drive us to make less effective choices.
‘Principles behind the Agile Manifesto’
‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This principle is trivial when your company creates value for single clients at a time. The difficulty arises when a company seeks to deliver value through a product. It is crucial that the end-user of the product is the person to satisfy and not the shareholders. This principle holds that software is only valuable if it meets customer demand; only then can you have a sustainable product.
‘Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.’
This principle shows that not only our world is changing, but also that of our customers. Our software is helping them to get a competitive advantage. If our software doesn’t change to the new realities of our customers, it is bringing them less value.
‘Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.’
This principle was the most controversial of the principles amongst the original authors. It is also the one that doesn’t stand the test of time that well. With the rise of continuous delivery, companies can deliver working software multiple times a day. If it takes a couple of weeks to deliver working software, it is now seen as slow.
‘Business people and developers must work together daily throughout the project.’
To avoid miscommunication and to understand the needs of the business, it is okay if developers and people from the business work together daily. This prevents promises from being made to customers based on misunderstandings and makes sure the latest information is available for developing the software.
‘Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.’
According to internal research at Google, psychological safety was the most critical factor in team success. While the world focuses on agile tips and tricks, the central message of people over process is still challenging to get right.
‘The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.’
This is still valid, although modern communication techniques like video-conferencing and shared environments have made it easier to work remotely.
‘Working software is the primary measure of progress.’
Any other proxy of the result is harmful. Measuring velocity, lines of code written, or any other derived metric will promote unwanted behavior. In my opinion, this principle can be even stronger if the value that customers perceive is the primary measure of progress.
‘Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.’
Doing death marches to finish projects in time is extremely expensive. Employers will run into burnout issues, and the negative impact on software quality will also need to be paid later on in the lifecycle of the product.
‘Continuous attention to technical excellence and good design enhances agility.’
Without constant attention to technical practices, the software will accrue technical debt, which will slow down development output to unsustainable levels.
‘Simplicity—the art of maximizing the amount of work not done—is essential.’
Every functionality put into the software incurs maintenance costs and reduces the possibilities for later development.
‘The best architectures, requirements, and designs emerge from self-organizing teams.’
Software structure reflects the organizational structure of the company building it. If we want to have robust software with components that are not strongly coupled, it is good to aim for self-organizing teams that have the mandate to change the part for which they are responsible.
‘At regular intervals, the team reflects on how to become more productive, then tunes and adjusts its behavior accordingly.’
The feedback loop is vital for learning and changing. Without any feedback, the agile movement is meaningless. Agile tries to optimize for learning quickly, but without feedback, the learning will be suboptimal at best and very likely only an inefficient way of working.
On the whole, this document has aged better than most of the software we have written. This document was written in the time that Windows XP, Myspace.com, and Napster came to be. While a few of the principles of the Manifesto show their age, their intention is still clear today.
It is an extraordinary document that, although created by very technical-oriented people, stays away from technical solutions and is more values-driven.
With the increase of development speed, new movements like the DevOps movement have added to these values to create a better way to look at software development in a broader context.
At the same time, with the success of agile, we have seen companies try to market agile as a product. I hope that the product “agile” will not supplant the agile mindset. Agile is something to be discovered by teams that need it, not something to be bought and implemented as a new operating system.
