LOGIN | REGISTER NOW | SUBSCRIBE
 
print Printable version 
Most Read Latest News Blog Resources
Does Windows cost Microsoft opportunities?
Microsoft's decision to focus .NET on Windows is stifling innovation due to the specter of...

Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

OSBC focus turns to best practices for open-source adoption
Businesses are no longer asking why they should adopt, but how do they use open source leg...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Windows & .NET Watch: Shun the Gantt, embrace the burn-down


By Larry O'Brien
July 1, 2009 — 
I once, heaven forgive me, described a software project with a 5-foot-tall Gantt chart. A Gantt chart is the staple of project management software: time on the X-axis, tasks on the Y-axis, tasks starting the instant their dependencies are finished.

The center of gravity of the tasks shifts as you travel down the page(s), until finally all of the little waterfalls end in a little zero-duration diamond-shaped milestone. Nov. 14, a Tuesday. Not the 13th, not the 15th, but the Tuesday of the week before Thanksgiving. Management loved that chart: dozens, if not hundreds of tasks quantified and laid out, tick-tock deliverables culminating well before the end of the quarter, with a “buffer” that could be eaten up without interfering with Thanksgiving in Tahoe.

Gantt charts ought not be used in software development projects. Using a Gantt chart to estimate a software project is like designing a rocket ship by snapping together Lego blocks; it might give you an idea of the shape, it might flush out some constraints or hidden issues, it might be colorful and look good, but it fails to capture the complexity and variables of that which it is modeling.

Worse, it camouflages them. Toy blocks are of uniform size, snap together tightly, and hide the messy internals. Gantt chart estimates have the same characteristics, albeit disguised by the “feature” of arbitrary precision on estimated times (“That task will probably take 143.25 hours.”). Of course, no one would estimate a task like that, so instead the schedule is made from top-down decomposition, snapping together tiny little estimates of few-day tasks. Invest enough time snapping together things and lo! you’ve just given management a concrete delivery date.

Management needs delivery dates. Companies need to rely on projects coming to fruition a few quarters out. Any methodologist (or “process guru”) who urges you to “ship when it’s ready” is going to be long gone when you’re three months in to the death march that starts when your Gantt chart is about three-fourths covered in corrections, annotations and big swooping circles highlighting some task that turned into a multi-week digression.

Gantt charts facilitate a barely disguised waterfall model of development, an approach that we know is wrong. From “spiral” to “iterative” to “continuous,” the software development industry has learned that the tighter that you can make your release cycle, the more success you’ll have when it comes to deadlines. Not because at the end of 16 months you’ll necessarily have delivered everything discussed today, but because at the end of 16 months you will have already deployed many of those items, you will have deployed some unforeseen items, and the more trust you’ll have established about trading off features, deadlines, and resources.

When management calls you in on Nov. 14 to explain your shortfalls, it’s far better to have released three-fourths of the feature list than to say, “Well, we’re three-fourths of the way through the Gantt chart.”

I like four- or six-week iterations for “potentially releasable” milestones. Some say that’s too long, but most teams are challenged enough developing the new habits for a month-or-so-long release rhythm.

The burn-down chart has replaced the Gantt chart as the “go to” chart for talking to management about a project's schedule. Data-wise, the burn-down chart is very similar to a tracking Gantt chart: days on the X-axis, “effort remaining” on the Y (“person-days,” “story points,” “function-points”—whatever unit of effort is comfortable). The key difference is that the burn-down chart accumulates all the estimated task durations, so the day-to-day difference in the burn-down is not, “Did we delay the downstream tasks?” but, “What is our daily velocity versus the estimate?”

It turns out that rarely does a workweek result in 40 hours of X team-size reduction in remaining effort (quelle surprise!). But velocity turns out to be a useful metric, providing feedback to the estimation process, projecting into the future better, and vividly showing the effect of introducing new requirements.

Burn-down charts invariably have a roller-coaster aspect to them: Remaining effort often goes up, not down, as the inevitable “hard stuff” surfaces. A certain amount of roller-coastering is fine, but if the peaks are getting higher over time, you’ve got a “Flubber chart,” as in the Disney material that bounces higher than it falls. It happens; I’ve had a burn-down chart that bore a striking resemblance to the Loch Ness monster.

Flubber charts highlight a problem that’s harder to see in a tracking Gantt: serious gaps in requirements discovery or project management. There are burn-down chart variations that track new/uncovered requirements, but I like the simplicity of the basic chart.

Short iterations tracked by burn-down charts actually deliver the information promised by Gantt charts (productivity rates, long-term projections, ROI values). Your first short-iteration releases may skid, your first burn-down charts may have a certain amount of Flubber in them, management may be dismayed by the incrementalism of the feature changes, but all of those things can be tightened down. After three or four releases, the team gets into a rhythm and the Flubber dissipates as you gain experience estimating velocity and maintaining a backlog.

Best of all, you increase the trust between management and your development team as they see regular improvements, less stress and ultimately higher productivity levels.

Larry O'Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.


Related Search Term(s): burn-down, Gantt


Share this link: http://www.sdtimes.com/link/33581
 

Comments

07/08/2009 08:45:03 AM EST

When you say, "Using a Gantt chart to estimate a software project is like designing a rocket ship by snapping together Lego blocks," I would most certainly agree. Gantt charts aren't an "estimating tool" at all. If that is being done in anyone's organization, it's wrong. "it fails to capture the complexity and variables of that which it is modeling" -- as it should. There's nothing "modeling" about a Gantt. It is a vast over simplification intended to represent a time line and nothing more. It is not a model. The real problem with any kind of project representation is when we, project managers, analyst, or whatever we're called today, "sell" it to executives and stakeholders as a baseline road map and agree to perform according the (very tentative) time line. We shoot ourselves in the foot by giving in to that kind of pressure on projects where nothing is really known up front. In the Agile world and especially Scrum-world, a Gantt is particularly valueless. When the project is timeboxed, end dates and milestones don't slip... features and stories do. When the team is known (x number of people) and the project is timeboxed (for y number of weeks), the project is also fixed cost. Where's the cost estimation in this scenario? There isn't any... it's all about how many stories or features can be incrementally deployed in the allotted time with the allotted people. In cases where Agile is feasible (practice what's possible), the value of Gantt charts is debatable at best. In cases where Agile is not feasible, their value may be more. But never is a Gantt chart an "estimation tool" or "modeling" of a project. It is a graphical way to represent time lines especially in a way that is easy to understand by non-technical people. That's all. Nothing more. Don't confuse a Gantt chart with the Holy Grail of anything.

United StatesWoody Williams


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

High Performance Computing Linux Financial Markets
4/19/2010
New York City
Flagg Management

Informix User Conf.
4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG