Whether you’re a developer, product designer, or project manager, you’ll likely be asked to work with one of several commonly-used project management methodologies over the course of your career.
If you’re required to use a particular project management methodology, it helps to know what its advantages and disadvantages are to ensure a successful delivery.
If you’re in a position to choose your own methodology, you’ll likely find that some of them suit your work process better than others, or are more suited to the type of project in front of you. Understanding the way these methodologies work, their strengths, and their weaknesses is a huge asset when choosing a methodology.
We’ll walk you through the pros and cons of the two most popular project management methodologies: Waterfall and Agile.
Waterfall Project Management
Waterfall project management is a sequential, linear process of project management consisting of several discrete phases. No phase begins until the prior phase is complete, and each phase’s completion is terminal—Waterfall management does not allow you to return to a previous phase. The Waterfall model is so named because each phase of the project cascades into the next, following steadily down like a waterfall.
Waterfall project management has its roots in non-software industries like manufacturing and construction, where the system arose out of necessity. If you’re building a house, you can’t put windows in until the framing is complete, so the rigidity of Waterfall project management makes sense. Some of the industries that regularly use the Waterfall model include construction, IT and software development.
It’s easy to teach Waterfall project management—it only requires that each step be put into order. It’s also very easy to manage, as progress is obvious and steps are completed one by one. It can be seen as the simplest methodology, and it’s difficult to get wrong.
The weakness of Waterfall project management is the same as its strength: each step has to happen in linear order. This means there’s no room for shifting requirements.
Project Managers prefer to use Gantt charts to show the progress of the project. A Gantt chart is like a bar chart that provides a visual view of project tasks scheduled over time. It’s a useful way of showing what work is scheduled to be done on specific days. It helps project managers and team members view the start dates, end dates, task dependencies, critical path and milestones of a project schedule in one simple stacked bar chart.
Phases of Waterfall Model
Requirements: The manager analyzes and gathers all the requirements and documentation for the project.
System design: The manager designs the project’s workflow model.
Implementation: The system is put into practice, and your team begins the work.
Testing: Each element is tested to ensure it works as expected and fulfills the requirements.
Deployment (service) or Delivery (product): The service or product is officially launched.
Maintenance: In this final, ongoing stage, the team performs upkeep and maintenance on the resulting product or service.
Benefits & Disadvantages of Waterfall
Training is simple
Easy to show progress
Intuitive to manage
Not flexible with shifting requirements or change. Everything in the project is tied and the design has been finalized, so changing any requirements could mean a long approval and change management process
Difficult for complex projects with dependencies
Slow feedback cycle. The deliverable is only delivered at the end of the phase so if an error happened in the beginning or middle of the phase, the team may not be aware of it until the hand-off the product and then get to know the feedback.
Waterfall Model Key Terms
💡 Critical path
In project management, a critical path is the sequence of dependent tasks that form the longest duration, allowing you to determine the most efficient timeline possible to complete a project.
The diagram above shows that the duration of the project will be the sum of duration of each of the activities that falls on the critical path (Activities 1, 2, 3, 6, 8, 9 and 10).
Milestones are markers in the project's schedule signifying important events or goals. These could be the events that engineering manager or leadership may be tracking. The top management in a company may not have time to look at the daily progress of the project, but milestones are something they will keep track off.
Agile Project Management
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. Agile project management focuses on delivering maximum value against business priorities in the time and budget allowed. There’s a reason it has become the go-to methodology for developers, where the drive to deliver is greater than the risk.
In order to understand this methodology, you’d need to understand and internalize the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We’d also highly recommend reading through the 12 Principles of Agile.
Responding to change - Agile welcomes changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Accepting uncertainty - Based on agile manifesto, the team believes in responding to change over following a plan.
Faster review cycles - The working software is delivered incrementally and there is continuous collaboration between team members.
Less work up-front.
Lack of shared understanding - Requirements can change and sometimes the information may not flow to all the team members
Unpredictability - The design or product evolves with time, so the clear picture is missing in the beginning
Scaling up can be challenging
Practically speaking, how do people in the real world apply Agile principles to their projects? While Agile principles can be applied to pretty much any approach, these are the most common Agile frameworks.
While Agile is a mindset, SCRUM is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It describes a set of meetings (Scrum events), tools (Artifacts), and roles (Teams) that work in concert to help teams structure and manage their work.
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum.
Successful use of Scrum depends on people becoming more proficient in living five values:
Commitment, Focus, Openness, Respect, and Courage
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
For the Product Backlog, it is the Product Goal.
For the Sprint Backlog, it is the Sprint Goal.
For the Increment, it is the Definition of Done.
Extreme Programming (XP)
Extreme Programming (XP) is an Agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is recognized for its Values, Practices and Roles.
XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development, it is a discipline of software development based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
The five values of XP are communication, simplicity, feedback, courage, and respect.
The core of XP is the interconnected set of software development practices listed below.
The Planning Game addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next.
Small Releases means the team releases running, tested software, delivering business value chosen by the Customer, every iteration.The most important aspect is that the software is visible, and given to the customer, at the end of every iteration.
Metaphor is a simple evocative description of how the program works, like “this program works like a hive of bees, going out for pollen & bringing it back to the hive” as a description for an agent-based information retrieval system.
Simple Design means building the simple solution first, and not abstracting before needed.
Testing builds tests against acceptance criteria and uses them to prove to themselves, and to the customer, that the feature is implemented correctly.
Refactoring - Design improvement and removal of duplication (a sure sign of poor design), and on increasing the “cohesion” of the code, while lowering the “coupling”
Pair Programming - All production software in XP is built by two programmers, sitting side by side, at the same machine.
Collective Ownership - any pair of programmers can improve any code at any time, no one person is responsible for knowing how one area of the codebase works.
Continuous Integration - multiple builds per day keep the system fully integrated at all times.
40-hour week - work life balance makes better software
On-site Customer - Customer is involved with requirements and review of delivery.
Coding Standard - Code must be formatted to agreed coding standards. Coding standards keep the code consistent and easy for the entire team to read and refactor. Code that looks the same encourages collective ownership.
The Customer role is responsible for making all of the business decisions regarding the project including:
What should the system do (What features are included and what do they accomplish)?
How do we know when the system is done (what are our acceptance criteria)?
How much do we have to spend (what is the available funding, what is the business case)?
What should we do next (in what order do we deliver these features)?
The XP Customer is expected to be actively engaged on the project and ideally becomes part of the team.
The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project. Your team needs to make sure that you get a complete picture of the business perspective, but have some means of dealing with conflicts in that information so that you can get clear direction.
Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer. Because different projects require a different mix of skills, and because the XP method relies on a cross functional team providing the appropriate mix of skills, the creators of XP felt no need for further role definition.
Some teams may have a tracker as part of their team. This is often one of the developers who spends part of their time each week filling this extra role. The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement. Key metrics that your team may track include velocity, reasons for changes to velocity, amount of overtime worked, and passing and failing tests.
This is not a required role for your team, and is generally only established if your team determines a true need for keeping track of several metrics.
If your team is just getting started applying XP, you may find it helpful to include a Coach on your team. This is usually an outside consultant or someone from elsewhere in your organization who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self discipline.
The main value of the coach is that they have gone through it before and can help your team avoid mistakes that most new teams make.
Kanban is a framework that provides visibility to an entire process and is commonly used for agile and DevOps to drive continuous delivery and improvement.
Instead of working in fixed and planned iterations like in Scrum, Kanban teams work on priority tasks whenever they come in. The goal of Kanban is to have a constant stream of work without any bottlenecks.
To achieve that, teams add a limit to the number of tasks that can be worked upon simultaneously (known as WIP limit), so the team doesn’t multitask and slow down productivity.
A Kanban board visualizes all the work within the project. It’s a physical or visual cork board that is split into 3-4 columns. Each column in a Kanban board represents a status of the task, ranging from ‘To Do’, ‘In Progress’, and ‘Done’.
The Scaled Agile Framework® (SAFe®) is a system for implementing Agile, Lean, and DevOps practices at scale. It helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality.
SAFe is based on 10 foundational principles. Following these principles helps you align the right people, deliver high-quality solutions customers want, and respond to threats and opportunities.
Side-by-Side Comparison of Agile Frameworks
As a consulting company, we typically follow the client’s preferred project management methodology. Internally, we’ve found Scrum and Kanban to be our best go-to project management methodologies for most projects, but that’s because those work best for the way our team operates.
We recommend trying different methodologies for your projects and finding what works best for you. Everyone has a go-to project management methodology, but you may find your favorite won’t work well for a particular type of project. It’s good to know what methodologies fit best with the project in front of you.
We hope you’ve found this guide helpful! If you’re having difficulty finding the project management methodology that works for your project, or need an expert project manager to help, contact us for Project Management Consulting.