This is a following post to the series on Agile development at Songbird. As covered previously, I’ve created in-house tools to help with the planning and tracking of our release trains. The tool works off of Bugzilla and extracts meaningful information for project tracking. As it was originally meant to periodically generate an email status, it became apparent that it was too static for daily project tracking needs.

In the previous two installments of this series on Agile development at Songbird, I’ve covered our move from waterfall to Agile and provided an in-depth look at some actual release cycles. In this last post, I’m going to introduce a tool — which I gave the uninspiring name sdpbot — built internally to help facilitate the tracking of our releases.

Previously, I’ve examined the new development practices that the Songbird team adopted to plan and track a release. Everyone on the team was very eager to put them to the test. Unfortunately, at the time, we were still in the middle of the 0.3 release cycle and new work could only be started once that release was completed.

During the 0.3 release, everything was still treated as a bug, but in fact, many bugs were stories and tasks in disguise. We decided to apply some of the newly defined tracking principle to help us guide and finish the cycle, so we could start fresh with our next release as soon as possible.

This is the first post of a three part series presenting my experience moving the development of Songbird, a cross platform desktop media player from waterfall to an Agile process.