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 became famous for its flexibility and the ability to help teams minimize the ever-dreaded scope creep. As such, it quickly found its place in other industries besides IT, and led 71% of professionals to declare that they consider being Agile an important factor for project success.
Due to the widespread adoption of project management certifications and the popularity of Scrum, Agile recently gained even more exposure. Counterintuitively, however, this has only led to confusion about the relationship between Scrum and Agile, and what Agile even is.
If you’re also itching to know more about it, the guide below is a good place to start. It covers everything there is to know about Agile, how it works, who it’s for, why it’s so popular in project management, and how it differs from other popular methodologies and frameworks, such as Scrum, Kanban, and Waterfall.
What is Agile?
In short, Agile is a hyper-focused, flexible, and iterative way of handling the work needed to complete a project.
One of the main defining features of Agile is that it handles projects in small increments instead of being concerned with the big picture. Just as its name suggests, the agile approach is flexible and allows the project team to change direction at any moment, greatly decreasing the chances of risk and scope creep.
Basic Agile terms
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
Agile is an iterative approach to project management that emphasizes quick turnover, constant collaboration and feedback, and performing multiple smaller tasks in short bursts (sprints).
Agile Manifesto
Agile manifesto is a document created in 2001, in Utah, by seventeen practitioners of various Agile frameworks in order to create an alternative to existing processes for handling projects in software development. It lists four core values and twelve principles that serve as guideposts for Agile practitioners.
User stories
User stories are the smallest units of work that deliver value to the end-user. They are requirements written from a user’s perspective that usually use the following template:
| User story template | User story example |
|---|---|
| As a <Role> I want to <Objective> So I can <Motivation> | As an online shopper I want to see book reviews So I can decide if it’s the right one for me |
Epics
Epics are broader objectives a project team needs to complete. Epics consist of several related user stories.
Initiatives
Initiatives are groups of epics aimed at the same goal.
Backlog
Backlog is a list of features that have already been prioritized and are waiting their turn to be completed.
Cadence
Cadence is the length of a sprint or iteration cycle. If a sprint lasts three weeks, the sprint has a three-week cadence.
Kanban
Kanban is a popular Agile framework that emphasizes visual representation of work, improved collaboration and feedback, and workflow management.
Kanban board
A Kanban board is a visual representation of workflow in the form of cards stacked in different columns according to their status.
Stand-up meetings
Stand-up meetings are short daily meetings where the team discusses the broad strokes of the project, their recent accomplishments, and immediate goals.
Scrum
Scrum is a popular Agile framework that provides methods for implementing Agile values and principles.
Scrum master
A Scrum master is someone who helps coordinate the development teams and keeps them from veering off the Agile path.
Sprints
Sprints are short bursts of work when teams focus all their efforts on developing specific smaller goals.
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.
In other words, let’s see how Agile differs from Scrum, Kanban, and Waterfall — but, also, how it may relate to some of them.
Agile vs Scrum
Scrum is the most commonly used framework to promote Agile practices in an organization.
According to the 13th State of Agile Report, as much as 72% of respondents reported using Scrum or an approach that includes Scrum in their practices.
Because it’s so widespread, people often think that Scrum = Agile.
But Scrum is only one of many ways project teams can choose to uphold Agile values and principles.
Scrum is best known for its following characteristics:
- Iterative approach to project management,
- Multiple short sprints throughout the project,
- Daily stand-up meetings,
- Lacking a project manager, and
- Focus on the 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.
Agile vs Kanban
Kanban is a popular Agile 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 one universally recognized defining feature is the Kanban board. The board consists of several columns, each for a different stage of work. Multiple tasks or cards within those columns contain the description of the work that needs to be done.
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 “Doing” column. When the task is completed, it’s moved from “In progress” to “Done”, and so on. This is why Kanban is the second popular choice of framework. Its boards are a perfect visual complement for Agile’s sprints.
Finally, Kanban is very good at keeping the work volume in check. The number of tasks within a column is often limited in order to help the team stay in 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 two completely opposite approaches to project management. While many consider Waterfall to be quite outdated by now and see Agile as a panacea 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. As such, Agile is very flexible, allows teams to pivot and change course at any point during the project, and provides fast results.
While Agile is still best suited for the IT industry, many others have recognized the values Agile provides and incorporated them into their own practices.
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.
For instance, we all know that a house can’t be built starting from the windows. Things have to go in a certain order. 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 two approaches, we’ve listed their main characteristics in the table below.
| Agile | Waterfall |
|---|---|
| Focuses on user satisfaction | Focuses on client satisfaction |
| 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 the start |
Agile values and principles
Agile is often referred to as a project management methodology. While this is not too far from the truth, it’s better to look at it as a set of values and principles a project team must follow in order to be… well, Agile.
The concept of Agile has existed since the 1950s, but it was only in the 1990s that it experienced a boom in popularity as a new and better way of tackling software development. It took nearly another decade, however, to finally get formalized in the Agile Manifesto.
While only 68 words long, the Manifesto is viewed as a collection of commandments for Agile project management, listing core values and principles every Agile project should abide by.
Core Agile values
According to the Agile Manifesto, Agile project management has four core values.
| 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 are valued much more.
Here’s what Agile values are about, in more detail.
Individuals and interactions over processes and tools
In this short and simple statement, the creators of the Agile Manifesto summed 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.
While the processes and tools are important for executing the project, it’s the people who drive innovation, progress, and development — which makes them infinitely more valuable.
Working software over comprehensive documentation
A common misconception about Agile is that it requires no documentation at all. Now, documentation is always good. But there is such a thing as too much of a good thing.
So, while creating documentation in Agile, cut the unnecessary. Focus on what’s important. It’s always better to have an imperfect product than stacks upon stacks of perfectly neat documentation — but nothing to show for it.
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 sprint — 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.
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, the rigid structure can be quick to crumble.
Agile doesn’t follow a strict plan, constantly changes focus as a result of customer feedback, and structures work as a series of mini-projects that don’t necessarily depend on one another.
As such, responding to change in Agile environments is not only advised but also natural.
This adaptability that comes with being Agile is one of the reasons why, when asked about the importance of Agile for project success, 51% of professionals interviewed in the Dynamic Conditions for Project Success research by the Association for Project Management, declared that it was ‘important’ or ‘very important’, and 30% labeled it as ‘fairly important’.
Core Agile principles
Besides the four core values, the Agile Manifesto also lists twelve core principles that must be followed for a project to be called Agile. Those twelve principles are:
- Satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- 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 work?
Unlike traditional project management approaches that have it all planned out beforehand, Agile projects often begin with a general idea of the direction the project team wants to take and the question “What is the bare minimum that we need to do in order to create a functioning product prototype?”.
Once this minimum is identified, the work is divided into smaller chunks, prioritized, and then performed in short bursts (i.e. sprints) that normally last from several days to several weeks.
During these sprints, the team is focused on the task at hand, and only on the task at hand.
Once the sprint is complete, the results are implemented and reviewed, and a new sprint with a new goal begins soon after. The work that will be done in the following sprint is often determined by the review results from the sprint that preceded it and by the customer and user feedback.
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.
5 typical steps in Agile project management
There is no prescription for becoming Agile. There are no set steps or rules. Development teams are free to follow any of the popular Agile frameworks, or a combination of them, so long as the frameworks help them uphold the core Agile values and principles.
Usually, there are five steps Agile teams follow regardless of the framework they’re using. These may carry different names depending on whom you ask, but they normally follow the same general principles.
Jim Highsmith, one of the creators of the Agile Manifesto lists the following 5 in his book “Agile project management: creating innovative products”:
- Envision,
- Speculate,
- Explore,
- Adapt, and
- Close.
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 who will be the 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 requirements, objectives, stakeholders, and team members. The result is a clear vision of what the project is trying to be.
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. In his words, “We have to learn to speculate and adapt rather than plan and build.”
That said, the second phase is where we determine:
- Key milestones,
- A list of preliminary product features and requirements,
- Iterations, plans, etc.
Explore
The “explore” phase can be equated to the execution phase. During this step, the team is focused on delivering the requirements, managing risks, and managing quality and interactions with stakeholders.
Adapt
The penultimate phase is where the results of both the deliverables and the team’s performance are reviewed and evaluated by comparing them to the original plans. After this, any necessary corrections and adaptations are made.
The “speculate”, “explore”, and “adapt” phases are repeated with every iteration of the project.
Close
The final phase serves to officially conclude a project and celebrate its successful completion.
That said, before going off partying, it is important to evaluate the project as a whole and draw conclusions on how it could have been improved. This information is invaluable for teams who might be tasked with a similar project in the future, and as such should be given due attention.
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:
- Lower chance of scope creep,
- Better flexibility,
- Higher customer satisfaction, and
- Efficient use of resources.
Agile leads to a lower chance of scope creep
Traditional project management methodologies entail extensive planning and preparation in order to get ahead of risks and avoid scope creep. However, while planning can, in some cases, greatly reduce the chance of scope creep, if scope creep still manages to crawl its way into the project, it can cause a lot of damage because of the rigid structure of this kind of approach.
Agile, on the other hand, rarely has to deal with such issues.
Because of the way in which work is performed in Agile environments, potential sources of scope creep are easy to spot and eliminate, or perhaps even incorporate into the next iteration of the product.
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 sprint is a new chance to make adjustments to existing features, which makes sudden changes of heart much less impactful.
Higher customer satisfaction
Agile is a highly collaborative approach to project management, and this doesn’t only refer to collaboration between teams and team members, but also to the collaboration with stakeholders.
Agile takes collaboration very seriously and demands constant feedback from stakeholders on all fronts. This ensures that the development team will deliver 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 sprint session are a significant step up.
Efficient use of resources
It’s not uncommon for Agile projects to change or adjust course multiple times throughout their lifecycle, which is why in Agile, all work is performed as it comes and nothing is done in advance.
This kind of approach helps prevent any time or money from being wasted on something that might prove redundant in the future.
Using 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 project management software did not exist.
A good digital project management tool is an invaluable asset to any Agile organization. But good PM software is difficult to come by, especially those that don’t cost an arm and a leg.
As such an example, Plaky is a fantastic, free alternative to tools like Monday or Asana — it helps project managers:
- Streamline complicated project processes
- Keep everyone organized and informed
- Save precious time
Plaky offers several task views — including a Kanban board that can help Agile teams organize their workflow and keep track of their progress, regardless of the size and complexity of the project or team.
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 in-house, or remote teams.
It 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, and always will be, free of charge, you can try it out yourself anytime you like.
Conclusion: Agile projects are more 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 is Scrum.
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.
References
- Association for Project Managment. (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/
- Digital.ai. (2021). 15th state of Agile report: Agile adoption accelerates across the enterprise. https://digital.ai/resource-center/analyst-reports/state-of-agile-report
- 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
- Highsmith, J. (2009). Agile project management: creating innovative products (2nd Ed.). Pearson Education.
- IPMA. (2019, May 15). Findings of the 13th State of Agile Report. Retrieved March 1, 2022 from: https://www.ipma.world/findings-of-the-13th-state-of-agile-report/
