>I drank the Agile koolaid a while ago. In particular I’ve learned to see how a combination of SCRUM and XP can be a good combination. At STAR we are one of the few standard organizations that have shown that Agile techniques can be applied to the development of standards.
Since working on the XSL Tools project at eclipse, I’ve been using some modified SCRUM concepts to implement the notion of Product Backlogs and Sprint Backlogs as described in the Scrum Development Process. Eclipse uses Bugzilla to track all of the change requests (ideally even adopter contributed code should be here before it shows up in CVS or Subversion), whether they be enhancements or actual bugs. Here is how I use Bugzilla at eclipse to implement Scrum.
- Product Owner – This is the community for the product. This includes the users and the adopters, as well as committers, and the Eclipse Planning Council. The later helps set the goals and target dates for when everything has to be done…i.e. yearly release in June. The Adopters and the User community have the same level of influence. Votes by the community help determine what is priority.
- Product Backlog – This is all of the Unresolved bugs that are either in a NEW, ASSIGNED, or RE-OPENED status. There are many ways to order priority for planning, either by how critical the bug is, or how many votes that it has received. Typically the older the bug the higher priority it will get.
- Sprint Backlog – a Sprint is the eclipse 6 week milestone development period. Personally I like sprints of about 2 weeks but 6 weeks is about right when you are working part-time on a project, it allows enough to get done. Selection for what gets added to a sprint, occurs only at the beginning of that Milestone. No commitment or scheduling of bugs for further milestones out…i.e. if XSL Tools is on 1.0M4, then we aren’t looking at what to go into 1.0M5 until we finish M4.
The Sprint Backlog for each of the milestones is publicly available to be viewed by the user community on the XSL Tools wiki development page. Items I still haven’t figured out how to implement and track using Bugzilla are, story points, and then the burn down charts.
While this ad-hoc just-in-time planning probably doesn’t fly very well, with the overall Eclipse Project Plan, it allows us to adapt to changing requirements from the community. If all of a sudden a particular bug is getting an increasing number of votes, it will migrate it’s way up the list to be reviewed. If something new is discovered that has to be done, it can be addressed in the next sprint. One thing we don’t do is change the priorities once a Sprint/Milestone has started. That can only be done when planning for the next sprint. It allows us to focus on getting things addressed.
One of the benefits I have found doing this, is that it helps focus the developer on particular tasks. Instead of automatically assigning a bug to somebody, that might not get actually worked on, it isn’t assigned until it will be worked on. It seems to work pretty well with XSL Tools development, as it allows the developer to focus on particular functionality, instead of being overwhelmed with a huge backlog of bugs. They only have a few they are focused on at a time.
Another advantage here is that this process has allowed us to keep XSL Tools in a release-able state during any particular milestone. If a build crashes due to a failing unit test. It is addressed before anything else. Failing builds are given the highest priority. Developers are encouraged to synchronize with the CVS repository daily to bring in the latest changes, and unit tests must pass before tagging the code for release.
Anyways, I’d be curious to see how other eclipse projects are incorporating Agile project planning techniques with the tools that eclipse provides the developer community. What works for you, what doesn’t work.. How can eclipse and the Architecture Council help address the issues and concerns?