Agile Manifesto: Understanding Agile Values And Principles
Agile Manifesto Introduction:
This tutorial will go deeper into Agile and the Agile Manifesto details. We will see what the manifesto says and what the values and principles enshrined in it are.
Introduction
Earlier development methodologies took too much time. 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 needed to be improved then, was causing many problems.
When the leaders of different development methodologies met to decide on the way forward, they could agree upon a better method and finalize the wording for the manifesto. This was captured as four values and 12 principles to help the practitioners understand, refer to, and implement it. And then, 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 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.”
These are concise and simple statements that clarify what the founders wanted to promote. Usually, traditional project plans are rigid and emphasize procedures and timelines, but the agile manifesto propagates precisely the opposite.
Agile prefers:
- People
- Product
- Communication and
- Responsiveness
We will explore this new paradigm, which the founders wanted to promote in detail by understanding agile values and principles.
The 4 Agile Values
The four values and the 12 principles guide agile software delivery. We will discuss each of the values in detail now.
Individuals and Interactions over Processes and Tools
Individuals and interactions are preferred over processes and tools because they make the process more responsive. If the individuals are aligned, and once they understand each other, the team can resolve any issues with the tools or procedures.
However, if the teams insist on unthinkingly sticking to the processes, it might cause misunderstandings among the individuals and create unexpected roadblocks, resulting in project delays. That’s why it’s always preferable to interact and communicate among the team members rather than unquestioningly 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 independently will also enable them to showcase what they can bring to the table freely. The results can be powerful when these team interactions are directed toward solving a common problem.
Working Software over Comprehensive Documentation
Traditional project management involved comprehensive documentation, which entailed a lag of months. This impacted the project delivery negatively, and the resulting delays were inevitable.
The kind of documentation created for these projects was very detailed; so many documents were made that many should have been referred to during the project’s 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 that was 100% as per the specifications. That’s why the focus was on capturing all the specifications in detail.
But still, the end product used to be quite different from the expectations or would have lost relevance. That is why Agile says that working software is a much better option to gauge customer expectations than heaps of documentation.
This doesn’t imply that the documentation is not necessary. It just means that a working product is a better indicator of alignment with the customer’s 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.
Customer Collaboration Over Contract Negotiation
Negotiation means the details are still being captured and have yet to be finalized. There is still scope for renegotiation. But once the negotiation is over, there can be no discussion. What agile says is that instead of bargaining, go for collaboration.
Collaboration implies that there is still room for discussion and ongoing communication.
Not a one-time thing. This gives a two-fold advantage – while it helps the team do a course correction if required earlier, it also helps the client refine their vision and redefine their requirements during 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, they are less involved during the project development.
Once the requirements have been frozen, they see the product only once it is ready. Agile also breaks this barrier by allowing customer involvement over the whole lifecycle.
This helps the agile teams align better with 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 with clarifications and aligning the work with the customer priorities
Responding to Change Over Following a Plan
The standard thought process is that the changes are expensive, and we should avoid changes at all costs. That’s why the unnecessary focus is on documentation and elaborate plans to deliver by sticking to the timelines and product specifications.
But as experience also teaches us, changes are primarily inevitable, and instead of running from them, we should try to embrace them and plan for them.
Agile allows us to do this transition. Agile thinks that change is not an expense; it is welcome feedback that helps 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 quick feedback and shift priorities at 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 have yet to be used. This is because the waterfall model follows the plan, whereas that is the phase when we know the least.
Agile also plans and 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
After creating the manifesto, the 12 agile principles were added to help and guide teams to transition into elegance and check whether their practices align 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 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 few months, with a preference for a shorter timescale.
4) Business people and developers must work together daily throughout the project.
5) Build projects around motivated individuals. Please give them the environment and support they need and trust them to do the job.
6) A face-to-face conversation is The most efficient and effective method of conveying information to and within the development team.
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 — 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 becoming 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 valuable software. Customers will be thrilled to see working software delivered every sprint rather than going through an ambiguous waiting period at the end of which only they will get to know the product.
Here, the customer can be defined as the project sponsor or the person paying for the development. The product’s end user 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 into the overall timelines without delay.
Since the agile teams believe in quality above all things, they would instead incorporate changes and deliver as per the customer requirements rather than 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 for the shorter timescale – This is taken care of by the teams working in sprints. Since sprints are time-boxed iterations and deliver 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 made when both work 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 to 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 deliver a superior product than unhappy teams unwilling to give their best.
One of the ways to do this is to empower the development team to be self-organized and make their own decisions.
#6) A face-to-face conversation is The most efficient and effective method of conveying information to and within the development team. Communication is better and more impactful if the teams are in the exact 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 keep their pace throughout 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 — 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 becoming more effective, then tunes and adjusts its behavior accordingly. Self-improvement leads to quicker results and less rework.
Conclusion
Customer centricity and focus on communication have brought success to Agile, which is visible today.
It is a proven technique with implications not just in software delivery but in other industries, and today, it has become an industry in itself.
