The 12 Agile Principles: What Are They and Do They Still Matter?

In 2001, the Agile Manifesto surfaced. It wanted to change the software development process. The manifesto has four central themes, but not many people know that there are also 12 Agile Principles. These offer more concrete examples of how agile software development should take place. Many years later, almost every organization will say they “do agile” but many only provide lip service to the values and principles of the Agile Manifesto. The world of software development has also changed drastically. It’s interesting to revisit the agile principles, see what they mean, and assess whether they still matter.

Early and Continuous Delivery of Valuable Software

As the first principle says, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

We usually develop software on someone else’s time and money to help them in some way. If we wait too long to deliver the product, it will probably not satisfy the customer. This is even truer now than it was in 2001. Not only is it valuable to have early feedback and to have it continuously throughout the project, customers expect fast delivery. And each delivery should add something of value for the customer. For example, the customer doesn’t care that you refactored the login page. She does care that it now allows her to log in with her Google account.

Users are using more and more software for all kinds of tasks. And they are used to frequent updates. So when they ask us for changes, they won’t be willing to wait for months before they see them.

Embrace Change

The second principle states, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

In a world that’s constantly changing at a rapid pace, nobody can really predict what the requirements of a piece of software will be. Yet businesses don’t like surprises. But what they like even less is wasting money on a product that’s no longer relevant. If we welcome change, the software could provide the customer with a competitive advantage because it satisfies the current and latest needs, not those of last year.

The fact that the world is constantly changing has been true for decades. Society changes, the market changes, our organizations change, and people change. Instead of trying to stop or slow down this process, we should embrace it and use it to our or our customer’s advantage.

Frequent Delivery

The next principle is to “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

This principle actually seems like a repetition of the first one and, in a way, it is. However, the first principle points out that we should start delivering valuable software early. This principle goes a little bit more into detail about what delivering continuously means. It recommends delivering a new version of your software within a short timescale. This means smaller releases, and smaller releases mean fewer chances of bugs getting through. More frequent releases also provide more moments of feedback from the client. If you only get feedback about all your changes after several months, you’ll have much more work that can accommodate any remarks.

This is a principle that’s become more radical over the years. We no longer regard a release cycle of “a couple of months” as agile. The industry has evolved to daily or weekly releases.

Business and Developers Together

Another principle states, “Business people and developers must work together daily throughout the project.”

Developers are often shielded off from business people. Analysts are put between them to “translate” the business language to a language that developers can understand. This agile principle calls upon organizations to remove these barriers and let developers and the business interact with each other daily. This increases mutual understanding and respect.

If you’ve ever played the telephone game as a child, you know that each extra step in communication leads to lost information. Having the business and developers work closely together reduces (but doesn’t eliminate) this risk. Even in the modern world of distributed teams, we should try to work together closely on a daily basis. Catching misunderstandings early and getting regular feedback from each other helps in producing successful outcomes.

Motivated Individuals

There’s also “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

An agile team is a team that’s mature and responsible enough to produce quality software. This requires a certain amount of trust. But if you can’t trust your developers, why were they hired? With the correct coaching, environment, and tools, motivated developers will feel enabled to do their work professionally.

If you build your projects around people that aren’t motivated or have been demotivated due to a lack of trust or support, your project isn’t likely to succeed. Even worse, smart developers will have no trouble finding better jobs.

Face-to-Face Conversation

And there’s also the principle that states, “The most efficient and effective method of information to and within a development is face-to-face conversation.”

Technology has increased the number of ways in which humans can communicate. But none of these are as good as a face-to-face talk. Our brains interpret all kinds of signals, not just the sound waves of our voices. Facial expression and body language matter too. It isn’t uncommon for asynchronous communication to cause misunderstandings.

The following diagram, from Alistair Cockburn’s book “Agile Software Development,” shows us how effective different forms of communication are:

Since 2001, the way we work has changed drastically. Many organizations have people that work remotely, even in other time zones. Technologies like issue trackers and Slack create ways of communicating asynchronously and tools like Skype and Hangouts allow us to have remote face-to-face talks. It will never be 100% like real-life interaction, but maybe it’s good enough. Teams across the globe are proving that they can still be successful and agile without seeing each other in real life.

Working Software

One of the principles says, “Working software is the primary measure of progress.”

