What Is Agile Project Management?

Out of the plethora of project management approaches and methodologies, few have seen such widespread success as Agile.

Created exclusively to keep pace with the dynamic IT industry, Agile has become famous for its flexibility and the ability to help teams adapt to changing environments. Because of this, it has quickly spread to other industries as well. 

Agile has become so popular, in fact, that in APM’s 2021 Dynamic Conditions for Project Success survey, 51% of professionals declared that they considered being Agile an important factor for project success.

But what is Agile exactly?

If you’re itching to know more about it, you’re in the right place, as this guide will cover everything there is to know about Agile, including: 

• How it works, 
• Who it’s for,
• How it came to be,
• Why it’s good,
• When it’s bad,
• Why it’s so popular in project management, and 
• How it differs from other popular methodologies and frameworks, such as Scrum, Kanban, and Waterfall.

There’s also a glossary of Agile terminology at the end of the guide that you can refer to should any of this sound confusing.

What is Agile?

APM defines Agile as an “iterative approach to delivering a project throughout its life cycle.”

In other words, the goal of Agile is to deliver a functioning product as quickly as possible and then build upon it in short intervals — or iterations — rather than tackle the whole project immediately. 

This iterative approach to handling projects is one of the defining features of Agile. 

Just as its name suggests, the Agile approach is flexible and allows the project team to adapt to their environment and change direction. 

This way, Agile projects can provide value to clients and users throughout the entire project life cycle, rather than only once the project is finished.

History of Agile project management

Nominally, Agile was formalized in 2001 through the Agile Manifesto.

We say “nominally” because the truth is that the Agile Manifesto only codified the concepts that had already been in use long before 2001.

Agile draws from and builds upon concepts that are much older than it. 

It draws from Lean project management, developed by Toyota in the 1940s to facilitate “just in time” production and reduce waste. 

Even Kanban, which is nowadays labeled as an Agile framework, predates the Agile Manifesto by more than half a century.

Concepts such as early releases and frequent iterations also date way back to the 70s and Evolutionary Project Management (EVO).

All of these efforts culminated in the 90s when frustration with Waterfall project management’s inability to keep up with rapidly developing technology led to the advent of many Agile frameworks, such as: 

• Scrum, 
• Extreme Programming (XP), 
• Dynamic System Development Method (DSDM), and 
• Rapid Application Development (RAD).

Then, in 2001, in Utah, a group of software developers that included the creators of many abovementioned frameworks, came together and codified the Agile Manifesto, which outlined the 4 values and 12 principles of Agile.

Any project team or organization that abides by these 4 values and 12 principles is, by definition, Agile.

Values of Agile project management

According to the Agile Manifesto, these are the 4 core values of Agile.

Individuals and interactions	>	Processes and tools
Working software	>	Comprehensive documentation
Customer collaboration	>	Contract negotiation
Responding to change	>	Following a plan

While the creators of the Manifesto acknowledge the importance of the items on the right, they stress that, in Agile, the items on the left hold much more value.

Let’s cover each Agile value in more detail.

Value #1: Individuals and interactions over processes and tools

In this short and simple statement, the creators of the Agile Manifesto sum up what Agile is all about and what makes it different from other approaches. 

An Agile project revolves around people — the people who work on the project and the people who will use the end-product. 

This doesn’t mean that Agile advocates not using tools — software development tools are at the heart of most Agile projects. Processes and tools are important for executing projects, but it’s the people who drive innovation, progress, and development — which makes them infinitely more valuable.

Value #2: Working software over comprehensive documentation

A common misconception about Agile is that it requires no documentation at all. This simply isn’t true. 

Agile doesn’t make a case for documentation being unimportant — it only states that documentation is not all-important.

So, while creating documentation in Agile, focus only on the essentials. It’s always better to have an imperfect product than stacks upon stacks of perfectly compiled documentation with nothing to show for it.

Value #3: Customer collaboration over contract negotiation

Traditional project management approaches, such as Waterfall, tend to include the customers only at set stages of the project, where plans need to be approved and budgets negotiated. After this, the project team is left to follow the set plan with as few changes as possible. 

This can result in strategic battles of wits where the two sides try their hardest to squeeze the best possible deal out of each other. 

Agile stresses the importance of customer involvement throughout the project — often after every iteration — to offer insight, reviews, and feedback. 

As a people-centric approach, Agile puts emphasis on providing as much value as possible to the customers and/or end-users.

Value #4: Responding to change over following a plan

Having a meticulously laid out plan in front of you before starting a project can be helpful in anticipating possible issues. However, when unexpected problems arise, this plan can collapse like a house of cards.

