|Perl Monk, Perl Meditation|
Thoughts on the Agile Impositionby talexb (Canon)
|on Dec 11, 2010 at 19:45 UTC||Need Help??|
Brother eyepopslikeamosquito has written extensively and passionately about the Agile Imposition (1,2,3,4), and I've been thinking about it as well, as my employer has promoted its use in development.
A sprint is planned ahead of time, with stakeholders being consulted on which bugs and features are their highest priorities, with the goal being a correctly working release, delivered on time. Scrums are the daily meetings that let the team keep each other up to date in the current sprint, and also keep the scrum leader and the stakeholder up to speed on what challenges they have.
The scrum area contains a burn-down chart, with the number of days across the bottom, and the number of hours for the total effort on the left side. A straight line is drawn diagonally from the first day and total hours, to the last day and zero hours, showing the ideal burn-down rate. Post-It notes with bugs and features (tasks) that define the sprint are placed in the first section of a wall area waiting to be claimed. The two other sections are Claimed and Finished; as tasks are finished, the burn down chart is update to reflect the team's progress.
But is this the ideal setup? It doesn't cover "production emergencies, high level features that *must* be implemented right away, or when someone is sick" (5) And if the scrum starts to fall behind, should features that were part of the scrum get tossed, just to stick to some ideal release date? (Seeing no way out, I asked the ScrumMaster for advice. He solved the problem simply by removing some features from the Sprint. Well, I couldn't see the point of being ceremoniously asked for commitment if such a commitment could be so easily broken. (4))
I do think the daily meetings are a great idea, but I'm not sure that having all these pieces of paper on the wall are that instructive. I don't have a lot of faith in the burn-down chart -- I get suspicious when the team's ahead, and I worry when the team's behind. And these numbers are based on software developers estimating how long something is going to take. If those numbers are off by 100% (you should be so lucky) your scrum's in trouble, and if they're off by 200% (a task takes 4.5 days instead of 1.5 days, say), the burn-down chart starts to look horror show.
One solution I think would work would be to estimate jobs in ranges of time, but use the rest of the scrum approach. Instead of a knife-edge of "We're on schedule" and disaster on either side, let there be an area of "We're in good-ish shape" in the middle. If there's a reason for a development release to come out on a particular day, then plan to cut development off as that deadline approaches. Don't try to cram in some half-baked code and hope to catch the problem in staging. And if the release is done early, that's fine too -- perhaps the scrum master will start to get a feel for whose estimates are more accurate.
At the bottom, scrums rely on some level of micro-management and on accurate estimates for work required. And I'm not sure that's a good way to develop software.