Back to Top

Agile Manifesto's Principles Explained

agile principles

The manifesto which includes the 12 Principles of Agile Software Development has been published almost two decades ago, but all the information is still valid today. Let's go through each principle and explain it using layman's words and concepts.

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

The key words here are "highest priority" and "customer satisfaction". The team is supposed to keep the customer happy, and it can do that by providing valuable bits of software early on.

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

Changes aren't always welcome by software developers. In fact, most programmers hate changes, because they force them to rewrite code, and this is often a boring, tedious process. With Agile, change is welcome, because it helps refine the product, providing maximum value to the customer. Programmers may not be that content, but the client will be happy for sure ;)

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

Everything starts with "working software". The team is supposed to send the customer functional versions of the application, which show how various features are implemented. Shorter timescales are always preferred, because they help both parties: the customer can evaluate the product and request changes as needed, and the developers don't have to waste their time by coding unnecessary features.

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

This is crucial! Product owners (or their proxies) and developers have the shared responsibility of working together while the project is being built. This way no money and/or programming efforts are wasted.

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

So, how do you motivate individuals? By creating an environment that keeps them happy and trusting them, of course. The team should set its own, reasonable delivery plan. They should also get all the support that they need; when these things happen, the team will do a great job.

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

It is clear that face-to-face meetings are best when it comes to sharing information effectively. It's important to note that the manifesto doesn't specify how the meeting is supposed to be run, though; it simply states the efficiency of face-to-face meetings.

7. Working software is the primary measure of progress.

Very few customers can understand the amount of work that's been put behind the projects that aren't working yet. This means that delivering working software, which demonstrates that the development is progressing, should be the team's top priority.

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

Sponsors, developers and users should work at a constant pace; otherwise, the project will be delayed and may even fail.

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

Technical excellence is the result of following the best industry practices, while good design is the result of talent and hard work.

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

What kind of work we're doing without getting a straightforward benefit out of it? This should be a recurring question, because the answer will help improve the project and reduce wasted time.

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

In other words, allow the team to take care of itself if you want to get the best results.

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

With Agile, project requirements may change quite often, and the development team needs to address these changes without wasting time. Some developers may need to change their approach as the project's features are updated.