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?
Best Answer
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.