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, and continuous improvement. In 2001, seventeen 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 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.
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 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 experiences I have are common ones that you may have encountered while using a strict agile project approach:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 simply want the bottom line: Is the project on track? Gantt charts can communicate this in 30 seconds.
Rivers and Lakes: My Blended Approach Using Agile & Waterfall
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 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 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.
How I used an agile project framework with a Gantt chart
Below are the steps explaining how I would set up the Gantt chart after I’ve decided which Agile framework techniques I’m going to use in my day-to-day 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.
The highlighted item is a task that needs to be moved to a later sprint.
Move and rearrange the dependencies
Below, 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, the Gantt chart/agile chart looks something like this:
It’s crucial to have 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 A Blended Agile & Gantt Chart
Benefits for Clients
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 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.
Benefits for My Team
As for my team members, they have also gained additional benefits from using a blended 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
- 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.
- 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 awhile 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? Interested in building a blended approach with a Gantt chart? Try TeamGantt for free.