5 Essential Project Management Methodologies You Need to Know

A common association people have with project management is that methodologies make up the discipline.

It’s like programming languages are to coding, which means it matters some depending on the company, but it’s not everything. It’s not even really most of it.

And sometimes, being too stuck on one particular methodology can actually be a hindrance. Many digital companies making things on and for the internet aren’t purists and will do whatever best fits the needs of the project. So should you.

When I accidentally stumbled into the world of project management, I had just a basic understanding of project management, and they came from the tools I was doing to get my work done.

For example, when I discovered Trello, I learned the art of Kanban. When I discovered Notion, I learned the art of the new way: adapting to whatever best suits the project. Project management methodologies sometimes sound like a bunch of fancy keywords that in all likelihood, you might’ve already experienced in work or even in your day to day.

So with that, here’s an introduction to some of the most popular project management methodologies and approaches:

Waterfall

There are generally two broad approaches to project management: Waterfall and Lean. Waterfall feels like an assembly line, where one thing happens after another, in sequence.

It first originated in the 1950s and is based on traditional construction and manufacturing industry processes. Waterfall doesn’t stray from the plan, aims to document and scope everything from the start.

There’s some project management purists out there who love waterfall vs lean, and vice versa of course, but generally, you can think of them as having different use cases: waterfall is great for if you have a project with a predictable outcome. You know what you’re doing and how to do it, you just need to get it done and keep everything on track.

Agile

Agile on the other hand, focuses less strictly on process and more on value. Often that means reducing waste and simplifying steps.

Agile officially came to be in 2001 with the Agile Manifesto but it has roots much earlier than that: starting in the 1970s from the software industry.

At its heart, agile is less about strict methodology and more about continuous improvement, being adaptable and collaboration. In contrast, waterfall has one person/team designated to one part of the process, with a more linear rather than cross-functional approach.

When to use agile? When you have an idea that you want to bring alive and when flexibility is important. Where waterfall follows a linear process, agile blends multiple roles and functions, tests, collaborates and documents and refines along the way.

Warning: while agile may seem more modern and less restrictive, like the cool younger cousin, there are definitely cases when waterfall works better.

If you already know the requirements and outcomes of a project—been there done that kind of thing—if stakeholders are traditional or have a more formal structure and there’s a linear feedback process established, then there’s no need to add additional complexity with a flexible approach like agile.

Scrum

Scrum is a sub-category of Agile that breaks down the process more specifically. So agile is the broad umbrella focused on iteration, flexibility and collaboration, and scrum gets more specific with how that gets done.

Within scrum, there are sprints.

A sprint is a pre-defined chunk of time - often ranging anywhere from one-week to a month, but can be as short as a 1 day sprint too. At the start of a sprint, the team will hold a sprint planning meeting to prioritize the sprint’s tasks.

Another aspect of scrum is something called a standup. It can look like a short meeting where everyone mentions, very briefly, 3 things:

• what they worked on last

• what they plan on working on today/next

• blockers

On remote teams, this can sometimes be a virtual standup by way of Slack.

Kanban

Kanban is another agile approach. It was invented by Toyota to model the lifecycle of a production line and means “visual card” in Japanese.

At the heart of Kanban is taking a visual approach to maintain a proper and manageable flow of a project. All tasks within a project are split into (and moved to and from columns) to designate its status: do, doing, done, with additional columns depending on the work (ex: in review, blocked). Taking a card-based visual approach is designed to limit the number of tasks in the doing column at any given time.

Kanban is great for tracking metrics and that’s a big part of why it’s useful. Let’s say you combine kanban with scrum (which often happen), you can easily measure how many tasks/tickets get done in a given sprint, and use that to plan for future sprints.

Hybrid

I’ve kind of hinted at this, but here we find ourselves close to the end of an introduction to some common project management methodologies and approaches… what’s left?

The hybrid approach: taking bits and pieces of waterfall, lean, agile, scrum and kanban and finding what works best for you, your project and your team.

If you work on projects at a company, it’s possible you may already be familiar with the hybrid approach.

But why use hybrid over a specific approach? Wouldn’t sticking with one thing be easier? Actually, hybrid’s shining moment and use case is if you have specific stakeholders that only need to see certain elements of the project. Then maybe a broad waterfall approach is best. But within that, it might make sense to have an internal scrum approach to get the work done. Maybe your stakeholders don’t need to see a kanban board of all tasks, but kanban gets it done.

Hybrid’s all about taking pieces that are necessary and valuable for certain aspects of a project, maintaining transparency where needed and reducing noise for communication when it’s not necessary for certain stakeholders or team members.

So which one should you learn? I’d recommend giving all of them a try. In all likelihood, unless you work for a very rigid company, you’re probably going to be taking a hybrid approach depending on the project. When a company gets big enough, there many not even be a one-size-fits-all approach and departments or product lines could have their own internal processes. It is important however, to have a general understanding of all of the above methodologies.

And by the way, you don’t have to go work for a company with a specific methodology in place to learn these project management skills and approaches.

Principles from Kanban and Scrum can apply to how you work on personal creative projects too—and that’s exactly how I got started, and how I manage to keep my creative self productive, happy and, (for the most part, at least) burnout free.