Agile Values and Principles (Manifesto)

In February 2001, 17 software development practitioners who named themselves “The Agile Alliance.” gathered at a resort in Utah. They came up with the “Agile Manifesto” which is a brief document built on 4 values and 12 principles for agile software development. It is this manifesto that is the foundation of modern-day agile software development. In this article let us go through the Agile Values and Principles.

4 Core Agile Values

Let us look at the core values from Agile Values and Principles.

#1. Individuals and Interactions over Processes and Tools

Let me put it this way. How important are the process and tools for you when your team is not able to communicate? It may be due to a conflict or maybe due to a lack of rapport. But, how good is a perfectly working Process and Tools in this situation.

It is not to say that process and tools are not necessary, but it comes second in priority. After all process without efficiency is frustrating. Because after all the team which has good communication and rapport can get this done more efficiently anyway. Always remember. It is the PEOPLE who are getting the work DONE

#2. Working Software Over Comprehensive Documentation

Traditional product development processes often required extensive documentation. But isn’t getting working Software into the hands of the customer of top priority? This only means that documentation is a good thing, but it should NOT be a bottleneck. I have been in many situations where a release was being delayed even though the code was ready to deploy, but the technical documentation formalities were still in progress. After all what good is “ample documentation” without working software around

#3. Customer Collaboration Over Contract Negotiation

A contract is important but is no substitute for working closely with customers to discover what they need. Under the agile philosophy, customer collaboration begins early in the development process and happens frequently throughout. Traditional product-centric processes allowed contracts to dictate what was delivered in the end. This left a lot of room for mismatched expectations. This culture of close collaboration with real customers helps product people ensure they’re delivering effective, useful solutions to customers.

#4. Responding to Change Over Following a Plan

This has more to do with mindset than anything else. The agile methodology lets a product team adjust its priorities and plans whenever doing so makes strategic sense. These teams do not get stuck in an outdated plan simply because they have committed to seeing it through Remember. Responding to a change does not mean accepting the change. But rejecting a change right away just because it is not part of the plan, is a stone-age product development mindset and does not fit into modern-day business scenarios.

Video: Agile Values and Priciples

12 Agile Principles

Let us look at the principles from Agile Values and Principles.

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

The idea here is to release early in the timeline rather than wait till the end of the lengthy release cycle. And do that continuously in short intervals

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

Now by allowing changes late in the development, we are increasing the chances of the software being relevant and competitive in the market

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

Now the more frequent your releases are, the shorter the iterations. This means that you get extensive feedback on your product in the market in short periods of time rather than waiting for eons. This again gives you a competitive advantage

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

Now often in the traditional methods, the developer is in the dark, which leads to a communication gap. This further leads to an attitude of being rigid to changes when the business pushes for them. Frequent exposure to business happenings keeps the developers up to date with information and they understand the context behind these changes.

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

The primary mission of the management in Agile is to remove any trust deficit in the team. More about this when we talk about SCRUM. This way team members can openly communicate and the commitments become more realistic.

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

Every gesture and facial expression that you give while communicating matters. Let me give you some statistics. Remote meetings generate on average 10.43 ideas, while in-person meetings generate an average of 13.36. For every dollar companies invest in travel, they receive $12.50 in value. The average company would lose 17% of its profits if it eliminated business travel. Since it is obvious, at every available opportunity try and get the meeting in person.

#7. Working software is the primary measure of progress

We spoke about the priority of working software over extensive documentation. Let us see some scenarios. Designing and releasing “Minimum Viable Features” rather than fully-developed feature sets means thinking first and foremost about the smallest things we can ship to start getting customer feedback and validate as we continue to build software. A fail-fast mentality means moving forward even in times of uncertainty and testing ideas rapidly. FAIL FAST! FAIL EARLY. Ship software often: a useful product now is better than a perfect one later

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

What they are trying to say here is to “Keep the expectations realistic”. The planning that you make before every iteration becomes crucial. The team should try not to over-commit. Protecting the team from deviations away from the goal during the iteration becomes important. Feedback must be two-way. Between the developers and the business.

#9. Continuous attention to technical excellence and good design enhances agility

The goal is to keep the work simple and not to “over-engineer”. This would mean that the team is cognizant of technical debt, every such design decision made we know the impact.

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

Simple design, simple approach means greater flexibility for future changes. This doesn’t mean that we leave room for refactoring for the future. This also means that the complexity of work taken by team iteration after iteration must be a cumulative even slope and not a jerky road.

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

In agile decisions are made as a team, unlike traditional pyramidal models. Agile has “Self-Organized” teams, where everyone gets a say in decisions. That way the risks are also minimized early on in the development lifecycle. A self-organizing team is a team where team members get to decide among themselves who does what; the team gets to work on problems and have some power to remove their own blockages.

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

The team needs to constantly adjust towards getting towards a working style or agreement where they are maximum effective. Retrospectives and Brainstorming.