Crossing a Gantt Chart With a Kanban Board: Agile-Waterfall Hybrid in Project Management

Crossing a Gantt Chart With a Kanban Board: Agile-Waterfall Hybrid in Project Management

When you’re mapping out a project, do you ever find yourself getting caught in a web of “shoulds” and “musts”?

“We should let the team work independently, but we must let key stakeholders oversee and gauge progress.”

“We must stay within budget, but we should allow for the flexibility to adjust and tweak the deliverable.”

The waterfall and agile methodologies provide clear, but very different, guidelines for project planning. Waterfall has more of a linear, fixed approach, whereas agile is about working in small batches, reflecting, then pivoting. And dancing in and around these guidelines is a real trick.

Each approach has fierce defenders and critics as well. Take Jay Sutherland, who developed the agile scrum framework: “[Waterfall] is slow, unpredictable, and often never resulted in a product that people wanted or would pay to buy.”

That’s a pretty scary outcome! You certainly don’t want to pull out a gantt chart if this is the result you’re going to get!

But, then, taking a purely agile approach means never having a timeline and budget at the get-go. Is this really possible in every scenario?

Sometimes, when you’re stretched between the “rules” of a project management methodology, and the requirements of the project at hand, the path forward is to silence the critics and, as Frank Sinatra would say, “do it my way.”

How do you determine if your project requires a combination of both agile and waterfall? It has to do with asking the right questions at the beginning.

Definitions of Agile and Waterfall

Software development and project management have many approaches. Perhaps it’s an oversimplification to divide them into the two camps of agile and waterfall. Within agile, for example, you have scrum, kanban, lean, crystal, and extreme programming, each with distinctive practices, ceremonies, and tools.

Nevertheless, waterfall and agile represent two central, and in some respects opposite, approaches, so let’s briefly define each, and look at their pros and cons.

Waterfall

Waterfall is a big-picture, top down approach to project management. The leader determines the goal, and then working backward, plots all of the steps to achieve it. The budget and timeline are set from the start.

Success is measured by how well the team stays on the pre-set course, and whether or not it fulfills the criteria outlined in the contract.

Waterfall is great in that it provides certainty around the scope, budget and timeline. Oftentimes a client has fixed requirements, and so waterfall assures them of key milestones and a delivery date. It also sets deadlines for a team to work toward.

However, large waterfall projects suffer from a phenomenon you might call over-planning. It’s impossible to predict every step in a monthslong project, and so oftentimes the plan provides an illusion of certainty. After a few months, the team easily gets way behind, and is forced to work long hours to meet deadlines.

Additionally, its fixed, myopic structure often leads to an outcome where a team has worked and worked to create a deliverable that the end user doesn’t even like, or never uses.

Agile

Agile is an iterative approach to project management, where an autonomous and self-motivated team produces work in small batches. After seeking feedback from key stakeholders, it reflects, then creates more work. Success is measured by a team’s ability to maintain a continuous pace of work from one iteration to the next, and by feedback from the client.

Agile’s collaborative approach means all stakeholders communicate with the development team throughout the project; they get to see ongoing progress and aren’t holding their breath up until the end. The deliverable, then, is more likely to suit the client’s needs.

However, since the team reflects and pivots at the end of each sprint, an agile team can only look four to six weeks ahead. It can’t work around a fixed timeline. And an agile project can’t have a budget at the beginning of a project, as the method permits changes to the deliverable, even late in development. Since an agile team works independently, a manager cannot oversee and course correct, either.

As you can see, waterfall plans a project very differently from agile. Each method has distinct benefits and drawbacks.

6 Questions to Measure a Project’s Agile-Waterfall Meter

It’s really rare that a project would fit perfectly into a pure agile or waterfall approach. Most, rather, fall on a spectrum between the two.

For example, when a project has hard deadlines and a huge initial investment, a lot of planning needs to take place at the beginning. But, if the project entails research and discovery as well, the plan would also require some flexibility.

Determining where your project falls on this spectrum means asking the right questions at the beginning. Here are some to cover.

1. How Much Innovation Does the Project Require?

Sometimes, a project has a pretty clear goal with a definite list of requirements. Consider building an airport. Right from the start, it’s easy to delineate everything that needs to be accomplished, from runways, to departure gates, to luggage collection, to waiting and dining areas. Of course there will be some unknowns, possibly related to regulations or weather delays.

But in a scenario like this, where most of the project is known from the start, a waterfall approach to planning makes the most sense.

However, other projects have a big question mark around the final deliverable. Consider a marketing campaign for a new product. Determining the content of the advertising, where it’s broadcasted, and even the audience, requires extensive research into the customer, and their preferred methods of communication. Plus, the deliverable is likely to be adjusted depending on how the market responds to the advertising.

