Monday, July 27, 2009

When To Make a Change

We recently migrated from RT to Jira for defect tracking. At the point where we did the final cutover, we were approximately 5 weeks from shipping a release. We had completed feature development and were in a stabilization phase concentrating on bug fixes and integration testing.

RT is not the best defect tracking system for viewing progress. It's hard to pull summaries out, and it's a bit intimidating for people who don't use it constantly merely because it plunges you into detail. Because of this, we had been maintaining a page on the wiki that listed "must fix" bugs for the release ("showstoppers", "blockers", pick a name, any name). It had extremely basic information about each: a quick description, whether it was a "must fix" or not, and whether it was open or closed. It was effort to maintain the page by hand, but it was a convenient place for anyone on the project team to see where we were and what the status of their pet bugs were.

But then we moved to Jira. We were able to set up a shared dashboard that showed the open "must fix" issues, a table of issues found that weren't considered release stoppers, and a graph showing the number of closed versus open issues targeted for the release. In short, it did everything the wiki page did, and with more colors. Time to ditch that hand-maintained issues page!

Err... no. Not yet.

Software development cycles are really about routine and consistency. The act of building (and testing and releasing and marketing) software itself is rife with uncertainty, so having a stable process underneath it can provide us with the tracking and planning mechanisms we need. And while the SDLC should absolutely be matured, we have to be careful about when and how we make changes.

In this case, we had the whole team - from the VP Engineering and the product manager to the support engineers and developers - already used to using the wiki issues page. Changing it is certainly possible, but habits die hard, and there was an opportunity for missed communication. ("I didn't see it on the wiki!" "It's on the Jira dashboard" "Yeah, but I forgot we were using that, and I know it's kind of late now but this really is a big problem".) So we decided to maintain the issues page through the end of the release. This gave us the opportunity in development to refine the Jira dashboard and work out kinks around handling new issues as they came in ("untriaged", we call them) , etc. It also made it easier to educate people, since we had the entire next release (which was just starting development at the time) to get the larger team used to looking someplace new for status.

In other words, just because we could switch didn't mean we had to switch. Better to make a change later and more smoothly, then to make a change as soon as you can simply because you can. So please, make changes in your progress. Just make them when the time is right.

No comments:

Post a Comment