Transparency instead of planned slack

railway-188025_1920

A fellow agile coach pointed out an interesting difference between the planning of traditional project management and agile methods, that I think deserves a blog post on its own: transparency.

When you plan traditionally and draw a Gantt chart, based on activities and allocated resources, you create the critical path – that is, the sequence of activities that must be finished on time in order for the final deadline of the project to be met. Most project managers know that this critical path, given the vague time estimates given and the sometimes poor understanding of the complex tasks at hand, will not hold. To counter this, they do one of two things:

  • They inflate the time estimates by some factor (by 2 or pi or some other arbitrary number)
  • They insert buffers into the critical path, to be used if needed

I can imagine that many project managers, especially for larger projects, do both.

The main issue that I have with this – and I say this not only as an agile coach but also as traditional project manager – is that it is not very transparent. The practice might need to be explained to the project team (”hey, we said it would take 2 days to do task x, why did you write a week?”) and it might be hard to motivate for the customer (”hey, why have you planned two weeks of doing nothing?”). There is also the factor of Parkinson’s law to consider: if you show everybody involved that a specific task will take 4 weeks to complete, it somehow always seem to take no less than 4 weeks.

Now, the precise (albeit faulty) planning of traditional project management does not exist in agile methods. Thankfully. I prefer the transparency of agile methods. We do not claim to know precisely how long something will take; instead we make a promise that we will work with a sustainable pace with the most prioritized features first. We do not plan in advance for one sprint of doing nothing, just in case. It’s done when it’s done. Also, after a few sprints we will be able to tell the customer when most of the things in the backlog – given that it is not re-prioritized too much – will be finished.

So, how come that many customers still request a traditional project management approach, with a fixed date, scope and cost? Sometimes, it is because they have to fulfill legal obligations or their own contracts, but most of the time I think it is that they simply do not know that there is a better, more transparent way. It is up to you, the reader, to enlighten them!