What would you say if I told you that you can double multiply the output of your development team while simultaneously increasing quality? Let me show you how I made this happen in a small team a couple of months ago.
When I joined autoplenum.de in October 2007, roughly 10 months after its founding, “phase 2” of the car community website was already under development by the same external shop that had completed version 1.0. Project planning for all the new modules and features were managed by the autoplenum product owner and the lead developer at the external company using spreadsheets, email and Instant Messaging. Everyone switched channels back and forth and important agreements, facts and discussions were spread throughout all three channels. So you found some tasks in a spreadsheet, detailed descriptions of the initial requirements in an email and the refined specifications were discussed over the phone and via IM. It was pretty chaotic and we faced a lot of issues:
- No central place for all the specs and discussions about a certain feature made it hard to get the whole picture
- Multiple versions of the spreadsheet-based task list lying around in multiple email accounts led to misunderstandings and confusion
- As so many things were going on in parallel, nobody had a clear overview about the current status of the development
- Usually all features for a release were shown for the first time to the product owner at the last possible moment (usually Friday afternoon or evening, with the release planned for Friday night)
- Ad hoc testing found a lot of bugs triggering hot fixes, which were tested even less than the original change. Of course, such fixes led to even more bugs, more hot fixes and so on – a downward spiral
As you can see, a pretty robust and typical approach for building software which I was now responsible for š
Luckily, the lead developer of the remote development team was very open to agile ideas and practices. That gave me room for improving the process. In this series I want to show you, step-by-step, which agile practices I introduced and how each of them brought me closer to the goal of doubling multiplying development speed while increasing quality. You will read about:
- How I introduced User Stories to break down big features into manageable chunks
- How the usage of a Backlog led to ruthless prioritizing
- Why I started using Story Points as an abstract measure of size, and
- Velocity – what will we be able to deliver this week?
Subscribe to Agile Web Operations via RSS to get all articles of this series!
Agile Web Operations 