The Agile methodology (it's actually a movement, not a methodology) is essentially a list of principles that advocates:
In 2001, 17 software developers met and worked together to publish the Manifesto for Agile Software Development. They felt there had to be a more efficient way to develop and deliver software that allowed more autonomy to the developer.
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 some types of projects 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.
If you’re a staunch advocate of Agile methodology 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 traditional project management techniques are still very useful.
Hear more about Agile—including where it works well, where it breaks, and how to put it into practice when you don’t have time to be trained—in our interview with Certified Scrum Trainer and all-around Agile guru Dave Prior.
Agile project management methodologies focus 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 a generic project:
Here's the Agile process for a generic project:
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 drawbacks I've experienced are common ones you may have encountered while using a strict Agile project management approach:
Our jobs as project managers is to steer the project from inception through completion. We make decisions that affect the finished product every day. Selecting the right approach for your project is no different. Don’t get stuck thinking you have to use one project management method or another. When I first made this realization, I noticed that my projects ran more smoothly.
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 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. That's why 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 are the steps I follow to set up the gantt chart after I’ve decided which Agile framework techniques I’m going to use in my day-to-day project 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 stand-ups 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.
In the gantt chart example below, the highlighted item is a task that needs to be moved to a later sprint.
Below, you can see that I’ve moved the task 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, the gantt chart for this Agile sprint looks something like this:
It's crucial to have a gantt tool that's flexible and super-easy to make these changes on the fly. An online gantt chart software, like TeamGantt, is a pleasure to work with, and their free trial allows you to play around to see if their project planning software works for you.
Clients and stakeholders really need the comfort of a plan. Here are some benefits of using this approach with clients:
As for my team members, they have also gained additional benefits from using a blended Agile and Waterfall project management approach. Here are just a few:
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 even more time to accept it. But since then, I’ve been able to enjoy greater project success.
TeamGantt makes it easy to create customized project plans that fit every project just right. You’ll have all the features you need to ensure projects finish on time and under budget, including:
Best of all, it’s wrapped up in a simple and intuitive interface your team and stakeholders can easily navigate.