Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at Why GANTT Charts Were Banned in the First Scrum
GANTT charts have some utility when a Product Owner has to present to naive users (non-Agile managers) to get a project funded.
Once implementation of the plan starts, the team enters the fog of war, just like a squad of troops entering battle. Military generals fully understand that once the enemy is engaged, all plans are shattered and the front line must self-organize to win the day.
Taking the GANTT chart into the Sprint has people look at a planning document that is absolutely wrong after the first day. At best it gobbles up a full time resource in the futile effort to keep the chart up to date. Even worse, it may lead the team to do the wrong thing and lose, i.e. a failed Sprint goes up in flames.
The GANTT chart was banned from Sprints for these reasons when I led the initial implementation of Scrum in 1993. 13 years later I don't see any reason to change this. In fact after consulting with leading companies up and down Silicon Valley and in other parts of the world this past year, getting their burndown charts updated daily and visible to the entire company is a top priority. Any distraction by GANTT charts is an exercise in futility.
posted by Jeff Sutherland @ 7:45 PM
4 Comments:
is there anything you would suggest to use in place of a Gantt chart with regards to planning the expected delivery schedule of future projects?
Since I originally published this comment, Mike Cohn's book on Agile Estimation and Planning was published. The strategy of building a Product Backlog and estimating it in story points has become the gold standard for agile development. It allows the Product Owner to develop a release plan that requires 80% less work in project planning and provides better estimates of completion dates.
Jeff,
Thanks for the prompt reply. Yes we use a product backlog, but what I find difficult to do is translate the product backlog into an actual planning tool. For example we have a number of Internal Products that we are working on and for example if the board said "please provide a schedule of when certain releases would be available" for me this seems almost imposable as I have t take into account the estimate of each user stories and try and determine how many of those user stories would fit into each sprint together with other priority products. Not sure if I am explaining my self correctly. If not let me know and I can provide an example.
The way PatientKeeper handled this when they were doing Scrum well was to determine what had to be in the next release for all products (every Sprint was a release). The stories for all products were put into a single product backlog. The teams self-organized around the backlog pulling it into the sprint and all burned down together the one backlog to release at the end of the sprint.
We have a virtual market release every three months were we sent out press releases and did the usual marketing. However, this was simply a cumulative release of all the sprints in the three month period.
Post a Comment
<< Home