Now, Agile doesn’t completely discard the notion of planning. An Agile software development project would still follow a software development plan, but it wouldn’t be blindly beholden to it. Instead, the project would constantly evolve as a result of customer feedback while using the plan as a rough guideline.

Because of this, responding to change in Agile environments feels natural. 

This adaptability is one of the reasons for Agile’s growing popularity in project management. Results of the Dynamic Conditions for Project Success research by the Association for Project Management show that 51% of professionals think of Agile as “important” or “very important”, while 30% consider it “fairly important”. 

Principles of Agile project management

Besides the 4 core values, the Agile Manifesto also lists 12 core principles that must be followed for a project to be called Agile. These 12 principles are:

1. “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 for 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.”

While there are certain practices that are often associated with Agile — such as performing work in sprints or having daily stand-up meetings — these aspects of project management aren’t what make a project Agile. 

A project is Agile only if it adheres to all of the abovementioned 4 values and 12 principles. 

How does Agile project management work?

Unlike traditional project management approaches, that rely on extensive planning before doing any work, Agile projects often begin with a general idea of the direction the project team wants to take. Then, it’s a matter of answering the following question: “What is the bare minimum that we need to do in order to create a functioning product prototype?”

But as we’ve seen, Agile is an umbrella term that covers many different frameworks. Each Agile framework approaches things differently.

For example, Scrum — the most popular and most widely used Agile framework — divides the work needed to make the functioning prototype into small tasks, prioritizes these tasks in a Product Backlog, and then performs them in Sprints. 

The length of Sprints ranges from several days to several weeks and during this time, the team focuses only on the tasks chosen for that Sprint.

Once a Sprint is complete, the results are implemented and reviewed. The tasks for a new Sprint are then chosen — most commonly based on review results or customer/user feedback — and the cycle repeats itself until the project is finished.

In practical terms, this means that Agile software development allows project teams to create a basic product that can be presented to the users, who can then give concrete feedback. This feedback gives the project team a further sense of direction, which then results in: 

• Upgrades, 
• Quality-of-life improvements, 
• Design changes, 
• Bug fixes, etc.

However, this also makes it difficult to answer the question of how Agile project management works, since there are dozens of different ways in which it can work. We can only make generalizations. 

In his book Agile project management: creating innovative products Jim Highsmith — one of the creators of the Agile Manifesto — details the following generalization of the 5 phases of Agile project management:

• Envision,
• Speculate,
• Explore,
• Adapt, and
• Close.

Step #1: Envision

Although Agile projects don’t rely too heavily on planning, it’s good to have an idea of the general direction the project is going to take and identify key stakeholders.

During this stage, the project owner will typically answer the questions of who, what, and how. In other words, they determine the key project requirements, objectives, stakeholders, and team members. 

The result is a clear vision of what the project is trying to be.

Step #2: Speculate

Although the name may be misleading, the second phase of Agile development focuses on planning. The reason Highsmith calls it “speculate” is simply because of the uncertain nature of Agile projects. As he puts it, “We have to learn to speculate and adapt rather than plan and build.”

That said, the second phase is where we determine:

• Key project milestones,
• A list of preliminary product features and requirements,
• Iterations, plans, etc.

Step #3: Explore

The “explore” phase can be equated to the execution phase. During this step, the team is focused on: 

• Managing risks, 
• Producing project deliverables, and 
• Managing quality and interactions with stakeholders.

The specifics of how the project team goes about this phase differ from framework to framework.

Step #4: Adapt

The “adapt” phase is where the results of both the deliverables and the team’s performance are reviewed and evaluated by comparing them to the project baseline. After this, any necessary corrections and adaptations are made.

The “speculate”, “explore”, and “adapt” phases are repeated with every iteration of the project. 

Step #5: Close

The final phase serves to officially conclude a project and celebrate its successful completion. 

That said, before going off celebrating, it is important to evaluate the project as a whole and draw conclusions on how it could have been improved. 

The information derived from these post-implementation reviews is invaluable for teams who might be tasked with a similar project in the future, and as such should be given due attention.

For example, if a new SaaS product encounters security issues, chances are that previous products made by the same company have encountered the same issue. Project teams can then look at how previous teams have handled this issue and, if applicable, use the same solution instead of reinventing the proverbial wheel each time. 

3 Benefits of Agile

Since its official inception with the drafting of the Agile Manifesto in 2001, many other industries besides IT have recognized the benefits of Agile. Some of the most prominent of these benefits are:

• Better flexibility,
• Higher customer satisfaction, and
• Value-driven resource spending.

