Agile afficianadoes in general, and ScrumMethodology fans in particular, despise the GanttChart:
- Most GanttCharts are lies from the get-go
- Most GanttCharts' lies get bigger as time goes on
- Maintaining these horrible lying charts is an expensive waste of time for an Agile tracker
- Most managers use GanttCharts to force developers into heroics, stress, burnout and, dare I say it, disgruntlement.
On the other hand, most Project Managers adore the
GanttChart:
- PMs are expected to communicate via GanttChart. Saying you won't use them is like saying you've decided to use the coughing code.
- The popular Prince2 and Pmbok methodologies will keep Gantts alive no matter what Joel, Bob, Ron, and all the whipper-snapper BaseCamp agilists have to say.
- When it comes to costing, calendars, external dependencies and resourcing the GanttChart actually useful. No, I am not kidding.
- Non-technical managers, especially high level managers, see no reason why GanttCharts which are perfectly adequate in all other realms of human endeavour should not apply to software development.
Up till now this has left agilists at a PM impass. Can't live with 'em, can't live without 'em. Isn't there some way we can turn these compelling graphs to our advantage? I believe there is. You can represent an honest XP
CommitmentSchedule with an
AgileGantt. Here's the grift:
- UserStories are represented by Gantt tasks. Use start-start dependencies to represent relative priorities so they'll fold up the right way. Burn anyone who says there's internal finish-start dependencies. Never put EngineeringTasks on the Gantt.
- Assign all developers to every UserStory Gantt task. This isn't telling any lies - developers pair on EngineeringTasks, not UserStories. Account traditionally for developer vacation schedules, illnesses, etc.
- Estimate in StoryPoint?s. To map to Gantt "effort" days, multiply by a big fat LoadFactor, say 4, then measure Project Velocity as you normally would for IdealDays and track per iteration. This is so the efficiency game you play in the next step makes you look pretty.
- Use ProjectVelocity to generate LoadFactor as a percentage, then adjust the Gantt efficiency of all developers by this percentage.
- Level every time you adjust the schedule after a PlanningGame. Let PMs ignorant enough to want to check you against a baseline figure it out ... if they can.
- Rig your FitTest server to fill in the completions for the UserStory tasks automatically. That way you only edit the Gantt manually after a PlanningGame.
That's easy peasy. Whack your
AgileGantt up on the wall next to your
BurnUpChart and
ProjectVelocity histogram and those old waterfall buzzards can Pmbok on you all they like, you're teflon. Or at least that's my present thinking - I'd appreciate critical comment. ~
PeterMerel
Hi, Peter! You're only about 5 years behind on this one. [WallGantt]
--AlistairCockburn
Thanks Alistair. It's reassuring to find oneself becoming a conservative. This is the way we've always done it. Harumph. :-)
I do like the WallGantt. It seems like a neat way for a large team to share ownership of EngineeringTasks. But I don't think it's quite the same idea as this one.
The WallGantt doesn't represent a CommitmentSchedule in UserStories and customer priority order. Also because it's (admirably) paper based it's not amenable to the purpose of the AgileGantt - corporate communication with non-copacetic customers. And I don't see how you could do a FIT integration with it ...
Basically the AgileGantt is an attempt to represent a customer-oriented CommitmentSchedule directly in the traditional PM form. The notion is that day to day EngineeringTasking is managed using stand-ups and pairing - obviating the burden of maintaining a detailed task schedule past a weekly horizon.
Ah, I see ... which is my way of saying I don't understand at all. Something is too complicated here for me to grasp. Is there a picture that shows it, or a simpler way of describing it so my mind doesn't blow up or go to sleep half-way through?
... those of us with little minds, you see, need to be given simpler ideas to suck on ...
Sorry for misunderstanding. When we get this cleared up, refactor at will to remove my dribbling. -- AlistairCockburn
Pshaw, the obvious problem is I've given no examples. I'm constructing the first of these today so will file off the serial numbers then put up a jpeg some place. But in the meanwhile some terminology clarifications might help:
- A start-start dependency means one task can't start until another has started. So given resource availability they can proceed in parallel.
- Gantt efficiency is a quality of a Gantt resource - generally of a person. It's something like availability; if you're only working half days you have an efficiency of 50%. I imagine really damnfoolish managers might use it to describe the relative quality of their staff. Tying it up in a knot as above makes it correspond directly with LoadFactor, which you'll recall described ProjectVelocity in Kent's original conception.
- A baseline is the BDUF Gantt a waterfall starts with; PMBOK regards reality as a variance upon the baseline, and your waterfall PM spends most of his life tracking that for purposes of blame distribution. At least, I think that's the purposes, I've never been certain.
- Leveling is the process of automagically reassigning your resources so that, given task dependencies, you can minimize the CriticalPath. Waterfall PMs believe doing this is important, presumably for purposes of OperantConditioning?. Though who they're conditioning I've also never been certain.
That all I understand. What I don't see is what is the difference between your thing and the paper wall-gantt. I know you've provided words for me to consume --- right now I'm needing to wait to see what the thing looks like ''to savvy how it is different from the things I know. (then we can delete much of this back-and-forth). Cheers - Alistair
Agile Gantt