Reincarnation of the Gantt Chart

You probably think that I became nostalgic and decided to convince you to dump all the progressive ways of software development management and go back to the the dark ages.

Sorry to disappoint, but it won't be about that. The purpose of this post is to show you that although the waterfall approach had many flaws the tools that came with it are still relevant in today's agile development.

---

In the last couple of years I faced several situations when the agile toolkit was unable to address a more long term planning with long term commitments. As I mentioned in one of my previous posts, you always have long term commitments and hard deadlines. That is the reality!

One of the basic principals of using an agile method is the ability to quickly adjust according to your current situation. That means being able to postpone any content to the next cycle in case you're unable to get it done. You're provided with a lot of tools and metrics to help you plan accordingly. We're being taught that you don't plan several cycles ahead, you adjust from cycle to cycle and you always have the fallback of pushing content forward.

But, what if you can't use those tools? Consider a situation in which your team is still new and you just don't know what is their velocity, or the business needs get the upper hand over any other consideration.

I was trying to find some tool that will fill this gap.

Using Gantt chart in the agile era

When you need more control

In one of those times when my team was facing a huge pressure towards the delivery of a project. We were a startup and a lot was at stake. The backlog was big and we identified only the important things we will develop, but we had to make sure we'll be able to deliver them. Unfortunately, the timeline was over several sprints and we had to plan them upfront taking into considerations some other projects the team was working on. My mentor at that time and a very good friend, told me that I should create a Gantt chart. At first I was horrified and reluctant to agree. It was against all what I believed in, we were using Scrum and it was working great. I was sure that I can use the tools Scrum gives me to solve the problem. But I couldn't answer all questions and we had major customer waiting. With multiple projects falling on the same team, I felt I'm running out of options.

I took a huge whiteboard and drew my first Gantt Chart in years.

Thanks to that, I was able to visualize the entire set of work for the next couple of sprints and identify the right way to plan them. As a result we managed to delivered successfully.

That was when I realized that this tool, which was used for planing huge projects that might span over years of development, was designed to take into consideration a lot of variances, making it a perfect tool to solve my problem. Although I stepped outside of the "Scrum way" it payed of.

Planing the first release

The first release of the product is usually the most significant one. It's a time with the most uncertainties but also with the most pressure on commitment and content. It's often important to get to the market with a valuable product.

"You never have a second chance to make a first impression", Oscar Wilde

Even if the development is conducted based on some agile method, you want to have a high level plan that catches the entire release in order to make sure that it's even possible.

Creating a Gantt chart at that point in time will give you just that.

Yes, this is a very "waterfally" approach, but you'll quickly see if you need more resources or if your preliminary assumptions are correct. That can have an affect on your entire approach.

Once you have the general understanding, you should lock it away. You don't want it to replace your other planing and progress management processes. Use Gantt to address a specific problem.

Self assessment and retrospective

It's not a rare occasion in which you need to know your status against your initial commitments. Either you're required to report it to your management, or you want to make self assessment in order to understand if you're getting any closer to your goals.

The best thing you can do is take the Gantt chart you created when you planned the first release and update it to the current situation. It'll probably be very different, as you adjusted throughout the agile cycles, but once you update it you'll have an insight into several important aspects:

• How much you deviated from the original planing?

and

• How close are you on your initial goals?

The first insight will provide a huge retrospective towards your future plannings. You will see if you have a good understanding at the beginning of the project and what are your improvement areas. It'll also provide you with good data in case you'll need to explain what was your deviation and the reasoning for it.

The second insight will give a sense of how far are you from your goals against the timeline. This can become a trigger for you to shift into a more controlled planing mode for the rest of the release, same as what happened to me.

Conclusion

All processes and methods are invented as tools for solving a problem. Even if you're using a certain method, the reality makes you face problems that require applying tools outside of your toolkit. Sometimes using tools that considered obsolete or even bad practice are the best choice and you shouldn't dismiss them just because they don't fit the narrative of your current process. Gantt is one of those tools.