I’ve yet to hear a self-respecting engineering team boasting about using waterfall development. Nowadays, everyone claims to espouse at least some level of agility. However, few are able to articulate what their development process consists of.

There is a lack of information about how development is actually performed in software companies around the world. Often for good reasons; they don’t want you to know.

Agile development methods are well suited to plan and execute near term releases¹. Those methods help us plan and steer a release over several iterations to reach completion with a good level of accuracy and repeatability. The rapid successive iterations that lead us there are akin to fast twitch muscles. They give you speed and tire quickly.

However, there are instances when the time horizon needs to be further out than the current cycle. The need to create a budget, synchronize a roadmap with a partner or determine future hiring needs, make it necessary to have an effective mechanism for long term planning. We need slow twitch engineering muscles that are good for endurance and can work over long period of time.

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.