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.
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:
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?’
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.
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:
In 2001, seventeen software developers met to discuss these lightweight software development methods:
As a result of the meeting, they published the Manifesto for Agile Software Development.
This is the manifesto they put out:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the authors listed above and at AgileManifesto.org.
This declaration may be freely copied in any form,
but only in its entirety through this notice.
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.
Here are the 12 Agile Principles, which underpin the Agile Manifesto, as articulated at AgileManifesto.org:
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.
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:
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.
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 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.
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. ut, 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. PRICE2 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.
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.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.
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 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
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 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.
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.
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.
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’m always interested to hear about your experiences, opinions, and questions. Leave a comment below and I shall certainly respond to it.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.