> However, I still think that Gannt charts and top-down planning have value.
Of course they do. What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate.
Anyway, if you want to provide the same sort of value but present it in a different format, consider using a network diagram or a user story map[1].
> What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate.
You think I don't know this?
I think you missed the point :(
(As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)
> they do not effectively communicate timeline expectations
Of course, that is in part by design.
If you are delivering solution X that is just an instance of iteration Y of system Z with a few customer-specific tweaks, Agile methods will work just fine in combination with GANTT charts, and teams that are engaged regularly in that sort of work aren't too likely to object.
However, as soon as a task is a known unknown (that is, a well characterized problem with an understood though as-yet nonexistent solution) requiring new code that isn't just a variation on familar themes (ie. whatever is the equivalent of a CRUD web application for your industry), you start having to deal with uncertainty and risk (which humans are very bad at reasoning about). GANTT charts can make things worse because they foster a false sense of control (padding time estimates by x% for example feels like it helps, for example). And if anything in your critical path is a known unknown, your timeline expectations, however consensus-driven and reasonable as they may be, are likely to get smashed to smithereens, and all a GANTT chart is going to do is tell you when your carefully constructed schedule is starting to slip.
Throw unknown unkowns into the mix (from "we haven't yet figured out how to solve this" all the way to "are we even solving the right problem"), and timelines become entirely fictional.
I am not aware of any chart format that incorporates this sort of risk and uncertainty well (FogBugz for example, which incorporates probability and risk based on an estimator's past track record, basically just sticks that data into a chart's tooltips)
Now, if you are willing to mitigate these risks by basing your timeline around deadlines for handoffs with the understanding that what gets handed off is "best effort working system in available time" (in which case continuous integration/delivery is your best friend) that's a different matter, but that just isn't how most projects are concieved or managed. Yet.
BTW, related to all this is the conflict between feature-based and time-based approaches to software releases.
You think I don't know this?
I think you missed the point :(
(As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)