Benefit #1: Better flexibility

More often than not, customers don’t know exactly what they want until they get the nearly finished product and realize that it’s definitely not that. This can cause a lot of problems for the project team and a lot of negative feelings between the client and the project manager or the company as a whole.

Agile environments don’t leave much room for such issues. The project sees constant involvement of the customers, users, and other stakeholders.

Since Agile is structured as a series of mini-projects, each new iteration is a new chance to make adjustments to existing features. This makes sudden changes of heart much less impactful.

This increased flexibility is inherently tied to lower risk.

Benefit #2: Higher customer satisfaction

Agile is a highly collaborative approach to project management. This extends beyond teams and team members to also include project collaboration with clients, users, and other stakeholders.

To iterate upon a project, Agile requires a steady influx of feedback from stakeholders on all fronts. This helps the development team to pinpoint exactly what the customers want and need, which, in turn, leads to greater customer satisfaction. 

The second major factor that influences customer satisfaction is the quick turnaround. Customers can be involved in the upgrades and see the product being built in front of their eyes. 

Compared to the traditional approach where the customers sometimes have to wait months before seeing any results, the tangible results after every iteration are a significant step up.

Benefit #3: Value-driven resource spending

The aim of Agile projects is to deliver value to the client and/or users.

This may sound like stating the obvious, but it isn’t always the case. The goal of non-Agile projects is to create the final deliverable, as contractually specified. This could be a deliverable that doesn’t provide value to end users, possibly because your assumptions about what the users want or need are way off.

For example, let’s say you want to build a smartphone app that locks, unlocks, and starts your car at the press of a button. If we imagine that you’re a car manufacturer in this example, we can take things further and say that you no longer even put keyholes in your car since the app is supposed to render them completely obsolete.

The assumption here is that your customers hate car keys and that you’ll provide value to them by removing them. This assumption might be true, but if it’s not, you’ll have spent loads of money developing a feature no one wants or needs.

Let’s not even mention the fact that leaving your phone inside your car by accident would create a whole new problem where you can’t get inside, or that hackers could effortlessly go into your car and drive away if they uncovered your credentials.

With Agile, even if your initial assumptions are off, your first prototype will make this clear. Consequently, Agile projects are less likely to spend resources developing products or services that don’t drive value.

3 Disadvantages of Agile

For all its benefits, however, it’s important to stress that Agile is not the best approach to all projects.

Many of the things we’ve listed as the benefits of Agile are also its downsides, depending on the project. In other words, some projects simply aren’t suited to Agile because it:

• Is prone to scope creep,
• Doesn’t get things right the first time, and
• Works with unclear timelines and budgets.

Disadvantage #1: Scope creep

Agile’s iterative approach makes it easy prey for scope creep. 

After all, it’s easy to add one small new feature as part of the next iteration. But it doesn’t stop at one. Before you know it, you’ll have spent loads of resources on adding in these small new features, most of which will likely not lead you closer to having a finished product that’s up to the desired specs.

Therefore, Agile project managers have to be more careful about staving off scope creep than Waterfall project managers — who have detailed, contractually negotiated scopes and are often unable to accommodate changes of this kind even if they wanted to.

Disadvantage #2: You aren’t expected to get it right the first time

Iteration, by definition, implies that you’re not going to get it right the first time.

Instead, you try to get closer and closer to the solution of a problem with each successive attempt, almost like you’re throwing darts at a board until you get a bullseye.

This works well with software development.

But it does not work well with, say, construction or manufacturing, where you don’t have the luxury of not getting it right the first time.

You can see how the following wouldn’t be a good motto for a bridge-building project team: “We’ll create an approximation of the finished bridge and iterate upon it after we release it and see where it starts to break, shake, and fall apart.”

The famous example of the Indiana University Wells Library illustrates this point even better. The library is said to be sinking a couple of inches every year because the architect failed to account for the weight of all the books that would be placed in it. This urban legend has been debunked, but the concept behind it is plausible.

If you have to get something right the first time, Agile may not be the best option.

Disadvantage #3: Uncertain durations and budgets

Agile does not perform at its best when restricted by a hard deadline. These projects need time to breathe and find their footing. If you’re using Agile correctly, then iterations — i.e., not getting it right the first time — are a feature, not a bug.

But this inevitably means that Agile projects are tricky to budget. Project teams don’t work for free, so the longer the project drags, the more it will cost. So, if you’re on a budget or you need to meet a project deadline — for example, having your product ready by Valentine’s Day — then it could be a problem.

