The Agile Manifesto – Imagination, empathy, emotion

Ken Schwaber & Jeff Sutherland, the authors of the “Agile Scrum Guide” introduce the Agile Scrum methodology as lightweight, easy to understand and… challenging to master. How difficult could it be to master a set of basic principles contained in a few-dozen-page booklet?

Table of contents

1. What is the Agile Manifesto?
   – What are the Agile Manifesto values?
2. Agile Manifesto values explained
   – Individuals and interactions over processes and tools
   – Working software over comprehensive documentation
   – Customer collaboration over contract negotiation
   – Responding to change over following a plan
3. 12 principles of Agile Manifesto
4. Agile Manifesto – is it still relevant today?
5. Summary

The above-mentioned guide describes the roles and responsibilities of a Scrum Team in an easy, straightforward way to be understood by anyone, even if not directly involved in project management. The guide comprises a kind of “service agreement” between the Scrum team members, where everyone realizes their particular roles and duties.

However, aside from the guide, there is one more vital document that allows greater freedom of interpretation of Scrum, and which differs significantly from the more rigid and formal “traditional” waterfall methods, which is the Agile Manifesto.

What is the Agile Manifesto?

Every philosophy needs a written-down explanation of its core assumptions. Agile Manifesto is the primary source to turn to when we are lost, or we want to find out how to fix a particular problem within the framework.

Agile Manifesto has its own structure – the central part contains 4 main values that are the key to using Agile methodology with success. The Manifesto’s additional part includes 12 principles that are the more detailed guidelines for Agile software development.

The purpose of the Agile Manifesto is simple – to give every person interested in this framework a clear vision of what they should focus on and consider. They were written by software development experts that were behind the whole Agile movement. This way, we can be sure that they realistically constructed their rules to meet the requirements of the process.

What are the Agile Manifesto values?

In this article, we want to give you a clear explanation of the Agile Manifesto principles. We believe that a deeper understanding of each point will lead to more efficient software development and will help Agile beginners to get more proficiency in this framework.

The primary 4 values that are defined in Agile Manifesto are:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Now, let’s take a closer look at each of them and determine why they are so important and how to incorporate them into a software development project.

Agile Manifesto values explained

If you want to read more about Agile as a project management method – we invite you to check out our other articles on Agile software development.

You can learn how to work with the most popular Agile framework called Scrum, how to write user stories that are one of the main tools in Agile software development and what is a minimum viable product (MVP). All these concepts are essential when using Agile.

Now we can get down to business and analyze the values of the Agile Manifesto principles.

Individuals and interactions over processes and tools

According to Agile Manifesto, 10 is the maximum number of members an Agile team should have to be fully productive and ensure that communication in the team is easy, or should we say – “agile”? That’s what the Agile Scrum Guide calls it anyway.

You do not have to look too far in the literature related to team management to find out that 7 is the most common number of people recommended to be working with one manager. That number is considered the “golden middle” when striving to maintain top efficiency when delegating tasks and maintaining processes.

“In management circles, it is common knowledge that the ideal number of direct subordinates a manager should have is 7±2 (say it with me now: “seven plus or minus two!”).”

~ source: How Many People Can One Person Effectively Manage?

However, the real strength here lies not in numbers (of people in the team), but rather in the friendly and mutually helpful relations between people working in a small, non-competing group. Such a group of specialists working in close contact with each other could be compared to a group of friends-enthusiasts involved in creating their own startup.

Titles and experience, or communication barriers, have no place here, while informal discussion about problems and open communication most definitely do.

The amount of work to be done by particular people is agreed by self estimating one’s own capacity (over a cup of coffee) rather than by assignments, which gets rid of a lot of pressure associated with “delivering and exceeding KPIs” under threat of escalation.

If we add the Product Owner (usually client appointed) to the mix – a person who can perfectly fit with the Scrum team, identifies with it and becomes its integral member, then the respect for the value of individuals over the tools and processes comes naturally.

Working software over comprehensive documentation

A well-documented failure – is one of the examples of project management from the Project Manager’s angle. Even if this type of description raises some controversy, I assume that most PMs can – based of course, on their colleagues’ experience, not their own … :), recall at least one such project.