That is to say, you can’t plan for requirements at the beginning if you have no idea what the final product looks like. In these instances, an agile approach, which allows for pivoting and adjusting, works better. You can elevate your Agile methodologies skills and open yourself to various job opportunities by becoming a Certified Scrum Master. It’s easy! Opt for a CSM Certification training, and you’re good to go!

2. How Certain is the Scope?

Some projects have such a clear deliverable that the scope isn’t likely to change much at all. Plus, the final deliverable is fairly stable.

Consider building a dock. From the beginning, it’s fairly easy to determine the size and the exact materials required. Additionally, the dock may well last twenty or thirty years, with minimal repair.

When the scope is clear, and the final deliverable is stable, then a predicative waterfall approach is the way to go.

On the other hand, many projects require constant updates and tweaks, even during the production phase. Something like software needs updates as soon as it’s released, and periodically thereafter.

These projects benefit from an agile approach, which anticipates making changes late in the game, and pivoting if necessary.

3. What is the Impact of Making Changes?

On some projects, making an adjustment is hugely disruptive and expensive. Consider laying the foundation of a building. Making changes to its size and location after it’s already been laid incurs huge increases to the project’s cost and timeline.

In this instance, you can’t just wing it. It’s crucial to plan everything carefully at the beginning.

With a project for something like a software system or an app, however, it’s relatively simple to adjust buttons and tweak features. This doesn’t add a lot to the project’s scope.

In these instances, where you’re looking for more flexibility, and changes don’t make a huge impact, then a flexible agile approach wins the day. Over-planning only gets in the way.

4. How Final is the Deliverable?

Sometimes a project’s deliverable is pretty set in stone. To get literal, consider a stone walkway up to a house. It’s not really going anywhere after it’s completed. In this instance, it’s necessary to study the project beforehand, which means taking a structured waterfall approach.

Other times, the deliverable can change rather easily. For example, a marketing campaign can be delivered in piecemeal, and be continually tweaked to reach different audiences. In this instance, an agile approach makes the most sense.

5. Which Method Reduces Risks?

When initial investments into a project are really high, then it’s no time for trial and error. It’s necessary to plan everything out beforehand, and a lot of research needs to happen before the project even begins, in order to reduce the risk of losing the start up costs.

Other times, too much planning actually increases the likelihood of creating a sub-par deliverable. This is actually why Sutherland invented scrum, as alluded to in the introduction. Software development, generally speaking, must be open to constant change and adjustment.

When a fixed plan increases the risk of producing poor quality, then an adaptive approach is best.

6. How is the Project Limited by Safety and Regulation?

Some projects are really encumbered with legal and safety requirements, for example in the areas of banking and credit cards. When this is the case, the project manager would lean toward a structured, waterfall approach, in order to give the project a strong framework.

In sum, various kinds of projects are more suited to either a waterfall or agile approach. Asking the right questions allow you to make this determination, and in turn draft a good development plan.

Most of the time, a project is on a spectrum between the two. You usually won’t have a scenario where something is purely waterfall or agile. This is why a hybrid solution is necessary.

Models of Agile-Waterfall Hybrid in Project Management

Even after you’ve determined where a project falls on the agile-waterfall spectrum, it’s hard to know practically what the planning should look like. Do you continue with scrum ceremonies, and utilize a gantt chart at the same time?

The solution is really tailored to the individual, but here are two models of what a hybrid approach could look like in an organization.

Fixed Planning With Iterative Development

One hybrid approach that teams find effective is a waterfall approach to large-scale planning, and an iterative approach to shorter incremental development. Let me show you what it means.

On the quarterly and yearly calendar, the organization looks at where it wants to be, and plots significant milestones on a gantt chart.

Next, it takes these items from the gantt chart, and puts them into the product backlog, breaking them down into tasks suitable for sprints. Then, it organizes sprints around these tasks, and reflects and pivots, etc.

The quarterly goals may be adjusted based on the increment and feedback developed during the sprint.

Staggered Agile-Waterfall Approach

When an organization is really large, and has many departments and managers, a pure agile approach is totally unrealistic. Take a monthslong project like a website redesign. Just letting the team independently complete the project over several months wouldn’t cut it for many of the managers. They’d want to see a plan and periodic progress.

At the same time, many facets of the project require tons of research. And so the deliverable would change and adjust as the team talks with various departments around the content it wants on the website.

These requirements mean that the approach must stagger between waterfall and agile. The development is iterative for a few stages, working in small batches, seeking feedback, reflecting, and pivoting. Then, it switches to waterfall in order to meet manager requirements.

Well these are just two examples of what an agile-waterfall hybrid can look like. It’s good to experiment with a few mix ups, and to reflect on what works best for you.