Software projects can take a long time. So it’s absolutely rational for businesses to measure progress. This agile principle states that the primary way of measuring progress is working software. Finished analysis, complete models, or beautiful mock-ups have little meaning if they aren’t converted into working software. They may be necessary, but if you haven’t put at least a small portion of that into a working product, then you haven’t created value for your customer.

Today, we often go a step further. If the working software hasn’t been shipped, it’s not finished and so no progress has been made. Unreleased software is inventory. And inventory is a cost, not a piece of income or value.

Sustainable Development

The eighth principle goes as follows: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

So, what does that mean exactly? To me, it means people should work in an environment where they experience pressures that they can handle forever. Pressure comes in different shapes and forms. Think about things like budget, deadlines, company politics, and respect among colleagues. 

Each of these things can be either a source of stress and cause people to walk away, or they can be things that are present but not a concern.

Here’s the thing. It doesn’t mean that an Agile organization can’t have any of these issues going on. It does mean that they can’t be happening all the time. For example, an Agile team can handle an intense period of high-paced work. But they should have a rest period after that. If the organization is always stressing the team to its limit, it isn’t sustainable—the team can’t maintain such a pace forever.

Notice how the principle mentions “sponsors, developers, and users.” So everyone should be able to maintain the current pace of development. For example, if developers are cranking out features too fast for users, then the developers should adapt. One way to do this would be to slow down. Another would be to invest more time in documentation and educating users about the new features.

The core idea of this principle is that everyone involved can keep up with the pace at which the software is being developed.

Technical Excellence

There’s another saying, “Continuous attention to technical excellence and good design enhances agility.”

Many businesses prefer time-to-market over good technical design. And in all fairness, they can’t be blamed. We just mentioned that unreleased software is a cost. The end-user doesn’t care about technical excellence and it doesn’t create income for the business.

But if teams neglect a good technical design for too long, their speed and time-to-market will start to slow down. Their ability to change the product as a reaction to a changing market will diminish. They’re losing their agility.

This principle is still very relevant. In my experience, both managers and developers aren’t aware (enough) of this principle. In small projects, it may make sense to work fast without an eye for good design. But if the project is big enough, it pays off to pay attention to the technical quality. Martin Fowler created a pseudo-graph to visualize this:

This doesn’t mean we need big theoretical designs before starting to code. Good designs can emerge as the software evolves. But developers need to get the time and be responsible enough to do so.

Simplicity

“Simplicity—the art of maximizing the amount of work not done—is essential,” is yet another principle.

Maximizing the amount of work not done can be done in several places: you can remove procedures that are no longer relevant, automate manual work, use existing libraries instead of writing your own, etc. It all saves time and money, giving us room to focus on delivering more value.

This is an ongoing effort for all organizations. But it requires some work to identify where and how we can improve.

Self-Organizing Teams

One of the last principles is that “The best architectures, requirements, and designs emerge from self-organizing teams.”

This principle is a combination of some previous principles. If we want the business and developers to communicate with each other regularly and effectively, if we want to measure progress by working software and not theoretical models, and if we work with motivated individuals, then we should have teams producing quality software without too much control from above.

Teams should learn to self-organize all aspects of software development: they should gather requirements by communicating with the business, write quality software, organize their work, etc. This leads to better software because the developers will start to “own” the software.

Developers are still regarded as factory-line workers that can be fed requirements. But software development is work that requires much more. The team needs to be allowed to organize itself to deliver.

The other side of the story is that agile software developers should take on this responsibility. An agile team requires developers taking on responsibilities beyond just writing code.

Regular Reflection and Adjustment

Finally, there’s the last principle that says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

At regular intervals, self-organizing teams should take the time to look at the way they work and adjust accordingly. No team runs perfectly. A mature agile team can identify issues with respect for each other and then take action to improve the process.

This principle will always matter. It’s what makes individuals, teams, and the business successful by not accepting the status-quo but always looking to improve the situation.

They All Still Matter

You may notice that all the agile principles are still relevant today. That’s because they’re based on economic reality and human nature, two things that don’t really change that much. If anything, some principles have become more radical than they were intended to be. For example, we should deploy weekly or even daily and we can now automate more than we imagined in 2001. On the other hand, some principles have been given a different meaning than we imagined in 2001: individuals no longer need to be in the same room for effective communication for example.