Video is also really good (would be better with audio :)).

Will think about it some more, maybe some other readers will find this old article and check out Team Effort and share feedback.

I note that you’re not saying that Planning is a useless exercise in Agile projects, just that preparing the traditional Gantt charts is a wasted dead-end effort. I could not agree with you more!

So you might find it strange to hear that a lover of all things Agile would spend a few years in the closet building an online project management tool that looks remarkably like a Gantt chart, but I did.

I really would love to hear your thoughts on it …

http://blog.teameffect.com/post/Team_Effect_equals_Agile_friendly_Gantt_charts.aspx

Regards,

Jason

On the first one – I agree that Gantt charts are very powerful for communication, but only when they are made at the right level. A higher level Gantt is great for communicating to people external to the team. They aren’t going to get any value from knowing that Jim is writing the stored procedures to improve query performance on zip code searches on Thursday. But they certainly can benefit from knowing that we’re on track to delivering the address validation capability, which is a required predecessor of the instant loan-approval process.

I definitely would like to learn more about how you drive stuff at TenForce – I’m sure our readers would like to know more too.

Thanks again!

1.
Planning in general, and gantt charts in particular, are an important ‘communication’ tool. I have found myself often creating a plan, just to be able to discuss it with team members, customer, users, suppliers, and so on. A plan should tell a story, it needs structure. After all, there is much more to the typical project than just the ‘agile’ programming part. You have users, trainings, installations, suppliers, and so. They need some timing synchronization to get to the end result.

2.
I don’t like the work breakdown approach: splitting up each task in more detailed tasks. Rather I work from the deliverables (so-called products in prince2 -speak). Unless the scope of your project changes, your deliverables remain fairly constant in your project. A gantt chart (or at least the left part of it) is the ideal place to explain that deliverable break down.

We at TenForce have developed a pragmatic project management product that integrates with MS Project as a planning tool. We advice our customers to keep the planning on a high enough level, and not loose yourself in the details. Those get changed anyhow.

Best regards
Frans

http://yoxel.wordpress.com/2007/08/15/is-gantt-chart-the-real-issue-here/

I think scheduling is important. But maintaining a representation in MS Project of the individual developer tasks is too low level. I agree that if you have a representation of that stuff in MS Project, and you are maintaining dependencies for them, balancing the resource load for assigned tasks, and prioritizing them within each sprint – generating the Gannt chart from them takes no effort.

My point is that doing all of that conceptual maintenance work is a waste of time (at that level of detail). The tasks and their dependencies are too mutable, the team will resequence on the fly. The team will introduce and remove dependencies faster than you can keep up. Tracking the higher level stuff (like which use case is being delivered, in which sprint) is more important, and will have a lot less churn.

Dave