The second principle of the Agile Manifesto takes on this issue.

This approach to the matter draws more attention to the Scrum Master’s continuous dialogue with his team asking themselves: What should we do to make this work? Instead of explaining to the client why it doesn’t work.

There is one more element necessary for Agile Scrum communication to work and it’s “trust” – the word that does not often appear in business. Scrum Master, with a technical background that understands the details of the developers’ work and who is able to estimate the time for specific tasks independently, is a walking gold. However, not all companies can afford such comfort. Therefore, the issue of building openness and trust in the team is one of the key drivers in team cooperation and is what actually makes delivering working software possible.

Customer collaboration over contract negotiation

Another quite demanding principle from the Agile Manifesto to meet. Especially if we talk about budgets and multi-million software development contracts mulled over by law firms before being signed. Bringing this principle into the Agile yard, where our direct client is usually the Product Owner and an integral part of the team, is another element of everyday cooperation.

In our previous article, you can read about the role of SPOC in Agile Scrum environment.

Should you rather respond positively to the last conversation or stick to the terms of the contract? In this case, the ability to actively listen to the Scrum Master is valued much higher than the ability to read with understanding.

Responding to change over following a plan

From the Agile point of view, the change is not an element that appears in the project and needs to be managed. Change is its integral part. Such an explanation of the team’s software development processes at the very beginning of the project makes it easier to work in its further phases. It means that following a plan that is strict and unchangeable is not helpful if we want to be Agile.

Besides, Scrum Master does not manage the change but manages the emotions of the team while the changes take place. The best practitioners of the art of management know exactly how the concerns of their team members turn into the emotions of waiting for something positive that comes along with the change.

The change in Agile Scrum is a sign that our idea is starting to clear and the differences between what the client expects and what has been so far produced are decreasing. We are closer to what the project is all about.

Changes and improvements to work processes are best implemented when based on real issues and addressed quickly. Each completed Sprint is discussed at a Sprint Retrospective. Read the linked article to learn more about it.

12 principles of Agile Manifesto

Now you should understand better how Agile Manifesto values work and what you should pay attention to when creating a team for building Agile software products. Here are the 12 principles of the Agile Manifesto that will also help you to implement this methodology into your daily work.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto – is it still relevant today?

Agile as a term was invented in 2001 – which means this idea is almost 20 years old. It doesn’t seem a lot, but in the world of constantly changing and improving technology used to build software products, you might wonder – can Agile Manifesto principles still be applied to what we do at IT companies every day?

To answer this question, we need to realize that Agile is a mindset and it can become a part of any organization or process. Its rules are universal and timeless – they are based on values that can be acknowledged by any modern brand that craves efficiency, partnership and reliability.

Well-known Agile practitioners claim that they still quote the Agile Manifesto on a daily basis and they like to educate their clients about the principles at the beginning of every collaboration. 

Furthermore, there are software developers that intuitively incorporate the Agile principles into their work. The Manifesto is only a formalization of rules that are frequently a matter of instinct and common sense for many. There is no doubt that following them helps to accomplish tasks in a more productive way and respond to changes or obstacles mindfully and calmly.

The main problem when it comes to Agile is that many software houses claim that they use this methodology, but in fact, they just pick principles that are favorable for them while ignoring the rest of the philosophy. Everyone knows that Agile is flexible to some extent, but that doesn’t mean we should use only parts of it. That simply means not being Agile in a sense that would be desired by our potential clients.

If an IT company wants to be Agile, they should do it the right way and really learn this methodology’s guidelines. It’s then time to try them in project management and development to optimize the processes and get productive in the spirit of agility.

Summary

Now you really know the basics of Agile. We’ve explained the Manifesto to you with the main principles within the method. You’ve also learned why it is still used until this day and how to do it right. You might probably guess that we use it in all our projects at itCraft. Our approach to clients is vitally individual, but we always move in the realms of Agile when planning our tasks, strategizing production stages and communicating with product owners.

If you are looking for a business partner that values people and productivity, you are in the right place. Contact us and let us take care of your idea for great success.