Chopping down a tree is easier if you take time to sharpen the ax. So before I dive into a project, I always try to consider which type of project management approach is going to work best.
For me, a traditional or "waterfall" project management style—where I divide the project into steps and then move through the steps one at a time—typically makes sense. But in more complicated industries like product development, or when managing a project that incorporates multiple teams and sub-projects, a sequential approach can be a hindrance that causes delays and confusion. That's where "agile" project management comes in.
Before you dive in: there are a number of specific project management terms used throughout this explanation that you may or may not be familiar with. Hop down to our glossary to find definitions.
What is "agile" project management?
There are a few different management concepts that fit into the larger umbrella of agile methodologies. The three most popular agile "categories" are Agile, Kanban, and Scrum.
Agile, Kanban, and Scrum aren't three different project management styles.
Agile is a project management philosophy.
Kanban is a project management tool.
Scrum is a project management methodology.
In theory, a project could employ Agile, Kanban, and Scrum simultaneously—none of the three are incompatible with each other. But each concept can also be used separately depending on what the project's priorities are.
Usually, agile methods are most popular in industries where projects contain many moving parts and a lot of unknowns, like product and software development.
Agile vs. traditional project management
Traditional project management is also called the waterfall method because of the way the project moves through different stages one at a time—the same way water flows over a series of waterfalls. Each phase of a waterfall project needs to be completed before the next one can begin. You could also think of waterfall as a relay race or a simple assembly line.
Waterfall has several limitations that don't work for more complex projects:
It requires a lot of upfront planning to put phases in order, write a sequential timeline, and schedule teams.
You can't put multiple teams to work simultaneously, which can be an inefficient use of time and resources.
Delays in one phase result in delays to the whole project.
Some projects can work within these limitations, but project managers can still draw from elements of agile management to add some flexibility into their workflows.
What is Agile?
Agile (with a capital "A") is the original agile management philosophy. It came about as a result of an informal conference of planners who gathered in early 2001 with a mission to innovate project management to adapt to the rapidly growing software development industry. The meeting produced a document called the Manifesto for Agile Software Development, which outlined four key values of agile management:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile is also called "iterative" project management. Instead of breaking your project down into phases that have to happen sequentially, you split your project up into smaller projects and ship each one as a step toward reaching the full goal. You'll plan the broad ideas of the project and divide it up, then plan, design, build, and test each part of the project individually. That lets you ship faster, and makes it easier to adapt the project along the way.
The benefits of Agile management include:
Faster delivery times
The ability to continuously incorporate customer feedback and adapt to market changes
The tradeoff is that Agile projects are more susceptible to scope creep, as the parameters of the project aren't strictly defined. If you're not careful, tasks will get added to the project, and it'll balloon into something unmanageable.
Agile is best for:
Dynamic projects with many moving pieces
Projects that need to incorporate changes as they progress
Teams with a highly collaborative working style
Agile is kind of like a team scavenger hunt. The items on the list don't need to be found in order, and the entire team doesn't need to help find each and every one, so you're better off splitting the list up and having parts of the team work on finding different things at the same time. If one group runs into trouble or gets stuck, the other groups can keep working—it allows the team as a whole to keep progressing even if a part of the team hits an obstacle.
Since Agile is a philosophy rather than a methodology, really any project management platform that isn't waterfall/Gantt chart-only will work well for Agile projects. Jira was purpose-built for agile software development teams, but other software like ClickUp, Zoho, Asana, Wrike, and Trello are also compatible with Agile methodology.
What is Kanban?
Kanban isn't a separate agile methodology: it's an approach that can be used in tandem with Agile and other flexible project management styles.
In fact, Kanban was developed long before agile project planning was even a thing. It was first developed in the 1940s by a Toyota executive named Taiichi Ohno, and is today recognized as an "agile" project approach because it prioritizes similar values like adaptability, efficiency, and improved collaboration.
The Kanban approach is a means of visualizing a project's status and progress via Kanban boards. (The Japanese word "kanban" means "billboard.") A Kanban board is divided into columns representing different stages of completion, like "not started," "in progress," and "complete." Tasks are sorted into columns and tagged with information, like priority level, person working on it, and project status.
Your Kanban system can be as flexible as you want—it's really just a way to visualize the Agile idea—but there are four pillars of the Kanban philosophy that can help make sure your projects get shipped. These include:
Cards: Each task has a card that includes all relevant info about it; this makes sure everything needed to complete the tasks is always at hand.
Cap on work in progress: Limit how many cards are in play at once; this prevents teams from over-committing.
Continuous flow: Move down the list of backlogs in order of importance, and make sure something's always being worked on.
Constant improvement (otherwise known as "kaizen"): Analyze the flow to determine how efficiently you're working, and always strive to improve it.
Kanban is compatible with, not an alternative to, other agile methodologies. Often, Agile and Scrum teams will maintain a Kanban board that can be used throughout the projects, and then they'll have Scrum sprints to keep track of what's happening with each task in the project and make sure work isn't being missed or duplicated.
The tradeoff is that, because Kanban is compatible with many different project methodologies, it doesn't inherently eliminate bottlenecks the way that Scrum does. If the top card in your "To Do" list falls behind and the remaining cards in the list can't start until the top card is completed, it will still cause delays.
Kanban is best for:
Projects involving many teams and players
Distributed teams that need a central project plan
Teams that prefer highly visual project and progress tracking
If you're the type who always starts their project with a big whiteboard, or who maintains a massive wall of Post-it notes, or if your project management system ever makes you feel like you're looking for Pepe Silvia, then Kanban boards are for you.
Trello made its name as the original digital Kanban tool, but nowadays many project management platforms offer Kanban views alongside calendars, Gantt charts, and task lists. Asana, ClickUp, and Azure DevOps, among others, all offer drag-and-drop functionality to move cards between lists on a board.
What is Scrum?
Agile is an approach and Kanban is a tool; Scrum is an actual methodology with clear steps and a defined structure.
Many different project styles can fit into the definition of Agile, but Scrum is the method that most people think of when they're thinking about Agile management (which is why the two are so often confused). A Scrum project follows the following structure:
The project manager, or "Scrum master," works with the team to identify the set of tasks to be accomplished and organizes them into a "product backlog." From this, they will pull a smaller set of tasks into the "sprint backlog," which is the chunk of tasks that the team will focus on in the sprint.
The team enters a finite period (typically two to four weeks) called a "sprint." The entire team works through the sprint to complete the tasks in the product backlog, but there's no predefined map or order of priorities for completing these tasks.
Each day of the sprint, the Scrum master holds daily standups, quick meetings at which members of the team report progress and different task needs are discussed.
By plotting next steps in these short increments, Scrum keeps sprints flexible and capable of adapting easily to changes, problems, or delays.
At the end of the sprint comes the "sprint retrospective," during which the team reflects on what went well and what didn't, so that these learnings can be applied to future sprints.
Scrum is best for:
Teams with complex, multifaceted objectives
Projects in inherently dynamic industries, like development and tech
Teams working on a product that is actively being used or tested by customers providing feedback
Scrum is the tool to use if your projects change so frequently that they start to feel a bit like a game of Whack-a-Mole, with tiny changes and updates appearing too quickly for a less flexible project management system to adjust.
The best software platforms for Scrum teams are purpose-built for sprint planning and offer features like backlog management and the ability to organize product versions, features, and releases. Many project management platforms are capable of Scrum compatibility, but some of the most popular are Zoho Sprints, monday.com, Wrike, and Jira.
Agile hybrids: Lean, Six Sigma, and PRINCE2
In addition to the three main agile management categories, there are also agile hybrids that combine elements of agile philosophy with more traditional management methods. The three main hybrids are lean, Six Sigma, and PRINCE2.
Lean project management
The lean approach was also created by Taiichi Ohno while at Toyota, and, much like Agile, it's a management philosophy rather than a methodology. Lean is compatible with both agile and traditional methods, and its primary purpose is to reduce waste throughout the project life cycle.
Ohno defined seven different "mudas" (Japanese for "wastes") that the lean approach looks to mitigate:
Overproduction, or wasted product
Overprocessing, or wasted energy on activities that don't add value
Wasted transportation, or unnecessary travel that doesn't add value
Wasted motion, or unnecessary wear and tear caused by unnecessary movement
Wasted product caused by defects
With lean project management, you'll still break up your project into smaller pieces of work that can be completed individually. You'll also define a workflow for each task, which helps reduce waste over repeated workflow cycles and helps ensure each part of a project is produced at the same quality.
Six Sigma's concentration is on quality control, which is implemented through continuous improvement based on data analysis.
There are six steps to the Six Sigma approach, known as DMEDI: Define, Measure, Explore (or analyze), Develop (or implement), and Control (or improve).
Define: Determine the scope of the project, get information from all sides, and determine what the business goals are (for example, sales).
Measure: Establish the nature in which the team will calculate progress—your overall goals. Seeing the rate of success—the value to the consumer as well as the business—as a quantifiable thing is at the core of Six Sigma.
Explore: Figure out the ways in which the team can meet and exceed product requirements.
Develop: Put a detailed strategic plan in place.
Control: Perform a documented review full of lessons learned and apply takeaways to future projects.
It's much like a Kanban approach, except that you don't define the stages yourself—they're always the same, and they ensure that you plan, define goals, and test for quality at each stage.
You'll likely end up with more meetings than Kanban calls for, but you'll also have a far more structured way to approach each task, which allows for stricter and better quality control.
PRINCE2 stands for PRojects IN Controlled Environments. It was originally developed for the UK government, and it shows: PRINCE2 is strict and regimented, with clearly defined steps, roles, and responsibilities. It's the system I would use if I had to organize a Buckingham Palace guard change.
PRINCE2 throws sprints out the window, and instead approaches a project as one big sprint. It also stresses quality of delivery—like a traditional project management version of Six Sigma. The framework is more focused on the ends rather than the means; what's expected of the end product will determine the scope and shape the planning.
There are three interests at play with PRINCE2:
Business interest (is it going to make money?)
User interest (will customers find this valuable?)
Supplier interest (do we have what we need to make this happen?)
PRINCE2 has a more clearly defined personnel structure than most project management systems. Each team member has specific roles, which carry through all seven of PRINCE2's stages: Startup, Direction, Initiation, Control, Boundary Management, Planning, Delivery, and Closing.
Startup: First on the agenda: leadership chooses a project manager and clearly relays everything that they expect the product to be. The PM, whose main focus is the fine details, reports to the project board, which puts together the project's direction. The project board steers the course of the project and is ultimately accountable for its success. The remaining members make up the team.
Initiation: During this step, the project manager writes the "initiation document," a plan to bring the project into reality. Once the project board signs off, it's time for the control stage, when the project is divided into phases. These phases don't have to last the same amount of time; the duration of each is determined by what each realistically demands. Like with the waterfall approach, a phase must be completed before moving on to the next one.
Direction: It's not enough to have oversight—you also need to know exactly how a project should be overseen and managed. The direction phase sets the overall management structure for the project, outlines how each stage should progress, and what should happen if something changes along the way.
Control: Some amount of change is inevitable, which is why PRINCE2's per-stage review can be helpful. The roadmap for each phase is determined by the review of the previous one. So while there may have been a general plan, that can be changed if a review shows a need for something else. Once again, the project board has to sign off on this—bringing double the meaning to the "Boundary Management" stage.
Boundary Management: The management stage looks at product delivery: what's going out (for example, what features will an app keep or chuck?), how is it going out, and does the product that's going out meet all requirements?
Delivery: From a project manager's perspective, this is where the most important oversight takes place. As work begins on product delivery, the project manager is in charge of making sure that everyone is doing a job that aligns with the project's goals and getting approvals once parts of the project are completed.
Closing: After everything is said and done, the closing stage still remains. Closing is an in-depth analysis of how the project fared. This is put into a report, which also has to be approved by the project board.
That may be a bit much for some projects, but you can customize the stages for your needs, while still keeping the same general idea of PRINCE2's structure, planning, and reporting back to upper management.
Glossary of project management terms
Agile: An iterative form of project management where tasks are completed through specific phases
Critical path: The list of the critical tasks that must be completed before a project is finished; together, they show the total estimated project time
Event chain diagram: A bar graph of events in a project and the order they'll be completed based on resource availability
Float: The amount of time a task can be delayed without causing a delay to subsequent tasks or the entire project
Gantt chart: A bar graph and calendar fusion that shows the time each task in a project will require; a form of an event chain diagram that's focused on time.
Milestone: The time when important tasks in a project are completed
Project manager (PM): The team member whose top responsibility is to plan, carry out, and close a project.
Resources: Elements required to complete a project, including time, equipment, supplies, team members, and other resources
Scope: The definition of what the project will cover; when this grows during the project, it's called "scope creep"
Sprint: A period of time in which a certain part of a project is created and shipped
Traditional Project Management (TPM): Basic project management where tasks are completed one after another
The best project management system for you
Project management may be a science, but it's not a precise science—there's no set-in-stone, one-size-fits-all project management method. You might be lucky and have a project that exactly fits one of these methods, or you may need to build your own hybrid system—or a brand new one, as the Apollo team did in their quest to get humans to the moon and back safely.
What's important is that you use something to manage your projects, that gives your work structure and ensures you don't miss anything crucial.