Moving to Scrum

Will they land on a rugby field?My first few weeks in my current role – now almost two years ago – were spent bringing some failing projects under control. There were just two developers working on different projects but both were under performing because of the same reason: too many rapidly changing requirements. The team is now completely different: much larger and dealing with larger projects with more complex technology, more customers and faster changing requirements. Two years ago I put in place a standard waterfall process; like most implementations it was flexible in certain areas and rigid in others. It served us well. It acted as a framework to introduce some basic development practices and enabled the team to deliver, mostly, to a defined time scale.

One of the truisms of development is that you have more users than developers; the users can invent requirements and file bug reports faster than you can develop. In an industry as faced paced as ours, this means fast changing requirements and priorities. There’ve been more than a couple of projects that were delivered – to time and to specification –  that were no longer needed by the time they were delivered. Of course this is not necessarily a development problem but a business one. Still what can we do as developers to help the business with their problems?

There are three fundamental things I’m looking for from a project management methodology: predictability of development times, the ability to cope with changing requirements and a known, preferably low, bug rate. For a small team, 7 at last count, of multi-skilled developers, designers, testers and DBAs, we regularly work on five main projects; most developments are quite small – taking from 3 days to a couple of months. With my current waterfall system it’s almost impossible to predict who’ll be working on what in a month’s time.

Enter Scrum. Two main things appeal to me about Scrum: I define development windows for each project (sprints), sprints can’t over run – they deliver what ever is complete in that time; and the product owner defines at the start of the sprint what he would like delivering during this sprint. This means that I get predictable time scales and the product owners get delivered what they want. Sounds perfect! I’m starting small with a couple of projects due to kick of this week… further updates will describe more of how we’re implementing Scrum and the results.

  1. No comments yet.

  1. No trackbacks yet.