Waterfall

There are more options than just Waterfall or Agile.

Agile methodology was developed out of a need to address common inefficiencies of more traditional project management methodologies in the software development process, such as Waterfall, but you may find that your upcoming project might actually be burdened by Agile techniques. There’s no rule that says you can only pick one and stick with it. I’m here to display myself as a proud technique blender in hopes that you may feel more comfortable doing so too.

Wait!

If you’re a staunch advocate of Agile or a strict traditionalist, you might be about ready to fire up Twitter and tweet angry things at me. But first, hear me out. Sometimes we’re so blinded by the bright, new, shiny thing that we forget that other ways of doing things once existed.

Why People Searched for Alternatives to Waterfall

Agile methodologies focuses on iterations in which planning, design, implementation and testing occur in short periods of time. Agile methodology allows planning to occur throughout the project lifecycle, thus allowing decisions to be reactive. In software development, bugs can be caught early and remediated before they grow to become bigger problems. The premise of this approach is to plan around the inevitable changes requested throughout as the product evolves.

It’s not hard to see the differences in process between the two methodologies.

Here’s the Waterfall process for generic project:

Waterfall methodology

Here’s the Agile process for a generic project:

Generic Agile Process

Sounds Great, Right?

When I first learned about Agile, I was hot to try it out. I was even lucky enough to work with someone who was a certified Scrum Master. I picked up the basics quickly, but I found that a pure Agile approach wasn’t working for most of the projects I was working on. Turns out, gantt charts are still helpful for things like planning out resources, milestones, and team notes.

Some of the experiences I have are common ones that you may have encountered:

  1. Loose requirements make many stakeholders uneasy. Requirements aren’t definitive by the time initial planning is done. They often evolve and emerge as the project is underway or as feedback from past iterations. This may mean that the final end product may be very different than what stakeholders and the project team may have envisioned.

  2. The project never ends. While this can be good for business, it can also become very frustrating. Without a clearly defined scope, stakeholders may complain that it seems as though the project will never reach completion. Often times, these very same people are the ones who are also requested to add new features to the product.

  3. It can add pressure to your team. In a purely Agile-run project, features need to be 100% perfect by the end of the iteration. Some team members experience greater stress knowing this. Many of my colleagues embrace dates because it helps them balance their overall workload. Defined deadlines can help create mental to-do lists and keep people self-policing.

  4. Your estimates don’t hold their weight. Dates are fluid with Agile and it can be hard to express timing to stakeholders. You’re more likely to encounter stakeholders who need to see a set of milestone dates than ones who can deal without them. People love dates and timing estimates. I haven’t been able to get around this and it just adds more stress whenever I used a purely Agile approach.

  5. Agile documentation is internal. Gantt charts are tried and true. Try showing a burndown chart to your stakeholders. The questions I am frequently faced with can be depicted with a gantt chart. I have tried maintaining both a gantt chart and a burndown chart, but it became too cumbersome.

  6. Not everyone is an active player. For all of the above items to not become a problem, everyone has to be very involved from day one. While that is not an issue for the project team, it usually doesn’t work out like that for external stakeholders. Often times, they’re too busy or they don’t have the expertise. They want the bottom line: Is the project on track? Gantt charts can communicate this in 30 seconds.

Rivers and Lakes: My Blended Approach

Our jobs as project managers is to steer the project from inception through completion. We make decisions everyday that affect the finished product everyday. Selecting the right approach for your project is no different. Don’t get stuck thinking you have to use one method or another. When I first made this realization, I noticed that my projects ran more smoothly.

Separate Tracks

There’s more than one way to do things.

I no longer approach two projects the same way, but I do begin with the same step. I take all background information on the project available and study it. From this information, I determine which components from both methodologies that would work best. This can be based on the attitudes of stakeholders, critical dates we must meet, technical complexity and team composition.

The most common challenge I come across is stakeholders’ focus on timing. Even if a project lends itself to naturally assume more Agile-based techniques, not having milestone dates worries most of my stakeholders. In response to this, I began to create a modified version of an Agile sprint backlog using Gantt charts.

I know, I know. The two aren’t supposed to mix. But I do and the project management police have yet to catch me. Here’s an example of how I would set up the Gantt chart after I’ve decided which Agile techniques I’m going to use in my day-to-day management.

Under each anticipated iteration, I create one task item per feature. The key deviation from a typical gantt chart for a waterfall-based project is that this chart relies heavily on dependencies. All items in each iteration have a start-to-finish dependency to the testing period for the iteration. Start-to-finish dependencies among tasks are only given if there is a technical dependency that would model how my resources would tackle the sprint. Throughout the iteration, I hold daily standups as well as planning and review meetings. From these meetings, I can determine which features to move to later iterations. When these items are moved around in my Gantt chart, the dates move automatically too.

So I begin with a chart that looks like this:

The highlighted item is a task that needs to be moved to a later sprint. So now I’ve moved it down and rearranged the dependencies. From my daily stand-ups, I’ve determined that my two resources can work on their assigned tasks simultaneously, but some of the other tasks that are also assigned will have to move back to accommodate this new addition. So now, it looks something like this:

Having a gantt tool that is flexible and super easy to make these changes on the fly. TeamGantt is a pleasure to work with. You can use the free trial to play around and see if it works for you.

Why I Stick to My Rivers and Lakes Approach

While this setup can’t produce pretty progress charts Scrum Masters are used to seeing, I do have a schedule with concrete dates that helps my stakeholders visualize the time and effort each feature requires.

I can share this with my project team, internal stakeholders and clients. This Gantt-backlog chart is a direct way of expressing responsibilities, milestones and the expected product (It also allows me to save time from completing draining PM tasks). When updated everyday following a scrum, it shows the viewer progress in an intuitive way.

Clients know when to expect components of the project to be completed and they know when they can be expected to conduct their testing. There is a clear roadmap of how we would reach the final product.

As for my team members, they can see not only what is expected of them in the upcoming iteration, but also an outline of later iterations. Certain tasks or features may be moved down to later sprints or iterations, but the gantt-format can also shed light on dependencies. They can plan for themselves and advise me on how they’d like to approach implementation. Testers can rest easier knowing a ballpark timeframes of when they’ll be needed. They can see from the chart what they’re expected to test and what not to report bugs on.

Lake

No two rivers or lakes are the same and this blended approach allows me to customize how I run every project. I can select techniques that are efficient and compromises my team’s preferences with my clients’ tendency to prioritize dates. I use this Gantt-backlog combination to drive conversations with stakeholders on how their requested changes can affect the overall timing. It also provides me with a handy tool that I can use to educate my less-savvy clients on design and development processes.

I’m proud to be a project manager that isn’t defined with a specific methodology. It took me a while to get here and then even more time to accept it, but since then I’ve been able to enjoy greater success.

Are there any other method blenders out there? What methods have you had success or a terrible time with?

Planning Your Projects Can Be Easier

Thousands of people from over 60 countries use TeamGantt to plan, track, and manage their projects! Join them in making project planning an easier part of your life.

Learn More

Try TeamGantt

Create a beautiful project plan completely free, forever.

Try Free

Plan your project in minutes

Create a beautiful project schedule in just minutes. Join thousands of others from over 60+ countries that use TeamGantt everyday.

Try Free for 30 Days