The Agile Manifesto Explained

The Agile Manifesto with its original and full text is available at https://agilemanifesto.org.

What is the Agile Manifesto Not?

People can quickly become overenthusiastic when they face great ideas. However, The Agile Manifesto is not some kind of religious text. There is room for dissent and debate. Time should bring fresh ideas and it is not heresy to develop alternative opinions. The Agile Manifesto is not even a definition of Agile.

Analysis of the Four Values of the Agile Manifesto

Let us read attentively the embed displayed below, sourced directly from agilemanifesto.org.

The first thing to notice is the closing sentence: “while there is value in the items on the right, we value the items on the left more“. That means agile seeks a new balance between these sometimes conflicting values, favoring those which are on the left. Favoring the values on the left is different from abandoning and despising the values on the right!

Individuals and interactions over processes and tools

To understand the importance of this value, we have to invoke the working model of traditional projects. In traditional projects functions are centralized: we need project managers, architects, business analysts, and solution designers. It is their task to shape a solution and create a work breakdown structure. Specialists work in separate groups (organizational silos) and their manager assigns them to projects. Then, the project manager assigns the tasks to the ‘resources’. Even communication is regulated and must flow through certain channels. The quality of processes and tools largely impacts the outcome.

In contrast, agile relies on cross-functional, self-organizing teams. How the work is done is up to the team members. That is why the individuals and their interactions matter more than the processes and tools. It does not mean they should keep up with poor processes and tools, though. We have to find a balance between following processes and acting as trusted individuals.

Working software over comprehensive documentation

It is genuinely difficult to determine how much documentation is enough. Bureaucratic organizations are prone to require an excessive amount of documentation to the extent that hinders the delivery process. Furthermore, the need for documentation depends on the applied practices. When individuals can frequently interact and when they continuously deliver inspectable increments, less paperwork is sufficient. As mentioned above, in a waterfall process even task assignment and monitoring are centralized, therefore project documentation on its own is heavyweight.

This value reminds us that in a software delivery process, regardless of how many hours we spend on large-scale planning activities, as long as there is no working software, our achievement is worth $0.

Customer collaboration over contract negotiation

Business is inevitably based on contracts. However, software development is a complex process and at the time the contract is signed, the overall understanding of the challenges and opportunities is low. Therefore, if the delivery process is determined by contractual terms, and based on the knowledge we had at that time, we can expect a suboptimal solution to emerge. Before the era of agile, organizations tried to solve this problem with more and more upfront planning and documentation.

With customer collaboration, we can address the problems we face and choose a solution viable for all involved parties.

Responding to change over following a plan

This value grabs the ultimate goal of agile. While following a plan, in general, may still be a great idea, the ability to respond to change makes an organization agile.

It does not mean that there is no value in planning in agile. It does not mean that constantly changing our opinions and to-do lists without considering the impacts is good.

Change may not only emerge from the environment. In the course of the development process, both technical- and business teams gain significant new knowledge of their domain and its specific problems. Upfront-crafted plans lack this knowledge, therefore accommodating change potentially has a positive impact on the outcome, even if business goals remain the same.

Analysis of the Twelve Principles of the Agile Manifesto

The first three principles describe the difference between the traditional waterfall approach and agile. Continuous delivery is key for organizational agility.

The last nine principles describe the necessary change of attitude, habits, modus operandi and conventions. Agility is not achievable only through tools and processes. In other words, practitioners have to develop an agile mindset to be successful with agile.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The first statement is a precondition of agility. Early and continuous delivery of valuable software puts the organization in a position where responding to change has a low cost which opens opportunities.

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

In a traditional “waterfall” delivery process, change is the enemy of budget and deadline and, therefore should be avoided. Change requests are regarded as a correction of an earlier mistake. This makes the delivery process very rigid and imposes a threat to the organization since the environment can dramatically change over the course of development. It cuts the organization from exploiting opportunities and even from making a solution better.

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

This principle describes an important aspect of agility. Long cadence locks in an organization’s resources for a long time, bearing a huge risk. Long cadence means late delivery of working solutions, which comes with opportunity cost. A major challenge of Agile is to shorten the cadence. However, it is not just a matter of decision, since the traditional waterfall practices would not make it viable.

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

In a waterfall model, it is typical that the developers never meet business people. Instead, project managers and business analysts do. They create documents and deliver messages while the developers have to work from specifications. If they need clarification, they reach out to their business analyst or project manager. There are multiple problems with this approach:

• Developers are not domain experts: the lack of context negatively impacts their understanding of business requirements.
• Distortion of information: messengers are prone to miss or misinterpret important pieces.
• Insufficient bandwidth, lag: if the flow of information is slow that may hinder the progress of development.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Motivation has always been in the crosshair of management studies. This principle is rather a statement against highly hierarchical organizations where people follow orders instead of goals, handled as resources instead of important contributors. Agile relies on self-organizing teams which are highly inefficient without motivation, trust, and support.

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

While this is a trivia statement for communication experts, hierarchical and bureaucratic organizations prefer written communication. In 2001 it was still the ruling model. In our days distributed teams and people working from home office impact face-to-face conversation. Therefore, it is still important to keep in mind that while written and oral communication are both important and have their advantages, we should seek ways to communicate in person. It is not only a matter of efficiency but also an opportunity to build rapport.

Working software is the primary measure of progress.

In a traditional project, the progress of delivery is monitored based on the completion of items in the work breakdown structure. However, in a traditional project, these items do not represent inspectable, working solutions. For instance, in a waterfall project only the very last phase results in software, before that, all we have is a signed-off specification, architectural design, test plan, test scenarios, unintegrated code, etc.

However, changing our approach to measuring progress is not just a theoretical problem. Claiming that the delivery percentage of a project is 75% when nothing is available yet is very different from claiming the same when 75% of the functionality is ready for inspection.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Project-based delivery often results in a struggle with deadlines. Developers must work overtime which is not sustainable in the long run. Keeping a constant pace is better for the organization and for its people, too. Agile frameworks strive to reach this goal through various techniques.

Continuous attention to technical excellence and good design enhances agility.

Accumulating technical debt slows down the progress of development. A solution with poor quality involves hidden future work. This undermines agility. Agile addresses this problem with different techniques. For instance, with the concept of the Definition of “Done”, Test-Driven Development, continuous integration or DevOps.

Simplicity–the art of maximizing the amount of work not done–is essential.

The value of simplicity is often overlooked. People tend to admire complicated and ‘complete’ solutions and anticipated future requirements. In practice, these otherwise smart considerations often overcomplicate a system which becomes difficult to maintain, understand, and develop. The value generated justifies the work done, therefore any feature, functionality, documentation, option, etc. should only be created if really need be.

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

There are arguments pros and cons. There are very good architects and software designers who can outperform an average team. However, statistically self-organizing teams have a mix of broad and deep domain knowledge resulting in a balanced, adequate performance. When architecture and design are critical, it is still considerable to form a team with a skilled architect on board, as opposed to turning to an external specialist.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

At a traditional, hierarchical organization rules are set top to bottom. This approach misses the opportunity to channel the experience of the highly skilled individuals participating in product development. 

Scrum thoroughly implements all values and principles of the Agile Manifesto.