Gantt Charts vs Scrum Agile Processes

This week while catching up with a little technology and media news, I came across a recommendation at the end of the article. This was a link to a blog written in 2010 titled ‘The Blueprint for Your Project’s Success – A Project Charter‘.  The advertising company Outbrain had targeted me accurately and knew this was a topic I would have an interest in, and despite its age, I think the article is still providing some value, and, despite it primarily being a product placement – Seeing Gantt charts mentioned got me thinking, how can a tool which is essentially a relic of the 1st World War still be circulating as part of a blueprint for success? I remember this was a question also asked in a project management book ‘Scrum: The Art of Doing Twice the Work in Half the Time‘ by Jeff Sutherland. Blog posts on pmi.org also warn that “tools are like the proverbial ’emperor’s new clothes.’ The better they dress with fancier Gantt charts”.

You’ll not see a Gantt chart appear in a Scrum project. However, I would support that article and suggest using them on high-level dependency management, controlling workstreams or where you need to plan for multiple projects or application releases.

While it can help communicate better, even for a small project, I also want to look at how cumbersome they are for planning. Here is what a simplified Gantt chart for my recent web app project would look like.

My choice to place design and at the end might not have been the best. Had this been presented to a team at the beginning, that might have come up in the discussion, because it is immediately visible, but, that is dependent on the circumstances, i.e. I have a background in corporate projects where design is not so important and there usually we try to prove a solution works early. If you are building an application that needs to be sold in an app store, then you would be best spending much more time on design upfront.

Using Gantt charts the tendency is to try to organise each step the team will need in great detail, which if your diligently updating week for week, not only will amount to a lot of work, but you won’t be making use of the team’s expertise and there will be a lot of guess work. I’ve been in projects where the design work held up work for several months, it kept us from actually building the product. Gantt charts just don’t help improve efficiency and concentrate enough on the minimum viable product (MVP), using Scrum you might have broken down the design into one screen and could have had something to look at very quickly, which is the reason why I would stay away from using a Gantt.

Generally building an application as fast as possible is just not going to happen by using a Gantt chart. If you’re using Scrum processes, then you are reviewing and reordering work items on a weekly if not daily basis. Working with a Gantt chart you plan everything out and map progress as you go along. The biggest problem then, is that you start estimating how much time each step will take, which in any project can be somewhat difficult – some, even go as far as planning hourly tasks. I’m amazed people still think that way of planning works. In Scrum that is avoided by comparing work items based on complexity and unknown factors which the team might need to figure out.

Either way, I think we will be seeing Gantt Charts for a while yet. Having just listed several negative points, I wouldn’t write them off altogether, even in a Scrum project there is a need to track how epic stories are progressing.