Agile Principles: The 12 Keys to Adaptive Project Management

Adaptive project management – otherwise known as Agile… If you are going to understand it, go back to the very start. First, there was the Agile Manifesto: a statement of intent and a set of four beliefs. Then came the 12 Agile Principles.

And it’s those Agile Principles that tell us what Agile really is, and how to make adaptive project management work.

So, in this article, let’s look at the 12 Agile Principles and see how they guide us. And we’ll also test these principles of adaptive project against wider principles of good project management.

The Questions We’ll Answer in this Article

It’s tempting to dive straight into the 12 principles of Agile project management. But we need to set some context first. If you know that context, you can use the links below to jump ahead. But here are the five questions I’ll answer:

• What is Agile Project Management?
• Why has Agile Project Management become so Important?
• How did Agile Project Project Management Start?
• What are the 12 Agile Principles?
• How do the Agile Principles Relate to its Tools and Techniques?

What is Agile Project Management?

Agile is a way of thinking about delivering new products. Therefore, there are a number of Project management methodologies that we can describe as ‘agile’. But, a better description might be ‘adaptive’.

Agile methods adapt to business ad customer needs and, in particular, to how they evolve over time. Embedded in the agile approach is incremental development and iterative refinement. So, agile project management avoids a rigid plan and a strong emphasis on cost and schedule management.

The Agile Alliance has a nice definition:

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

Agile Alliance: What is Agile?

So, agile is best suited to projects where there is a high level of uncertainty. Because agile approaches seem to foster greater degrees of creativity and innovation.

More traditional. planned project management approaches thrive where we see higher levels of familiarity and certainty. There, definition, planning, and active cost and schedule management are the best way to achieve control and predictability.

For more on the differences and applicability of adaptive (agile) and predictive (traditional or ‘waterfall’) project management, see our article, ‘Agile vs Waterfall: Which one is Right for Your Project?’

Why has Agile Project Management become so Important?

As I said above, Agile is best suited to conditions of high uncertainty. And today’s world has much higher levels of uncertainty, ambiguity, and complexity.

This all demands greater flexibility and adaptability. Agile approaches offer this. Indeed, with the rise of software-based internet start-ups, we’ve seen agile development at the heart of the birth and growth of vast new businesses where the founders could never have expected to accurately predict the needs and wants of their customers.

So, agile allows us to adapt to a growing understanding of what our clients need – and their evolving requirements too. And it does this with less need for re-work.

But crucially, agilists claim that it places a greater emphasis on the end-user or customer than traditional approaches. I’d rebut this and suggest that traditional project managers, when we do our jobs well, give equal weight to their customers’ needs and desires. The difference for me is the ability to react quickly and cheaply when they change… to be agile.

How did Agile Project Project Management Start?

This question is important. Because the 12 Agile Principles appeared early on and are part of the origin story of Agile Project Management.

In the early 1990s, software development was going through what some commentators called the ‘application development crisis’. In truth, this was a recognition of a lag in the delivery of new applications. It was taking too long to bring them into operation. Some experts estimated that the time between an organization recognizing a need and it having a working production version of the application to be around three years.

I remember my software engineering colleagues talking about RAD: Rapid Application Development, in the mid 1990s. This was just one of many software development methods that engineers created, to speed up the creation of new software. Here’s a partial list:

