Accueil > professional > Why is "Agile" planning better than the traditional Gantt approach ?

Why is "Agile" planning better than the traditional Gantt approach ?

Last sunday, I’ve been discussing with a friend about planning. In his company, they’re doing it the « traditional » way, with a Gantt like approach. The example was of an excel sheet containing two tasks, coding and testing, one after the other. Quite to my disappointment, I was at pain to express clearly the advantages of an « Agile » planning. So, in order to be clearer next time, here is my homework 🙂

Users care for features and nothing else !
Thinking back on this discussion, I think the key point I didn’t express at that time was, as Mary Poppendieck would put it : « These days we do not program software module by module; we program software feature by feature ». It really goes to the fundamental differences between a Gantt like planning and an « Agile » one.

When planning modules by modules, and can have buffers before/after, reorganize your plan, but basically you’re at risk of delivering nothing or something that the users don’t really care about (if you go for partial delivery). And all that, maybe, just because some corner issues (either in terms of functionality or technical) aren’t resolved.

With features planning, you put what the user wants first, meaning there is a high probability of pleasing him. Furthermore, a feature doesn’t dictate a technical scope : even if the technical aspects are not all perfect, you can still release the feature if possible/needed. The full database schema hasn’t to be known/implemented/optimized for having some functionality working…

Finally, an Agile team commits itself for a set of features. Sorting out the difficulties encountered is part of this commitment. When committing to fit to a Gantt planning, it can be done perfectly and still having nothing working or of interest for the users…

Software development tasks cannot be accomplished in isolation
On a more general scope, separating activities in software development is a risky business. What you do on the data base level has impact on the software. DBA and developers have to speak together, they don’t work in isolation. Furthermore, if during testing some feature is missing, the odds are high that both the code and the database will be affected. What do you do if you’re now in the « testing » phase of your gantt planning ? In which cell does it fit ?

Software development is full of uncertainties
Last but not least, a Gantt planning looks horribly deterministic. It looks like all is sorted out, that we know exactly where we go. But software isn’t like mass production : each project is different. What if some functionality isn’t properly described ? What about technical uncertainties ? What if priorities change ? Agile planning – and agile software development – is all about taking these uncertainties in account. The exact tasks to achieve for a functionality aren’t figured out months before working on it (as if anyone could ever do so). The iterations and daily scrum are all about, as well, resolving uncertainties when they appear and when we have the required knowledge.

As usual, all feedback welcome !


Étiquettes : ,
  1. septembre 20, 2009 à 5:48

    I’m agree 100% with you 🙂

    But what can we say if our customer wants a « milestone-plan » about the next 1 year of the project?

    I had succesful use the « agile way » (or what i’m understanding under « agile development ») in my last 2 projects.
    At the beginning our team was asked for a rough estimated timeline. And we try to find out such a plan, therefor we
    must analyze/plane the (required) features from a to z (rough). Is there a better (agile) way for that?


  2. Joseph Pachod
    novembre 2, 2009 à 10:19

    Hi Andreas

    Sorry for the late answer… At the time of your comment, I was reading Agile Estimating and Planning, and thus I thought I would be better off finishing it first. Then I started this SCJP stuff, and this book’s reading didn’t progress much. To be honest, this book has interesting content but is hard to read (amazing how interesting content can sometime be put in a dull way).

    Anyway, back to the topic. This Agile Estimating and Planning book speaks about this « milestone plan » and says something very close to your approach. In fact, they even provide ways of estimating such « themes », with the idea that the customer should be able to choose priority between the different themes possible. They speak of theme because there should be few details there, only a rough « road map ». As told in some other post, they reckon that the themes’ estimates should be done by the whole team, and then the product owner/management should prioritize them. For sure, one should put some buffer around the estimate to avoid troubles.

    Later in the process, the themes should be split in user stories. These user stories should then as well evolve over times, becoming more and more detailed until they are finally included in some sprints. The idea is to always have enough information for planning, but still avoiding going too much into details which could be proved wrong/different/unnecessary later on. Easy to say, hard to do !


  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l'aide de votre compte Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s

%d blogueurs aiment cette page :