Of course, the benefit of Agile in these cases is that, should the project drag, the team could Agilely cut unnecessary features and prioritize essential features to still meet the deadline in some shape or form. 

Waterfall projects lack the gymnastic grace and flexibility to pull this off, so it all depends on the project in question and whether or not something like this would be viable for it.

What Agile is NOT

Now that we have a better understanding of what Agile is, let’s see what it is NOT.

Martin Fowler, one of the founders of the Agile Manifesto, claims that the biggest challenge for Agile practitioners is dealing with what he calls “faux-Agile” or “Dark Agile” — the widespread use of practices that misinformed people brand as Agile, but that contradict the basic Agile principles.

To put it more simply, anything that doesn’t follow the 4 values and 12 principles of Agile is not Agile.

Just because there is no one right way to be Agile doesn’t mean there aren’t wrong ways to be Agile. This is why project managers get many certifications — like the Agile Certified Practitioner (ACP) — to show that they know what they’re doing.

In addition to this, there’s a lot of confusion about the differences between Agile and Scrum, Kanban, and Waterfall in particular, so let’s tackle these differences one by one.

Agile vs Scrum

According to the 16th Annual State of Agile Report, as much as 87% of respondents reported leveraging Scrum in their practices. This makes Scrum the de facto leader when it comes to Agile frameworks.

But, because it’s so widespread, people often think that Scrum = Agile. 

This simply isn’t the case. Agile is a set of values and principles. Scrum is one of the frameworks you can use to manage your projects in accordance with these values and principles. 

So you can be Agile using Scrum, but you can also be Agile using other frameworks, like Kanban.

Scrum is best known for its:

• Multiple short Sprints throughout the project,
• Daily stand-up meetings,
• Unique Scrum Team Roles that don’t include a project manager, and
• Focus on individuals and users.

All of the above points are complementary to the Agile approach to project management, which is why Scrum is the most frequent choice in IT organizations that choose to adopt Agile practices.

That being said, other Agile frameworks, like Kanban, share very little with Scrum while still being Agile, so we shouldn’t equate Scrum with Agile as a whole.

Agile vs Kanban

Just like Scrum, Kanban is also a framework that you can use to manage projects while adhering to Agile values and principles.

Kanban is a popular framework that focuses on streamlining and managing workflow in a visual way. It encourages feedback loops and fosters successful self-management for teams. 

Kanban’s most defining feature is the Kanban board — a visual representation of the project’s workflow. The board consists of several columns, each for a different stage of work. Tasks are organized as cards that you can stick to and move around the Kanban board.

The number and titles of the columns may vary from project to project, but most Kanban boards have at least the following three:

• To do,
• In progress, and
• Done.

Once a new task is undertaken it’s transferred into the “In progress” column. When the task is completed, it’s moved from “In progress” to “Done”, and so on. This is why Kanban is the second most popular choice of framework.

Finally, Kanban is very good at keeping the work volume in check. The number of tasks within a column is often limited to help the team focus on what needs to be done at the moment and not concern themselves too much with what lies ahead.  

Agile vs Waterfall

Agile and Waterfall are 2 diametrically opposed approaches to project management. 

While many consider Waterfall quite outdated by now and see Agile as the ultimate solution for all their project management problems, this is certainly not the case. 

Agile was first developed as an approach that would be a better fit for software development than Waterfall. 

Waterfall is a linear approach to project management that has predefined steps that need to be completed in a certain order. The method is set up so that one step must be completed in order to start the next one.

This means that a lot of time can potentially be wasted if the team gets stuck on one of the steps.

However, just because Waterfall loses to Agile when it comes to IT, it doesn’t mean it’s universally bad. 

Software development is malleable. Buildings are not.

Software can be built, rebuilt, and changed much more easily than a house. Conversely, once you erect a building that’s 10 floors high, there’s only so much you can structurally change and rebuild on, say, the 5th floor.

This is why construction is a particularly good example of an industry where Waterfall works better than Agile.

To create a clear distinction between the 2 approaches, we’ve listed their main characteristics in the table below.

Agile	Waterfall
Focuses on user satisfaction	Focuses on contractual obligations
Has high flexibility	Has low flexibility
Self-managed	Managed by the project manager
Cyclic approach	Linear approach
Constant collaboration with stakeholders	Minimal stakeholder engagement
Quick turnover and short deadlines	Slow turnover, longer deadlines
Rudimentary planning	Entire project planned from start to finish

The right tools for Agile project management

Just like it’s hard to imagine our lives without an alarm clock these days, it’s difficult to perceive a time when Agile project management software did not exist. 

A good digital project management tool is an invaluable asset to any Agile organization. 

