Agile Project Management now feels like a part of the landscape of the project profession. It’s 7 years since the PMI introduced Agile into the 6th Edition of its Project Management Body of Knowledge. We now have a methodology-agnostic 7th edition. In the world of PRINCE2, we have PRINCE2 Agile. And there are multiple agile methods and frameworks in use – each with its own knowledge base and many with certifications.
But there are still a lot of project professionals who are uncertain about ‘What is Agile Project Management?’ and why it is important to project managers.
This is made worse because the word Agile has so many different connotations. And many project managers still think it is something that only applies to software development. So, it doesn’t apply to them.
They are wrong.
An Update
So I think it’s time to update the article that Agile expert, Chuck Cobb, wrote for us seven years ago. He wrote it to take you through the basics.
Chuck has authored three serious guides to Agile. These include the best-selling second edition of: ‘The Project Manager’s Guide to Mastering Agile‘. He also runs the Agile Project Management Academy, with a comprehensive range of online training.
This article therefore is largely Chuck’s work, with a few updates and additions from me (Mike). All credit for this should go to Chuck Cobb. Any errors I have introduced are my responsibility!
Finally, I read recently a statement in a LinkedIn post, that we cannot answer the question ‘What is Agile?'”‘ without first defining ‘what we mean by “agile”‘. In this article, I hope Chuck and I can do both!
We’ll cover:
- So, What is Agile?
- What’s Wrong With the Predictive Project Management Approach?
- Why Is Adaptivity Important?
- What’s an Example of a Project Requiring an Adaptive Approach?
- How Does an Agile Approach Solve This Problem
- What are Scrum and Kanban?
- So, Do I Need to Be Concerned About Agile?
So, What is Agile?
‘Agile’ means a lot of different things to different people:
- To some people, it means just developing software faster
- To some people, it means creating a more people-oriented project environment
- And to others, it means making the project management process a lot more efficient. It does this by streamlining the whole process and eliminating unnecessary documentation
But these are only a few of the many different connotations. There are many, many more flavors and interpretations. Consequently, there are also many stereotypes, myths, and misconceptions about what Agile is.
Here’s a short video I made to answer the question. I made it back in early in my YouTube career in the summer of 2017. But the content still holds up*
* except, that is, for the reference to the then-forthcoming 6th edition of the PMBOK Guide. We have now had the 7th edition since summer 2021, so I imagine PMI is currently working on the 8th edition!
The Essence of Agile
All of these things are potential outcomes of an Agile process. But they are not the fundamental essence of what an Agile process is all about in my opinion.
The fundamental essence of an Agile process is adaptivity.
The Agile Manifesto and 12 Principles
In the video, I refer to the Agile Manifesto. We have a full video that looks at it in more detail, and answers the question, What is the Agile Manifesto? | Video
The Agile Manifesto was followed, a few years later by an articulation of 12 Agile Principles. We have a full article that examines these: Agile Principles: The 12 Keys to Adaptive Project Management.
The Origins of Agile
Many people think that Agile began with the Agile Manifesto of 2019. That’s not true. The roots of Agile go much deeper than that.
Iterative and incremental software development methods go back as early as 1957 – and maybe earlier. Evolutionary project management and adaptive software development started in earnest in the early 1970s. During the 1990s, a number of lightweight software development methods evolved and gained active support. These were a reaction to the existing methods (often referred to collectively as waterfall) that critics described as overly regulated, planned, and micromanaged.
These lightweight methods included:
- Rapid Application Development (RAD), from 1991 (which my colleagues were using – says Mike)
- The Unified Process (UP), from 1994
- Dynamic Systems Development Method (DSDM), from 1994
- Scrum, from 1995
- Crystal Clear, from 1996
- eXtreme Programming (XP), from 1996;
- Feature-Driven Development (FDD), from 1997.
Although these all originated before the publication of the Agile Manifesto, we now retrospectively consider them to be agile software development methods.
Most of these early Agile methods were designed for software development. However, the Agile Manifesto started to recognize the value of applying the principles of these approaches more generally, outside the context of software development.
What’s Wrong With the Predictive Project Management Approach?
Let’s start with the project management processes that you are probably familiar with. Generations of project managers designed these around a ‘traditional plan-driven project management’ model.
This is what many people loosely call ‘Waterfall’. To me, this is an inappropriate term, that some use in a pejorative way. I prefer the term ‘Predictive Project Management’ – or maybe ‘Planned Project Management’.
This approach prioritizes predictability. It uses estimating, budgeting, planning, and controls to predict costs and schedules, and to work to maintain them. Therefore, in predictive project management, it is important to have clearly defined requirements. These are the basis for planning the project.
The Benefits of Predictability
That’s the predominant way that project management has worked since the 1950s and 1960s. A project is successful if it delivers the requirements within the defined budget and schedule. This kind of predictability can be important. For large investments, it allows a company to:
- Calculate an expected return on their investment from a project, with some certainty
- Make a go/no-go decision about whether to fund the project or not based on that information
This has worked magnificently. But the approach is not without problems. The primary problem is that it requires a fairly detailed plan for the project upfront. And that is very difficult at the best of times.
It becomes near impossible to do, in projects with very high levels of uncertainty. Particularly, when that uncertainty relates to the outcome that is desirable. And that is the case when technology, markets, and society are changing rapidly and unpredictably.
Comparing Adaptive and Predictive Project Management
The fundamental difference between an Agile Project Management approach and a traditional plan-driven project management approach is:
- A predictive project management approach primarily emphasizes planning and control to achieve predictability over project costs and schedules for projects with well-defined requirements. In that environment, success is generally defined as delivering requirements to specification, within the project’s cost budget, and on-time.
- An Agile Project Management approach primarily emphasizes flexibility and adaptivity to maximize the value of the project in an uncertain environment. In this kind of environment, it may be impossible to create well-defined requirements prior to the start of the project and it is much more important to use a flexible and adaptive approach to further define the requirements as the project progresses. Creativity and innovation maximize the value of the solution.
However, it is important to note that there is not a binary and mutually exclusive choice between these two extremes. Depending on the level of uncertainty in the project, project professionals should blend them in the right proportions to create a project management approach that is well-suited to delivering the value the project requires.
Why Is Adaptivity Important?
We live in a different world today from the world of the 1950s and 1960s. Yet that’s when project managers first defined formal project management approaches. Now, there is a much higher level of uncertainty:
- Technology is fast-changing
- Solutions are much more complex
- Our business environment is dynamic and subject to constant change
When you develop a detailed plan for a project with a lot of uncertainty, it needs a lot of assumptions. In today’s kind of environment, those assumptions will often be wrong – or will soon become out-of-date. As a result, your project will need significant re-planning and possible rework.
So does it make sense to force-fit a project with a high level of uncertainty into a traditional plan-driven approach?
Surely it’s better to fit the methodology to the nature of the project. And that’s where a more adaptive approach makes a lot of sense.
This does not mean that you don’t do any upfront planning. It means that you should use a level of planning that is appropriate to the level of uncertainty in the project.
What’s an Example of a Project Requiring an Adaptive Approach?
Chuck uses an example in his Agile Project Management training that is somewhat extreme. But it gets the point across.
Suppose you have the task of finding a cure for cancer. Now suppose that you need to outline:
- what the solution will be,
- how long it will take to develop it, and
- what the total cost of the research will be to develop the solution.
In that situation, it would be ridiculous to attempt to develop a detailed project plan. You can’t make accurate cost and schedule estimates. There are just way too many uncertainties to resolve.
So what would you do?
Give up and do nothing? That doesn’t make sense either.
In this situation, we do know some things about finding a cure for cancer. We have years of research into that area. But there are still way too many unknowns to develop a detailed project plan for a solution.
So, what you would do is take as much advantage as possible of what we know. Then you would take an iterative, trial-and-error-and-learn approach to find a solution. This is how a lot of scientific research works:
- try something
- observe what happens
- draw some conclusions
- try something else
- and continue
That’s the way Edison invented the light bulb…
Here’s a quote from Edison on that subject:
I speak without exaggeration when I say that I have constructed three thousand different theories in connection with the electric light, each one of them reasonable and apparently to be true.
Yet only in two cases did my experiments prove the truth of my theory. My chief difficulty, as perhaps you know, was in constructing the carbon filament, the incandescence of which is the source of the light.’
(1890 Interview in Harper’s Magazine)
In a 1910 autobiography of Edison, Edison’s friend and associate Walter S. Mallory is quoted as asking:
‘Isn’t it a shame that with the tremendous amount of work you have done you haven’t been able to get any results?’
The book goes on to say that ‘Edison turned on him like a flash, and with a smile replied: Results! Why, man, I have gotten lots of results! I know several thousand things that won’t work!’
What Makes This Kind of Project Different?
There are two things that make this kind of project fundamentally different:
- The level of uncertainty is very high.
This makes it impractical or impossible to develop a detailed plan for the project upfront. - Creativity and innovation are necessary for finding a good solution.
They are far more important than predictability.
How Does an Agile Approach Solve This Problem
An Agile process is built on an ‘Empirical Process Control’ model.
The word ’empirical’ means ‘based on observation’.
In the context of an Agile development process, empirical working is at the heart of the approach. During the course of a project, both the product and the process to produce it are subject to continuous refinement. We adapt what we are doing, to produce the right product and to optimize the value of the product we are creating.
Why Is This Important to Project Managers?
You might ask ‘Why is this important to project managers?’ Isn’t Agile something that only applies to software development?
This is a common misconception.
It is true that Agile methodologies have been most closely associated with software development. But, it is also true that all projects have some level of uncertainty associated with them. So, if you try to force-fit all projects into a traditional plan-driven project management approach, it won’t always work.
Imagine, for example, trying to develop the next generation of the iPhone. Or pick any other new and innovative product. In that kind of project, creativity and innovation are as important, or more so, than predictability.
Go one step further. Imagine trying to create the iPhone 14 back in 2006.
Impossible!
What you need is a series of incrementally improving, but stable models.
What are Scrum and Kanban?
Agile is an approach to delivering projects. But it does not tell you how to do it. Project Managers have developed many ways to handle projects in an adaptive way. These are the Agile methodologies – or, more properly with most of them, agile frameworks.
Most of them have their origins in software development. But that does not mean we cannot adapt them to a host of project types. Two of these methodologies are Scrum and Kanban. Scrum is probably the most widely used today. Tomorrow? Who knows?
However, whilst their use in project management started in software development, there’s a deeper story. Their roots lie elsewhere. Kanban comes from Japanese manufacturing. And Scrum originated as a new model for product development. And then there is Scrumban – a hybrid of the two.
Other methodologies have stronger roots in software projects. There’s also:
- eXtreme Programming (XP)
- Rapid Application Development (RAD)
- Adaptive Software development
- Feature-Driven Development (FDD)
- Dynamic Systems Development Method (DSDM)
A wise project manager will draw on the wealth of ideas available to us, to find the right solution for your project.
So, Do I Need to Be Concerned About Agile?
Yes.
Most project managers today are well-trained; in a traditional, plan-driven approach. This hasn’t changed significantly since the 1950s. Its emphasis is on planning and controlling the costs and schedules. Projects have needed to meet well-defined requirements.
But, on its own, this won’t do.
Today, a project manager who only knows a traditional approach will be at a serious disadvantage.
It is not Either/Or
What makes this more difficult is that this is not a binary choice between ‘Agile’ and ‘Traditional’. Many people seem to think the two approaches are mutually exclusive.
They are not. Yes, there are some people who promote a purist attitude. That is a foolish attitude. They are just two extremes of a spectrum of all possible approaches. And, to be brutally honest, no human problems are ever solved by going to an extreme.
If you want to get the best results, you must understand the situation. You need to figure out how to blend a traditional plan-driven approach with an adaptive (Agile) approach in the right proportions.
This requires a lot of skill. But if you understand both approaches, you definitely can do it. And that is exactly what Chuck designed his Agile Project Management Academy training to address.
The Business Decision
Many businesses and Project Managers face a choice. Do they continue to choose a traditional plan-driven approach? Or do they opt for a more Agile approach? Or should they synthesize a hybrid model?
For critical projects, this can be a very important decision. It can have significant business impact.
This is why you need to see agile and traditional project management as complementary; not competitive. Project Managers must learn how to blend the two approaches in the right proportions to fit the situation.
What’s your Attitude to Agile?
- How do you assess the importance of Agile to Project Managers?
- What do you think of PMI’s decision to include Agile in the PMBoK and in its PMP qualification?
- What questions do you have about Agile?
We look forward to reading your points of view and responding to them, in the comments section below.