• Rapid Application Development (RAD)
• Rational Unified Process (RUP)
• Crystal
• eXtreme Programming (XP)
• Dynamic Systems Development Method (DSDM
• Scrum
• Feature Driven Development (FDD)

17 People…

In 2001, seventeen software developers met to discuss these lightweight software development methods: 

1. Kent Beck
2. Mike Beedle
3. Arie van Bennekum
4. Alistair Cockburn
5. Ward Cunningham
6. Martin Fowler
7. James Grenning
8. Jim Highsmith
9. Andrew Hunt
10. Ron Jeffries
11. Jon Kern
12. Brian Marick
13. Robert C. Martin
14. Steve Mellor
15. Ken Schwaber
16. Jeff Sutherland
17. Dave Thomas

As a result of the meeting, they published the Manifesto for Agile Software Development.

The Agile Manifesto

This is the manifesto they put out:

I have discussed an interpretation of each bullet point in our article, ‘Agile vs Waterfall: Which one is Right for Your Project?’

A few years later, in 2005, two of these people gathered another group to articulate 12 Principles behind the Agile Manifesto.

What are the 12 Agile Principles?

Here are the 12 Agile Principles, which underpin the Agile Manifesto, as articulated at AgileManifesto.org:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

We’ll examine each of these agile principles in turn, to understand what it means and how it fits into the wider Project Management concept.

Customer Satisfaction First

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

Principles behind the Agile Manifesto

Customers and users want their software now. Or, realistically, as soon as possible. So, agile methods need to implement processes that optimize for speed of delivery. If that’s what customers want, that’s what they should get.

But I disagree with the implication that early and continuous delivery is what customers always want above all else. For me, I’d prefer the focus on the first 8 words: ‘Our highest priority is to satisfy the customer’. Too many agilists focus on speed of delivery.

Two principles in here do seem to be near-universal:

1. Focus on delivering value
2. Putting customers/stakeholders first

Welcome Changing Requirements

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

Principles behind the Agile Manifesto

There are two important aspects to this agile principle. The first is the recognition that, in a volatile, uncertain, complex, and ambiguous (VUCA) world, what it takes to drive competitive advantage can shift – perhaps often – during the development cycle. And this recognizes a quantitative growth in the rate of change over the last 30 to 40 years.

But that is just a matter f degree. The more imortant aspect is the way Agile methods build an accommodation of changing requirements into the heart of their processes. This is different from the way most traditional project processes adopt Change Control as a ‘bolt-on’ process.

The ability to adapt and respond to change has always been a fundamental principle of Project Management. But I do think it is more important now, and the Agile principles have rightly brought it to the fore. I expect it to feature prominently in the new PMBOK Guide 7th Edition.

Frequent Delivery

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

Principles behind the Agile Manifesto

Frequent increments mean rapid feedback, which means quick remediation and minimal re-work. This is a sound principle in life. And industry seems to have taken this to heart. Iteration or ‘sprint’ periods are reducing and weekly releases are no longer a rarity.

PRINCE2 – that bastion of predictive PM – has as its second principle, ‘Learn from Experience’. Rapid turnaround gives an opportunity for more and faster learning.

However, it’s easy to caricature this principle as antithetical to traditional PM thinking. It’s not. Back in the mid-1990s, I was delivering projects with frequent drops of deliverables. And I was training new project managers to do the same.

Business and Development Working Together

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

Principles behind the Agile Manifesto

Isn’t this one obvious? Well, it is. But in traditional highly-scoped and planned software projects, software engineers and business people rarely if ever spoke to one-another. They didn’t speak the same languages. So businesses, consultancies, and developers employed translaters called Business Analysts, who spoke enough ‘business-speak’ to gather requirements accurately, and enough ‘system-speak’ to translate those into technical language.

Here’s a second principle of agile development that emphasizes good communication and stakeholder engagement. And many project managers applied this principle long before the Agile Manifesto.

Motivated Individuals at the Heart of Projects

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

Principles behind the Agile Manifesto

It seems to me that this principle was probably driven by some bad experiences. You wouldn’t think you’d need to state this. But, as a foundational principle, it has to be sound. How could it not be?

But, as well as advocating for managing morale and providing resources, it also says to me that we need to recruit people who want to be there. It reminds me of the familiar advice to:

Hire for attitude: train for skills.

One of the things that can easily demotivate is uncertainty about what others expect of us. PRINCE2 has, as one of its seven principles, ‘Defined Roles and Responsibilities’. The principle that we should motivate and support our team members is universal to all contexts.

Face-to-Face is the Prime Communication Method

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

Principles behind the Agile Manifesto

If email is the worst form of communication known to humanity (and I believe it is, pending future innovations), then a face-to-face conversation in a shared language is the gold-standard. So here’s another principle that focuses on communication. And many, like myself, agree that ‘Project Management is 80 percent communication’.

The challenge for many development and project teams is that they are no longer co-located. Technology solutions like video calls and messaging apps like Slack can plug the holes. But they will never beat having a development team or a workstream team working together in one large room.

This one is not so much a general principle of project management, but more of a general statement about human social interactions!

Working software is the primary measure of progress

Working software is the primary measure of progress.

Principles behind the Agile Manifesto

Every Project Manager needs to measure progress. There are simple measures (like milestones and delivery of products). And there are more subtle and complicated approaches like Earned Value Analysis. But, for Agile practitioners, this Agile principle says thee main measure is delivery of working software.

So, this is a special case of a general principle in Project management. That general principle is to measure progress, and to find a suitable measure to use (or a proxy if necessary). Here we see a particular measure come to the fore. PRINCE2 has a similar principle: ‘Focus on Products’.

And I also think that the general principle of focusing on delivery of value is relevant here. On a software project, it is working software that the team has delivered to its client that has value.

Indeed, we can go further. The development job is not complete until the working software has been delivered. Unreleased software is not an asset, so it must be a liability. You can think of it as stock, or inventory. And inventory is a cost to the business; not an asset with a positive value.

Aim for Sustainable Progress

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

Principles behind the Agile Manifesto

Here’s a real difference between the Agile philosophy and the reality of traditional planned projects. Planned projects have deadlines and milestones. They have handovers and go-live dates. Thee are big events that cause a certain amount of pressure, rush, intensive work, and even stress.

This agile principle combines with the frequent delivery principle to do away with that. Or, at least, to try to. Instead, Agile aims to create short cycles of even work pressure. I don’t doubt the reality of a last push at the end of a cycle, or sprint. But the aim is to make constant refinement and incremental development of more functionality a reality. And to do so without setting the team up for periods of high pressure and the risk of stress and burn-out.

This is a marvellous principle that does not find a ready equivalent in general project management. But it should. There should be a requirement that Project Managers set up processes that allow their teams to sustain effort at a reasonable level from initiation to close down. And, of course, the best among us strive to achieve that.

Continuous Attention to what Matters

Continuous attention to technical excellence and good design enhances agility.

Principles behind the Agile Manifesto

Is it just me, or does this appear to somewhat conflict with the first of these 12 Agile principles? If you recall, that said ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’

If you do as I suggest, and just retain the first eight words of that principle… no conflict. So, in the same spirit, I have headed my interpretation of this principle as ‘Continuous attention to what matters’. You can’t optimize for time and quality, without a blank cheque on budget.

But, do you know what. I think technical excellence and good design should always matter. And they enhance agility because they allow the necessary flexibility to modify or add onto a solution, without the need to over-write an unreasonable amount.

The general principles here are about the

1. Importance of quality management, and building it into your core project prcess, and
2. Balancing of time, cost, and quality.

Keep it Simple

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

Principles behind the Agile Manifesto

If ‘Keep it Simple’ is not a general principle in Project Management (and life), then what is?

This needs little interpretation, but two videos of ours come to mind, that will help you understand aspects of this:

• The Pareto Principle
• Lean Project Management

Create Self-organizing Teams

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

Principles behind the Agile Manifesto

What is the role of a Project Manager in Agile projects? The answer, of course, depends on which agile methodology you select. But some do not have an explicit Project Manager role. And this agile principle explains why.

Agile prefers a self-organizing team. Here, a motivated (see above) team can arrange its own work. And the role of any explicit leader is very much a supporting role – one of a Servant Leader.

This does not find a ready equivalent in many statements of general project management principles. Although creating a supportive culture, where team members can take responsibility for their own work, is clearly always there.

Make Time for Reflection

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

Principles behind the Agile Manifesto

I love this one. Reflection is the primary mechanism we can adopt, as professionals, for growing our own wisdom. It’s what moves us from being smart to being wise. And Agile methods often have explicit approaches to facilitating reflection baked into their processes.

And all approaches to project management place an emphasis on learning and lessons learned meetings.

How do the Agile Principles Relate to its Tools and Techniques?

I am a great believer in the ‘tool-approach’ to learning and doing. That is, the more tools we learn about, the greater our flexibility, adaptability, and yes, agility. We can be more effective professionals when we have more tools at our disposal. in that, we are no different from woodworkers, plumbers, and surgeons.

So, to me, Agile’s biggest contribution to our profession – and our crad=ft – lies in the many new tools its practitioners have created. nd often, these are in the service of one or more of the 12 Agile Principle.

Here are my favorites, in alphabetical order.

• Acceptance Test-Driven Development (ATDD)
  This places an emphasis on acceptance testing – a collaboration between the business customers, users, developers, and testers – where meeting criteria that users and customers define in adance is the measure of success.
• Backlogs (Product and Sprint)
  A process that gathers everything that has not been panned and scheduled, ready for prioritzation.
• Behavior-Driven Development (BDD)
  This development process focuses on what users do, rather than what they say they will do, or what they think they want.
• Cross-functional Team
  This is not unique to Agile processes. But they do emphasize it, and it is a valuable way to embed diversity into workstreams and so enhance problem-solving capacity and allow decision-making to become more robust.
• Daily Stand-up / Daily Scrum
  Regular short meetings that enhance communication, accountability, and collaboration.
• Iterative and Incremental Development
  at the core of Agile’s adaptivity is the approach of making small steps (incrementalism) and returning to improve a working product (iteration).
• Planning Poker
  Estimating is one of the hardest disciplines in Project Management. We’ve done a full article on it. Planning Poker is an alternative approach that allows broad measures of the scale f a task to emerge through pooling a team’s experience and assessment. Learn more in this short video, answering ‘What is Planning Poker?’.
• Retrospective
  Retrospectives are a particular approach to looking back on experiences, reflecting on them, and learning from the process.
• Specification by Example
  This offers an approach to specifying user requirements, by reference to examples of interactions.
• Timeboxing
  Here’s an approach that works well in personal time management and could usefully apply to wider project management than just agile projects. Ant given task can be given a strict completion point and the scope and quality adapted to fit into it.
• User Story
  This is another project definition method. It takes a narrative approach to defining a user’s functional requirements.

There’s a valuable resource I recently found on the Hubstaff Teams website. For a thorough glossary of Agile terms, check-out:

• A is for Agile: Project Management Glossary of Terms

To Learn More about the Principles and Practices of Agile Project Management…

We have a lot of resources on this site to help you learn more about Agile Project Management. And we also offer you access to a range of detailed courses. For a structured introduction to all of them, take a look at our Agile Roadmap:

I Want to Study Agile Project Management

What is Your Experience of Agile Project Management and the 12 Agile Principles?

I’m always interested to hear about your experiences, opinions, and questions. Leave a comment below and I shall certainly respond to it.