The 12 Principles of Agile

8 min readJul 20, 2022

Along with the 4 Values of Agile, there are 12 guiding principles.

This article is part of a series. Go to the Contents page.

It is unlikely you will know these verbatim! But it is important that you understand the following as nearly every situation or scenario will find you considering how the following apply.

Remember, when you read “software” think “solution”.

For each, I will pull out the important points to bear in mind when “Being Agile”, but as a version to pin to the wall, they can be summarised as:

The “Agile Principles Sentence”

Before listing, here’s a what I call the “Agile Principles Sentence”. A 12 word sentence, with 4 x 3 word cadence to be memorable, as a prompt for all twelve:

Satisfy change frequently, together motivate face-to-face, working sustainable excellence and simple self-organise reflection.

It doesn’t make much sense, and not exactly 12 words, but it’s a good aide-memoire! If you can remember it, you will be able to at least recall the essence of the principles. Here’s the breakdown (after which I will summarise each in more detail).

Satisfy the customer with early and continuous delivery.
Embrace change.
Frequently delivery.
Everyone works together.
Motivate people.
“Low tech — high touch”. Face-to-face with a whiteboard is best.
Success is primarily measured by working solutions.
Work in a sustainable fashion.
Focus on excellence.
Simplicity — the art of maximizing the amount of work not done — is essential.
Let teams self-organise.
Regular reflection and adjustment.

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

We focus on the customer, and we focus on satisfying the customer. If you remember one thing, remember this.

We structure the project such that we deliver early, and we deliver frequently. Engaging with the customer is so important, even if uncomfortable at times. It is always better to engage early, whether it is good or bad news.

Delivering working software (working solution…) is what we want to share, not documentation or plans. The customer is buying working software (solution), the documentation, the plans, the WBS items… these all enable the working solution. Presenting an accurate plan cannot compare to presenting working software.

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

Traditionally, change was considered negative. We describe them as scope creep. Needing strict change control mechanisms. To change in-scope and out-of-scope. A significant amount of time and effort can occur managing change requests.

Instead, Agile welcomes change. Scrum (one of the Agile frameworks) for example, has a light-weight and highly visible approaching for managing and prioritising change (through the use of a Product Backlog).

By accepting that change will happen, and having an efficient way to handle them, the team can focus on delivery. Rather than suppressing change, Agile keeps the project adaptive and flexible as long as possible.

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

It is only natural to make the perfect “thing” before sharing. But if we can share what we have done so far, get feedback, to then change or improve — then all the better. So we want feedback early and often.

Conversely, it also keeps the stakeholders engaged. Losing momentum can be a real detriment to deliver, along with losing interest. Regular opportunities for feedback helps to address these potential impediments.

Having a schedule of frequent review of work, to get feedback is important. Breaking down work, therefore, into deliverable “chunks” helps tremendously.

Scrum, for example, has iterations — which has a review process at the end to discuss with the stakeholders how things are going.

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

Documents, emails and telephone calls are always appropriate at times, but nothing beats face-to-face engagement.

Daily stand-ups are a great example of how a team can ensure that at least once a day they can share progress with each other, and maximise the value of their on-going work.

Remember that the team may not just be developers, but also represent other parts of the business. This way, all have that daily touch-point, which also supports the momentum and interest level mentioned in #3.

It is not always possible for all to be involved daily. Some will use “proxy” representatives (not ideal), others may schedule an update with those that cannot attend every 2–3 days, or once a week for example.

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

A motivated team can be one of the most significant success factors of a project. Whilst it’s not always possible to hand-pick teams, for those on the team we want to get the most out of them.

Appreciate their personal goals and see if you can align then with the project and business goals. Let them organise work as they want to, to achieve most value.

Recognise that the team members are in all likelihood the experts. Let them do what they do, and support them in doing so to maximise success.

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

As mentioned, documents, emails, telephone/video calls — they all have their place. But nothing beats face-to-face conversation. Communication is mostly non-verbal. There have been a number of studies on the complex topic of nonverbal communication with varying results. However, most experts agree that 70 to 93 percent of all communication is nonverbal. Some examples for further reading: [1], [2], [3].

So whilst Agile practices often have to adapt to context, this principle should be followed when possible. And as teams grow, we introduce an appropriate level of written documentation.

7. Working software is the primary measure of progress.

Remember, when you read “software”, think “solution”.

How many times have you heard “we’ve been really busy doing things”. When nothing has been “done”. So Agile promotes the idea of delivering working solutions, over the supporting work that has to be done to deliver it.

Design documents, meetings, documentation — these are all supporting activities. But the customer does not want these. They might need them, but they want working software. So this is the focus.

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

“I worked all weekend”. “I was up early to get it done”. “My family misses me”.

Ring a bell? Traditional IT environments almost expected manic period of time. And occasionally you have to got above and beyond.

But this is not sustainable. People burn out. They leave. So instead, we want a sustainable amount of momentum. A pace that is steady is much more preferable to peaks and troughs. Peaks can become expected, which will only end badly.

Over-worked staff, and under-worked staff, lose momentum and can lose interest. They stop caring, which impacts on quality (reference to #9). So keep the level of work at a suitable level to maximise value over a longer period of time.

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

Complicated code (or anything complicated) may deliver the first time, but ultimately it becomes difficult to maintain to to adjust.

Instead we want to be agile — we want to be able to understand and adapt code, designs, etc, easily.

So give the team time to refactor — to consider how code (etc) can be improved and maintained as a quality product. Refactoring can be housekeeping, cleaning up, simplifying and so on, to ensure things (like code) remains stable and maintainable.

It will also minimise the work required to re-use work (such as code) over the long term. Which leads nicely on to…

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

What can go wrong with something you don’t do? Nothing!

It is claimed that over half of software developed is not used, or rarely used. For example, the following was presented by Jim Johnson in a keynote presentation:

So in Agile, we want to find the simplest solution that would work and not over complicate things. KISS — Keep It Simple Stupid is a often used phrase! And applies nicely to Agile. I have my own variation, Keep It Simple Simon!

Start with what is needed, the Minimal Viable Product. Review with the stakeholders and discuss what the next priority is. Don’t build the Titanic when a Tug Boat would do fine.

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

We covered this previously in #5.

Let the team understand the requirements, let them learn from others, and let them organise themselves to deliver it.

Give them the freedom to organise themselves in the most efficient manner to deliver value, rather than force them into a way of working.

Another way to see the importance of this principle is to see that ideas that are generated by the team, do not need to be sold to the team. This will engender a sprit of ownership.

Recognise that the team members are the most informed about a project, and value them.

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

How many traditional projects hold “lessons learned” (if at all)? They are often held as an event “because we should”. Usually at the end of the project, and can be a significant amount of time after.

Do people remember everything that happened during the project?
Do they care?
Are lessons learned taken away and implemented?

This principle encourages regular and frequent reviews of “how” the team worked (not what they were working on). In Scrum, this occurs at the end of each Sprint for example as the Retrospective.

By reviewing regularly, it is timely, relevant to the project in hand, and can be acted on immediately. How did we work well, that we can re-enforce? How could we improve how we worked? Is there anything was can add/remove/start/stop?

Tip: Allow people to record topics to discuss between the times they reflect (like the Scrum Sprint Retrospectives), or encourage them to maintain a note to bring along. This will avoid having to recall topics from memory.

Summing Up

You don’t need to remember the principles word-for-word. They are principles, not dictates. But by remember the “Agile Principles Sentence” you will be able to constantly consider how you can apply the principles.