Agile principles serve as the cornerstone of the Agile methodology. Learn all about them in our guide.
When old methods stop working, you start looking for an alternative. For instance, you can gather like-minded people, go to a nice place to ski and have fun, and meanwhile, discuss possible solutions. Once you find the common ground, you put your thoughts on paper and sign the document, giving it official value.
This is exactly how the Agile Manifesto was created.
And it was revolutionary. Initially developed to be applied in software development, the Agile Manifesto shifted the focus from tools to individuals, recognizing human beings as the main drivers of progress. It emphasized the importance of welcoming the change and declared flexibility and responsiveness as priorities in project management.
So let’s explore this document more closely, describing the agile principles and values.
In 2001, at Snowbird Ski Resort, Utah, a team of developers, naming themselves “The Agile Alliance,” gathered to find new ways of software development as opposed to the traditional, bureaucratic ones that were getting outdated and counter-productive.
The team consisted of 17 members who represented different software methodologies – Mike Beedle, Arie van Bennekum, Alistair Cockburn, Martin Fowler, Kent Beck, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.
After two days of discussion, they came up with the Agile Manifesto, or the Manifesto for Agile Software Development, - a document describing the principles and values that can help build a dynamic, responsive, and customer-oriented work environment in the realm of software development.
The Manifesto did not reject the old methods altogether. It was rather a compromise between the traditional and contemporary paradigms. According to the authors, they aimed not at destroying the accepted methodology but at creating a new, more credible one:
We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.
The Agile Manifesto was a breath of fresh air in software development. This new approach allowed more flexibility and freedom of self-expression and was focused on building a high-quality product over sticking to a well-known agenda.
Even though it doesn't provide a real structure and, for this reason, is not a methodology in the common meaning of this word, since 2001, the agile philosophy has been adopted by numerous development teams in the technology industry and proved to be very effective.
The Agile Manifesto consists of two main components – 12 agile principles and 4 core values, which uncover the nature of the agile philosophy. Let’s take a look at them and see what this philosophy is about.
Related: 20+ Agile Statistics - All About Agile Adoption
1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
In contrast to a predetermined communication structure between developers and customers, which assumes that they meet to discuss details at the beginning and the end of the project, the agile approach suggests an uninterrupted flow of two-way communication.
The “early and continuous delivery” of software implies that instead of sticking to a plan, you’re supposed to satisfy the customer’s requirement, which can change anytime. This means you need to report to the customer permanently, get feedback, and deliver the product that the customer desires to get.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
To survive in a highly competitive business world, you have to “sniff the change” and react to it on time. This is why the agile approach requires you to be ready to reconsider processes and implement changes at any phase of software development, even at the latest one.
While it may pose a challenge, by accepting the requirements, you will make sure that your customers will not stay one step behind their competitors.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The more frequently you deliver software, the higher the possibility you will not be asked to add, change, or delete something at the end of the project. So work in short sprints. Set short-term goals, each of which would eventually lead you to your purpose. Do not create a thorough schedule with many steps – use your time for actual work, not for the paperwork, which is often simply unnecessary.
This stands in contrast with the traditional Waterfall project management methodology where you’re expected to outline the whole work process before you start the project. It’s a rigid and time-consuming model that requires you to complete each project phase before moving to the next one, which can often mean you will not realize there is a problem until you move to the next stage.
Unlike the waterfall approach, the agile one provides more flexibility, letting you adapt the project as it progresses.
Related: Agile vs Waterfall - Know the Difference
4. Business people and developers must work together daily throughout the project.
The agile approach to developing software prioritizes collaboration, based on the principles of transparency and trust. This is made possible thanks to regular communication between customers and developers, which guarantees that everyone looks in the same direction. Two-sided feedback eliminates misunderstandings and helps create alignment.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This principle contains two ideas. Firstly, pick the right individuals for your team. Make sure you’ve got people with the right skills and motivation. As Jim Collins mentioned in his book “Good to Great,” success starts with getting the people who are committed, and only after that, you can proceed with setting a direction – not the other way around.
And secondly, create an environment where your team will be able to work to the fullest. Promote trust and respect among coworkers and provide them with all the necessary tools. Do not micromanage – give people autonomy to move to the goals by themselves. However, you must always be available in case they need guidance.
Building an agile team also requires agile resource management and capacity planning, which means you have to prioritize collaboration and be aware of how much you can deliver within a timeframe, to maintain the team's well-being.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A face-to-face conversation is objectively the best way of getting things straight, letting you quickly ask questions and get the answers, double-check, dwell on details, and get confirmations. Nowadays, when a considerable amount of work environment is remote, a concept of face-to-face conversation has evolved – you do not necessarily have to be physically in the same room, because video chats provide you with the same benefits.
Of course, emails, and especially instant texting, are of great use – however, it will take you more time to figure out all issues if you use that way of communication.
7. Working software is the primary measure of progress.
A typical mistake of many people, not just developers, is paying excessive attention to the work process instead of the actual result. No doubt, the process is important – and as we know, it’s the journey itself that brings you true pleasure, not the final destination.
Yet, from the customer's viewpoint, what matters is the final product – the software, or anything else, which they entrust you. If you’re more concerned about following the timeline and performing the tasks on it rather than about the main goal, your idea of the progress must be wrong.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Anything in this world exists in a cycle, going through periods of increase and decline. Human productivity is not an exception. Demanding high productivity from your team at all times is a no-win tactic – because sooner or later, people will burn out.
The best way to maintain a healthy work pace is to keep your team motivated, lowering the bar of expectation at the same time. Do not overburden them with work. No one shows great results under pressure. True development can sometimes be slow, but it's always steady.
9. Continuous attention to technical excellence and good design enhances agility.
Moving to your goal without making constant improvements on your way is like taking one step forward and two steps back – because you will inevitably have to revisit previous issues and correct mistakes. This will slow the work process down and make it more complicated since problems will accumulate like a snowball.
This is why it’s not enough to just create software that would work – you should create software that would be easy to change when a customer, or circumstances, require you to do so.
10. Simplicity - the art of maximizing the amount of work not done - is essential.
There is no need to overcomplicate things. The 7th principle tells us that the measure of progress is working software, not meeting the deadlines on a schedule, - and similarly, the amount of effort you put into the project is not the measure of progress, either. Again, your goal is the final result.
Besides, by complicating things without any need, you risk creating issues for yourself and ending up with a pile of work that wasn’t even planned.
11. The best architectures, requirements, and designs come from self-organizing teams.
According to Niels Phlaeging, the author of “Organize for Complexity,” there exist 3 types of organizational structures – formal (org charts,) informal (spheres of influence,) and value creation (how work is done.) Phlaeging underlined success comes from the combination of the informal and value creation structures – the traditional hierarchical org chart, still used in many companies, doesn't provide enough flexibility.
Even more, it slows things down. The Conway’s Law states that “organizations… are constrained to produce designs which are copies of the communication structures of these organizations.” In other words, communication patterns among team members directly affect the architecture they build.
And this is why self-organizing teams are important. They ensure that people do not spend time on bureaucracy – they work, and they work smoothly and collaboratively. Besides, some autonomy has a beneficial influence on motivation.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This principle is about performance evaluation. To maintain high quality and stay effective, the team must continuously make pauses and reflect on its progress. If something goes wrong, that should be corrected. This is how you improve your productivity and results.
1. Individuals and interactions over processes and tools.
The reason behind this value is the fact that people are more responsive than processes and tools. This has an important implication in the context of a constantly changing environment: while people will act more flexibly, finding solutions and learning fast, tools will stay quite rigid, not satisfying the new requirements. Therefore, people should be treated as more important.
2. Working software over comprehensive documentation.
Documentation matters – however, it is rather an auxiliary instrument than a number one priority. Technical requirements, tests, plans, and every other paper need to be approved, and this takes time, which can otherwise be used on developing and improving software.
3. Customer collaboration over contract negotiation
Instead of discussing and approving every single project detail before the work starts, the agile approach suggests collaborating with the customer throughout the whole project cycle. This will ensure continuous feedback that would put everyone on the same page.
4. Responding to change over following a plan.
The possibility of change is pretty high, so it makes sense to be ready for it rather than avoid it by all means. Changes enhance the project, not ruin it, and a failure to respond to change for the sake of following a plan may result in worse quality.
The agile principles are not just about software. The flexibility and responsiveness promoted in the Agile Manifesto can be useful in any sort of project management, as well as in everyday life. They're about creating a flow of movement that would not allow you to fall behind. And they're about valuing real people in our highly technical world.
