Blog

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.

It can help communicate better even on a small project, they are usually touted as being cumbersome for planning and they can be as anyone who has used Microsoft Project might know.

Have a quick look at this simplified Gantt chart for my recent web app project.

gannt chart of a small project

My choice to place design and at the end might not have been the best.

Had this plan 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 guesswork.

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 don't concentrate enough on the minimum viable product (MVP), using a Scrum backlog you might have broken down the design into one screen and could have had something to look at with a customer 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.

Blog

Web App Project: Sprint 8

Over the last 8-weeks, I used parts of Scrum primarily on a one man project. I used a product backlog, estimated stories, had my share of great and bad sprints, made a demo every week and even carried out retrospectives. You can certainly apply Scrum processes to small projects, even on your own, but, I would warn anyone trying to do this, that unless you have an accountability system, such as weekly meeting with a customer or product owner, then you are very unlikely to follow through.

I didn’t realise in writing the final blog on this web app project, that I’d become apprehensive. So far I’ve had no feedback through comments on my blog or youtube channel. I had hoped for an honest discussion.

This experiment was a way for me to share parts of the Scrum process without having a team, Scrum master and product owner. I’ve been trying to avoid prescribing what is right or bad, there are just too many people doing that, nobody wants to be Chet Rong, the world’s worst agile coach, which is a funny video in itself, but I can tell you from many years using Scrum myself, that even badly implemented you can still reap benefits.

Anyone considering using Scrum processes should expect resistance if trying to get freelancers and contractors to work in this kind of team. I think that it boils down to them worrying about being micro-managed. I can assure you that this is not the case and that through the planning and retrospective meetings you both have a good 2-way communication from business to IT, vice-versa, and will be making improvements on a sprint to sprint basis.

Speed Comparison App

For this project, I only used tech that was new to me, including; the Ember.JS framework for the app, Node.JS for a microservice, Docker,  Google Cloud Platform, Kubernetes and NGINX. It wasn’t until the last couple of sprints I began to gain traction on the frameworks I had chosen. For example, the goal in the last week was to integrate a bootstrap theme which I completed relatively quickly. Obviously it takes a bit more work to get an application to look really great.

With any new technology, framework or programming language you’re learning there are always going to be surprises. Just this week, for me it was figuring out the Ember environment settings. Documentation on taking secrets like API keys out of source control don’t seem to be freely available, answers I only found by re-reading Ember documentation a couple of times.

 

Although I’ll be taking a break for a couple of weeks from the web app project. I took an hour to go through the product backlog. Now it might look like the stories are jumbled up. This reflects the last planning exercise I did.

Product Backlog

Using Critical Path Analysis (CPA) is not common on Scrum projects, but the technique can help you decide on future sprints.

Critical Path Analysis

Something I’ve not seen anyone use or talk about before. It can be helpful in working out and identifying dependencies, even if it is miss-leading on the total time required to complete work.

There are currently 4 epics:

  1.  Usability (purple) – adding progress bars when processing website speed and confirmation on delete.
  2. Dashboard (orange) – providing charts to make it easier to analyse the changes in site rankings.
  3. Scheduled Comparison (blue) – Checking the page speeds every night and sending notifications to users when there is a change.
  4. Monetization of app (green) – Make it possible for customers to purchase the service which will provide features like the scheduled comparison.

Following the critical path analysis I drew up the following sprint plan which looks like there will need to be at least another 8 to 10 sprints.

Sprint Plan Visualisation

I’ve also included a velocity chart which documents the number of story points I tackled in each sprint. This chart can also be a little miss-leading and you can see in Sprint 7 what seems to be a dip in productivity. However, bugs that need to be fixed cannot be estimated in JIRA. In that Sprint I deliberately took only one story, to be sure I would complete all work.

Sprint Velocity Chart

To wrap up on the infrastructure, I think Firebase is fantastic for rapid prototyping. The Google Cloud Platform is also very powerful and the fact they provide free credit allows you to get a good idea of the services they provide. The billing is currently showing that $112 of the $300 free credit have been used which will expire in about 3 weeks. For small businesses this might seem a lot, but, you are getting access to a world-class data centre which is not comparable with setting up your own servers in-house.


That’s it! Let me know what you think of the 8-week project and web app, in the comments below! If you have any feedback at all, I welcome it.