Agile Manifesto: Understanding Agile Values and Principles

Agile Manifesto Introduction:

Our previous tutorial on Agile Methodology explained us all about Agile models and methodologies in detail.

But until now we aren’t about why there was a need for agile in the first place and how agile overcame the shortcomings of the existing software development methodologies like the waterfall model.

In this tutorial, we will go deeper into the details of agile and the agile manifesto. We will see what the manifesto says and what are the values and principles enshrined in it.

agile manifesto

Introduction

As we saw in our previous tutorial, earlier development methodologies took too much time and by the time the software was ready for deployment, the business requirements would have changed thus not catering to the current needs.

The speed of change which was lacking at that time was causing a lot of problems. When the leaders of different development methodologies met to decide on the way forward, and they were able to agree upon a better method and also were able to finalize the wording for the manifesto.

This was captured as 4 values and 12 principles in order to help the practitioners understand, refer to it and put it into practice. And at that point in time, none of them could have imagined the impact that this would have on the future of project management.

Agile Manifesto

The manifesto has been very carefully worded to capture the essence of agile in minimum words and it reads as below –

“We are uncovering better ways of developing a software by doing it and helping others to do it. Through this work we have come to the below value:

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

That is, while there is value in the items on the right, we value the items on the left more.”

As we can see, these are pretty concise and simple statements and make it very clear as what the founders wanted to promote. Usually, traditional project plans are rigid and they emphasize on procedures and timelines, but the agile manifesto propagates exactly the opposite things.

It prefers:

  • People
  • Product
  • Communication and
  • Responsiveness

We will explore this new paradigm which the founders wanted to promote in detail by getting a deeper understanding of the agile values and principles.

The 4 Agile Values

The four values along with the 12 principles guide the agile software delivery. We will discuss each of the values in detail now.

Agile values

#1) Individuals and Interactions over Processes and Tools

Individuals and interactions are preferred over processes and tools because it makes the process more responsive. If the individuals are aligned and once they understand each other, then the team can resolve any issues with the tools or processes.

But if the teams insist on blindly sticking to the processes then it might cause misunderstandings among the individuals and create unexpected roadblocks thereby resulting in project delays.

That’s why it’s always preferable to have interactions and communication amongst the team members rather than blindly depending on processes to guide the way forward. One of the ways to achieve this is by having an involved product owner who works and can make decisions in collaboration with the development team.

Allowing individuals to contribute on their own also allows them to showcase freely as what they can bring to the table. When these team interactions are directed towards solving a common problem, the results can be quite powerful.

#2) Working Software over Comprehensive Documentation

Traditional project management involved comprehensive documentation which entailed a lag of months. This used to impact the project delivery negatively and the resulting delays were inevitable.

The kind of documentation created for these projects was very detailed and so many documents were created that many of them were not even referred to during the project progress. This was an unnecessary evil with which the project teams used to live with.

But this also exacerbated the problems in delivery. The focus was on documentation to such an extent because the teams wanted to end up with a finished product which was 100% as per the specifications. That’s why the focus was on capturing all the specifications in details.

But still, the end product used to be quite different from the expectations or would have lost relevance. That’s is why agile says that a working software is a much better option to gauge customer expectation than heaps of documentation.

This doesn’t imply that the documentation is not necessary. It just means that a working product is any day a better indicator of alignment to the customer needs and expectations than a document created months ago. It also implies that the teams are responsive and ready to adapt to change as and when required while showing the working software to the client when the sprint ends.

Failure to test the product during sprints takes manifold cost and effort in the next sprint. Once the functionality is deployed, the cost of these changes goes up further by a significant degree.

3. Customer Collaboration Over Contract Negotiation

Negotiation means that the details are still being captured and have not been finalized. There is still scope for renegotiation. But once the negotiation is over, there can be no discussion over it. What agile says is that instead of negotiation, go for collaboration.

Collaboration implies that there is still room for discussion and the communication is ongoing.

Not a one-time thing. What this does is, it gives a two-fold advantage – while it helps the team to do a course correction if required at an earlier stage, it helps the client to also refine their vision and redefine their requirements if required during the course of the project.

The other aspect is that while traditional software development models involve the customer before the development begins during the documentation and negotiation phase, and they are not as involved during the project development.

