auberger.com

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 »

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

This is the first post of a 3 part series presenting our experience moving Songbird development to an Agile process.

Drowning in the waterfall

Up until version 0.3, Songbird development had been following a fairly traditional waterfall model. Realizing the ambitious vision of building both a platform and a desktop media player has presented many challenges. A lot of plumbing infrastructure is needed before any features can be created. Faced with that challenge, the engineering team did what engineers do best, they designed a very comprehensive system, planned for it very carefully and started cranking code.

During the planning phase, the team estimated the work to the best of their abilities and a Gantt chart was created to reflect identified dependencies and track progress. Unfortunately, this approach led to lengthy release cycles (10-12 months) with lots of room for scope creep. When the release finally got completed, lots of good work was accomplished (over 1200 issues where addressed in 0.3 alone) but the lack of visibility was problematic and the slow pace of releases was too demoralizing.

We recognized that the schedule was build on assumption that we knew everything upfront. There was a sentiment that the whole Gantt thing was a little removed from the actual work and that overall “things were going ok, because we were kind of tracking it” was not an acceptable way to run our project. We had to accept that our planning and scheduling practices were broken.

read more »