What is Agile methodology?
The Agile methodology (it's actually a movement, not a methodology) is essentially a list of principles that advocates:
- Self-organizing teams
- Adaptive planning
- Early delivery
- Continuous improvement
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.
Agile project management vs. Waterfall approach
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.
Common drawbacks of Agile project management
Some of the drawbacks I've experienced are common ones you may have encountered while using a strict Agile project management approach:
- Loose requirements make many stakeholders uneasy. Agile 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 the final end product is very different than what stakeholders and the project team may have envisioned.
- 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, these very same people are the ones who also request to add new features to the product.
- Agile 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.
- Your estimates don’t hold their weight. Dates are fluid with Agile and it can be hard to communicate 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.
- Agile documentation is internal. Gantt charts are tried and true. Try showing a burndown chart to your stakeholders. The questions I'm frequently faced with can be depicted with a gantt chart. I've tried maintaining both a gantt chart and a burndown chart, but it became too cumbersome.
- 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 isn't an issue for the project team, it usually doesn’t work out like that for external stakeholders. Often, they’re too busy or don’t have the expertise. They simply want the bottom line: Is the project on track? Gantt charts can communicate this in 30 seconds.
My blended approach using Agile and Waterfall methodologies
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.
How to use an Agile project framework with a gantt chart
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.
1. Create task items per feature
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.
2. Move and rearrange the dependencies
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.
Why I stick to a blended Agile and gantt chart approach
Benefits for clients and stakeholders
Clients and stakeholders really need the comfort of a plan. Here are some benefits of using this approach with clients:
- 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 every day following a Scrum, it shows project progress in an intuitive way.
- Clients know when to expect components of the project to be completed, and they know when they'll be expected to conduct their testing. There's a clear roadmap of how we would reach the final product.
Benefits for my team
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:
- 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 timeframe 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.
- No two projects are the same, and this blended approach allows me to customize how I run every project. I can select techniques that are efficient and balance 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 a handy tool I can use to educate 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 even more time to accept it. But since then, I’ve been able to enjoy greater project success.
Interested in using a gantt chart for your next Agile project?
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:
- Drag and drop simplicity
- Easy team collaboration
- Customizable views
- Team availability & workload management
- Planned timeline vs. actual timeline
- Dedicated mobile app
Best of all, it’s wrapped up in a simple and intuitive interface your team and stakeholders can easily navigate.