Once the requirements have been frozen, they get to see the product only, once the product is ready. Agile breaks through this barrier as well by allowing for customer involvement over the whole lifecycle.

This helps the agile teams align better to the customer needs. One of the ways to achieve this is through a dedicated and involved product owner who can help the team in real time for clarifications and aligning the work with the customer priorities

4. Responding to Change Over Following a Plan

The standard thought process is that the changes are an expensive affair and we should avoid changes at all costs. That’s what the unnecessary focus is on documentation and elaborate plans to deliver by sticking onto the timelines and product specifications.

But as experience also teaches us, changes are mostly inevitable and instead of running from it we should try to embrace it and plan for it.

Agile allows us to do this transition. What agile thinks is that change is not an expense, it is a welcome feedback which helps to improve the project. It is not to be avoided but instead, it adds value.

With the short sprints proposed by agile, the teams can get a quick feedback and shift priorities at a short notice. New features can be added from iteration to iteration.

Why do we do this? Because most of the features developed using the waterfall approach are never used. This is because the waterfall model follows the plan whereas that is the phase when we know the least.

Agile also plans, but it also follows the just in time approach where planning is done just enough when needed. And the plans are always open to change as the sprints progress.

The 12 Agile Principles

There are 12 agile principles which were added after the creation of the manifesto in order to help and guide teams transition into agile and check whether the practices they are following are in line with the agile culture.

Following is the text of the original 12 principles, published in 2001 by the Agile Alliance:

#1) Our highest priority is to satisfy the customer through the early and continuous delivery of a 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 the development team is a 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 much 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.

These agile principles provide practical guidance for the development teams.

Another way of organizing the 12 principles is to consider them in the following four distinct groups:

  • Customer satisfaction
  • Quality
  • Teamwork
  • Project management

#1) Our highest priority is to satisfy the customer through early and continuous delivery of a valuable software – Customers are obviously going to be thrilled to see a working software being delivered every sprint rather than having to go through an ambiguous waiting period at the end of which only they will get to see the product.

Here the customer can be defined as the project sponsor or the person who is paying for the development. The end user of the product is also a customer but we can differentiate between the two as the end user is referred to as a user.

#2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage – Changes can be incorporated without much delays in the overall timelines.

Since the agile teams believe in quality above all things, they would rather incorporate changes and deliver as per the customer requirements than to avoid changes and deliver a product that does not serve the business needs.

#3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale – This is taken care of by the teams working in sprints. Since sprints are time-boxed iterations and deliver a working software at the end of each sprint, customers regularly get an idea of the progress

#4) Business people and developers must work together daily throughout the project – Better decisions are taken when both are working together collaboratively and there is a constant feedback loop between the two for course correction and change agility. Communication among the stakeholders is always the key in agile.

#5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done – You have to support, trust and motivate the teams. A motivated team is more likely to be successful and will deliver a superior product than unhappy teams who are not willing to give their best.

One of the ways to do this is to empower the development team to be self-organized and take their own decisions.

#6) The most efficient and effective method of conveying information to and within the development team is a face-to-face conversation – Communication is better and more impactful if the teams are in the same location and can meet face to face for discussions. It helps to build trust and brings understanding among various stakeholders.

#7) Working software is the primary measure of progress – A working software beats all the other KPIs and is the best indicator of the work done.

#8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely – Consistency of delivery is emphasized. The team should be able to maintain their pace over the duration of the project and not burn out after the first few sprints.

#9) Continuous attention to technical excellence and good design enhances agility – The team should have all the skills and a good product design to handle the changes and produce a high-quality product while being able to incorporate changes

#10) Simplicity — The art of maximizing the amount of work not done is essential and is just enough to meet the definition of done.

#11) The best architectures, requirements, and designs emerge from self-organizing teams – Self-organized teams are empowered and take ownership of their work. This leads to open communication and regular sharing of ideas among the team members.

#12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly – Self-improvement leads to quicker results and lesser rework.

Conclusion

The customer centricity and focus on communication have brought success to agile that is visible today.

It is a proven technique with implications not just in software delivery but other industries as well and today it has become an industry in itself.

Our upcoming tutorial in this series will explain more about the Scrum Team along with their roles!!

PREV Tutorial | NEXT Tutorial