i was a guest at the agile round table near boston last night. the event drew a crowd of veteran software engineers, i was the youngest in attendance by 20 years.
ken schwaber outlined his and jeff sutherland’s SCRUM approach, which struck me as interesting and worthwhile to follow up on.
jeff sutherland, CTO of patientkeeper, demonstrated how he manages his teams of developers with GNATS. jeff figured that developers loathe red tape, and had the goal to limit the effort required to 1 minute per day for developers, and 10 minutes per day for project managers.
and he was not using gantt charts to achieve this either. calling gantt charts totally useless for project management beyond giving warm fuzzies to the client, he explained how he leveraged their bug tracker to double as a means to keep track of effort.
each morning, developers review their tasks and update the work remaining estimates which have a granularity of one day. the project managers, in turn, analyze the reports that GNATS automatically creates. reports such as number of new tasks vs closed tasks, total work remaining and other metrics that can be derived from the task data.
tasks are the cornerstone here. jeff was able to demonstrate to the business side that the high level business goals were off by 100% with their effort estimates, while the low-level tasks achieved an accuracy of 10% on average. this led to enthusiasm from all parties to drill down on any project and get to the task level ASAP to get meaningful estimates. and, like psychohistory, project management is inherently stochastic.
nowhere to run, nowhere to hide
the level of transparency of this system is unprecedented. with everyone in the company able to see on a daily basis how much work was remaining and what the roadblocks were, the initial fears that developers would be pounded on by management turned out to be unfounded. instead, the transparency enables everyone to do real-time adjustments and to detect problems early, which has taken a lot of politics and second-guessing out of the equation.
when analyzing a project, jeff focuses on burn down, the part of a release where open tasks are relentlessly driven down to 0 by a joint effort of developers and business people. the corresponding graphic (roughly a bell curve) illustrates the importance of the burn down nicely, adding weight to jeff’s assertion that burn down is the only thing that matters to get a release done in time.
which prompted me to ask for advice on how to drive an open source release as a release manager. people are not exactly required to do your bidding, but metrics may help there too. collect these useful data points, as the bugzilla-bitkeeper integration is doing, and let them speak for themselves. peer pressure and pride in workmanship will take over from there. that’s the idea anyway..