>Ketan Padegaonkar of SWTBot fame, posted bug 261408 in regards to small projects having to adapt to the sometimes more stringent and less agile ways of working. I’ve stated in the past that eclipse projects in many ways only appear agile, but are not necessarily run in an agile way. There is nothing wrong with this, and each project has the right to determine what best fits their development methodology.
I’ve felt Ketan’s pain while working on the XSL Tools, VEX, and XQuery projects in the web tools incubator. Not being able to have a true integration build of the component I’m working on can be frustrating. Having to tag code and release it for a build is another frustrating item. It isn’t true continuous integration, and tends to let possible integration issues get delayed instead of being caught sooner. Tags should be done, but only for code that is included at the end of the Iteration. Tag the build after it completes so you know what was actually captured in that build.
Builds are not what this post is about. The one area that we in XSL Tools have a bit of control over is how we triage our bugzilla bugs. I’m just going to pick on Web Tools for example purposes because they actually do have a Workflow documented on this issue. I believe Mylyn also has their triaging process documented on the wiki as well. While the process is clearly defined, it really is not an agile approach to manging the backlog or producing the iteration plan. In summary the current process is this:
- Bug goes to the Project Inbox
- Component owner triages the inbox, and ASSIGNs the bug to somebody.
- New owner further triages the bug and based on priorities figures out when to work on it.
- The bug eventually gets worked on, and gets moved to the Assigned state. This means nobody else can work on it because they are actively working on it.
- Target field is only put in when they are relatively sure that it will get in that target.
- Once fixed, it is marked as appropriate and moved through the rest of the process.
While the above is all well and good there are a couple of things really keeping this from being more agile. I’m a big fan of SCRUM for project management and prioritization of the bugs to be worked on. So I view bugzilla as the Product Backlog for a eclipse project. To this end here is how I would tweak the above:
- Bug goes into the project inbox.
- Product Owner/Committer/Component Owner/PMC or who ever is effectively the product owner reviews the bug, and triages it. DO NOT REMOVE from project in box.
- Before the start of the each iteration, review the current backlog, sorted by priority, votes, or whatever measurement is used to indicate Highest to Lowest priority for the project.
- Team reviews the requirements for that Iteration only.
- Somebody selects to work on a particular backlog item, they get it assigned to them at that time, and set the Target field for that iteration.
- Steps 4 and 5 continue until the team feels it can’t complete any more bugs.
- Team works on the bugs, if somebody finishes and has time, they can help on any bug, it isn’t necessarily OWNED by any one person. The team owns the bug.
- Repeat steps 1 – 7 before the next iteration.
One of the issues with the first process is that by assigning it to somebody, they all of a sudden have a huge backlog of bugs that are Assigned to them. This has a tendency to get bugs lost, they get pushed to the background, and are forgotten about. It also tends to let the backlog grow, because the bug has been assigned, so it appears that somebody is in charge or responsible for it, but might not actually be actively working on it.
The advantages of the latter method is that it keeps the team focused on that iterations work only. The team as a whole is responsible for the backlog, not one particular person, and no one person is necessarily responsible for one particular bug. The product backlog is reviewed before the start of the iteration, and priorities are reviewed as well. The team becomes more focused on what they can work on for a particular iteration. It also starts to become clearer to the product owners (user community, adopters, etc) what is planned for a particular iteration.
There are probably disadvantages to the above, and I’m sure somebody will let me know what they are. However, I’ve found that once people get used to this way of triaging and managing backlogs, that it actually is less stressfull, and even more bugs and enhancements are addressed and fixed. The person is able to focus on the current priorities, and bugs aren’t necessarily lost as Higher priority items are always bubbling up to the top.
Ultimately it comes down to addressing the issues and making sure they get fixed. How that is done is up to each team to figure out on their own. The question that a team needs to ask it self, and it continually needs to ask it self this is:
Why are we doing it this way?
If the answer is something like “Because that’s they way it’s always been done.” It might be time to review the process. Just because it has always been done that way, does not necessarily mean it is the correct way to do it now. We humans tend to be a creature of habit, both good and bad. So it’s hard for us to change. However adapting to change, and being willing to change when it can help improve the overall process is something that one should always be willing to do. If it does not work, you can always go back to the old way that is more comfortable.