4

I've heard it said that gantt charts are a relic of waterfall project management techniques.

I typically use an agile-like approach to project planning and tracking progress which provides good visibility into feature-time trade-offs as the project progresses.

We're at the outset of a project in in which, while the exact front-end user interaction design is somewhat unclear at this early stage, the back-end requirements are fairly clear (components that communicate with various third-party APIs, the server infrastructure, etc).

We'll be going through a process to develop good user interaction design for the front-end (starting with user stories and working forward from there), but we also wanted to get an idea of how long the back-end would take.

I decided the best approach was to break it down into sub-components, where each component consisted of tightly coupled code that should probably be worked on in a contiguous period of time.

I assigned rough time estimates to each component and sub-component, typically ranging from 1 to 10 days. I then used OmniPlan to indicate dependencies between these various components, and assigned developers to each task, with the goal of distributing effort as equally as possible.

I then used OmniPlan's leveling tool. All, I think, a fairly standard way to use OmniPlan, and I thought reasonable way to come up with a rough time estimate.

I should clarify that the intention was not to come up with a rigid blueprint about who would work on what and when, but more come up with at least one plausible way that we could build what we needed to build in a two month period. The gantt chart suggested that this was feasible.

To my surprise, I received quite strong pushback from another team-member familiar with the agile development process, who accused me of adopting a waterfall methodology.

Their more specific criticism was that the gantt chart was specified in terms of architectural components, rather than on user-visible features. They were frustrated that it didn't lend itself to saying "we should have functionality X by Y date".

Where, if anywhere, did I go wrong?

Improve this question
2
  • Did you co-worker know that the intention was not to come up with a rigid timeline?
    – sarnold
    Feb 24, 2012 at 1:14
  • They should, and I repeated this during the conversation, which is when they moved on to the complaint that the chart was focussed on "components", not "features"
    – sanity
    Feb 24, 2012 at 1:42

3 Answers 3

Reset to default
4

The big issue that I have with using Gantt charts is this. They don't do a good job of illustrating how the total amount of work left on a project changes with each iteration. That being said, most of the business owners in our organization are familiar with Gantt charts. This makes them an easier medium for communicating progress than the preferred (in my opinion) burn-up chart. The burn-up does show the both the progress of the team as well as the change in scope of the project throughout it's lifecycle. So I think there is room for compromise, but I would always have a burn-up at the ready to help fill in some of the missing information from the Gantt chart.

If you are just using it for an initial estimate, I don't see a big issue with that. Using it to track progress does seem dated and "waterfally" to me.

Improve this answer
3
  • I agree, it isn't my intention to use the gantt chart to track progress, only for an initial rough estimate of the entire project.
    – sanity
    Feb 24, 2012 at 17:37
  • 1
    Nothing at all wrong with doing this. Getting too stuck in a methodology is a bad move. Being Agile without being able to give estimates won't go down real well, so use whatever tool gives you some help. If thats a Gantt then use it. If scissors and string work, use them. You get the idea. These things are all tools - if they help, use them. If they don't then you need to find a more suitable tool.
    – quickly_now
    Feb 27, 2012 at 7:33
  • the whole point of Agile and XP is to clear the air and allow you to give good solid estimates without too much political pressure in providing the right numbers.
    – user7433
    Dec 16, 2014 at 4:27
1

What you want here is to have an idea of a end-date, with a fixed set of resources, and a fixed scope. That's typically what Gantt charts are used for, but that's definitely not agile.

The agile manifesto states that :

We have come to value:

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Source : http://www.agilemanifesto.org/

This means that agile practitioners prefers being able to respond easily to multiple and important scope changes rather than being able to provide (and committed to) forecasts more than one month ahead (which other methods didn't do well anyway, but their goal is to address this concern).

If your clients/management value the items on the left more, then doing both agile and addressing their concerns will be tricky.

If you have a fixed set of requirements for a component with clear and fixed specifications, and you need to provide a delivery date, then maybe agile methodologies are not the best fit for your case.

So, to answer your question, you are not doing anything wrong, but you are not doing it in a agile way. As said quickly_now in a comment, it's bad to get stuck in a methodology, so everything is ok, you're just pragmatic.

For the front-end user interaction, you seems to be not expected to provide a delivery date, and the scope is unclear, then here, undoubtedly, agile seems the right thing to do.

Improve this answer
1

In the real world rigid time lines are compulsory!

How would you feel is you took your car in for an oil change and the guy at the shop said "it will be done when its done" or "I can get it back to you tomorrow at 4 p.m. but I may only have had time to drain the old oil".

Deadlines are a must for management. They have to plan, coordinate and budget all sorts of stuff besides your project and they need to know when its going to be ready!

As its pretty much impossible to provide an accurate estimate for any reasonably large software project this puts you in an impossible situation.

The best tools are still experience and gut feeling. Gannt charts, project plans etc. are necessary smoke and mirrors to keep the management off your back.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.