auberger.com

This is a following post to the series on Agile development at Songbird. As covered previously, we’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.

Songbird Release Trains

We concluded that a dashboard that was more dynamic and worked in real time with Bugzilla would provide a more accurate picture of development progress. This is an overview of the couple of extensions we added to the tool.

read more »

This is a repost of a series of article I originally published on Songbird’s blog

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.

Wrestling Bugzilla into shape

Because so much of our existing workflow occurred in Bugzilla, we’ve decided to use it as a central database to drive our process. Every actionable project artifact lives in Bugzilla, a Feature, Story, Task or Bug. From a release standpoint, the only actionable items are Story, Tasks or Bug and hence, we only track these. Here is how we’ve organized our bugzilla.songbirdnest.com to help us track each release.

Release train

Every release train has a name and is used to create a target milestone in Bugzilla. This allows us to put items in release buckets. See some examples of what was included in the Fugazi and Genesis releases.

read more »

This is a repost of a series of article I originally published on Songbird’s blog

Previously, we’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.

Cuánto es?

The first step was to add cost to everything. We introduced a new cost field in Bugzilla and put a cost value on everything according to our new scale of 1, 2 and 3 points. With costing in place, we were in a position to compute how much points the team was able to complete in a typical work week. That total, normalized per work day became our team velocity.

read more »