An Agile project management tool like Plaky is a fantastic option for anyone in need of a centralized platform for task management, goal-setting, collaboration, and performance reviewing.

Plaky can help Agile teams:

• Streamline complicated project processes into manageable tasks, 
• Keep everyone organized and informed, and 
• Save precious time.

Moreover, with no arbitrary limitations on the number of users, boards and tasks, Plaky is an ideal fit for companies looking to grow alongside a PM tool that won’t stifle them. 

In addition to the industry standard Table View, Plaky offers users the ability to organize their tasks on a virtual Kanban board and reap all the benefits that are associated with this visual, workflow-enhancing technique. 

Most importantly, it is a highly collaborative tool. As such, it can be used to connect and organize several teams working on the same project, regardless of whether they are office-based or remote teams.

Plaky is the perfect tool for managing projects in a clean and visual way, and it has all the features you’ll need to manage a fast-paced Agile project. 

And since Plaky’s basic features are free of charge, you can try it out yourself anytime you like.

Glossary of Agile terminology

Before we delve any deeper into what Agile is and how it works, we should first offer a brief overview of the most commonly used terms in Agile.

• Agile — an iterative approach to project management that emphasizes quick turnover, constant collaboration and feedback, and performing multiple smaller tasks in short bursts (sometimes called Sprints).
• Agile Manifesto — a document that lists 4 core values and 12 principles that serve as guideposts for Agile practitioners.
• Backlog — a list of features that have already been prioritized and are waiting their turn to be completed.
• Cadence — the length of an iteration cycle or Sprint; an iteration cycle of 3 weeks has a 3-week Cadence.
• Epics — broader objectives consisting of several related user stories that a project team needs to complete.
• Initiatives — groups of epics aimed at the same goal.
• Kanban — a popular Agile framework that emphasizes visual representation of work, improved collaboration and feedback, and workflow management to deliver just-in-time product delivery.
• Kanban board — a visual representation of workflow in the form of cards arranged in different columns according to their status (to do, doing, done).
• Scrum — a popular Agile framework that provides methods for implementing Agile values and principles.
• Scrum Master — the person who coordinates the development teams and keeps them from veering off the Agile path.
• Sprints — the name for iteration cycles in Scrum.
• Stand-up meetings — short daily meetings where teams discuss the broad strokes of the project, recent accomplishments, and immediate goals.
• User stories — the smallest units of work that deliver value to the end-user.

Conclusion: Agile projects are flexible and receptive to change

Although often confused for a methodology, Agile is a set of values and principles that serve as guides for managing projects in a more dynamic, flexible, and user-centric way. 

Since Agile doesn’t dictate its own methods to approaching project management, project teams need to choose their own framework with the Agile approach that does. The most popular of these frameworks are Scrum, Kanban, and Scrumban.

Since its inception, Agile has grown into one of the most popular project management approaches used across various industries due to its ability to change direction, implement new features, and evolve old ones — all without increasing the chances of risk or derailing the project due to constant change. 

📖 If you enjoyed having the glossary for Agile terms at your disposal while reading this text, you should check out our Project Management Glossary of Terms — it contains information about all basic and advanced project management terminology and isn’t restricted to merely Agile.

References:

• Association for Project Management. (2021). Dynamic Conditions for Project Success. Retrieved: March 14, 2022, from: https://www.apm.org.uk/media/50481/apm-dynamic-conditions-for-project-success-2021-v2.pdf 
• Beck, K. et al. (2001). Manifesto for Agile Software Development. Retrieved March 2, 2022 from https://agilemanifesto.org/ 
• Crowe, M. (2019, June 18). Not Sinking Since 1969: Wells Library is 50. Indiana University Bloomington. https://libraries.indiana.edu/not-sinking-1969-wells-library-50 
• Digital.ai. (2022). 16th State of Agile Report. https://info.digital.ai/rs/981-LQX-968/images/AR-SA-2022-16th-Annual-State-Of-Agile-Report.pdf
• Fowler, M. (2018). The state of Agile software in 2018. Martin Fowler. Retrieved March 14, 2022 from: https://martinfowler.com/articles/agile-aus-2018.html
• Glib, T. (2002, April 29). 10 Evolutionary Project Management (EVO) principles. Glib.com. https://static.aminer.org/pdf/PDF/000/306/364/evolutionary_project_management_multiple_performance_quality_and_cost_metrics_for.pdf
• Highsmith, J. (2009). Agile project management: creating innovative products (2nd Ed.). Pearson Education. https://www.researchgate.net/publication/234809670_Agile_Project_Management_Creating_Innovative_Products