There are so many different approaches you can take when starting a new web project. In the past I’ve preferred to use an 18a take on the time tested waterfall approach. It’s what I was taught at uni, and it’s served me well over the years. Being a straight forward sequence of events; requirements analysis, design, implementation, verification and maintenance, it gives you a nice clear path from start to finish. But I’ve often thought this a little too rigid for web projects, which often have a habit of evolving beyond their original requirements or expectations.

So for the recent development of our new webservice rssa.at, we thought we’d give an 18a version of the Scrum development methodology a whirl and see how it works. I say a version of Scrum as we’re only a small team, so it’s more of a huddle/maul really 😉 For a full game you need 5-9 people. Also as this is an internal project we’re also lucky enough not to have a client (or chicken in Scrum terms he he), but the general principles of the development process itself remain.

So what is Scrum?
Well in the words of Wikipedia ‘Scrum is an iterative incremental framework for managing complex work’. It gets it’s name from a rugby scrum, which I thought was particularly cool and definitely worth looking into further.

The basic idea behind Scrum is to turn around a workable, shippable product in a very short time-frame. By breaking the project down in ‘sprints’ the team are able to get vital user feedback to determine the direction future development takes. There’s lots of funny terminology used in Scrum. For example, all roles in the process fall into either ‘chickens’ or ‘pigs’. There’s a joke which explains this a little more.

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

Haha that’s pretty funny! If you want to learn more about Scrum, there’s no point me just repeating it all here, take a look at the Wikipedia article on Scrum, it makes for interesting reading.

What is rssa.at?
We found that many of our clients had shiny new websites, but weren’t making as much use of rss as they should be. Rather than charge each individually for creating a customised rss feed of their content, we thought we’d develop a system which semantically parses their website and grabs out data suitable for the creation of a feed. Rssa.at then keeps checking the given page and updates the ‘live’ feed as new items are published on the website. The feed is hosted on the rssa.at domain, and as a result we can provide feedburner style usage statistics, as well as a few cool widgets, allowing visitors to sign up to receive email alerts when new items are published in the feed.

Our Key Reasons for Choosing Scrum
1. We didn’t really know exactly what we wanted rssa.at to do, by getting something up on the web quickly we’re able to gauge how people use the service and what they might want from it in the future. We had lots of ideas, but as this isn’t a project with any real ‘return’, we didn’t want to get too carried away with our development.
Breaking up the task into sprints helped us focus on what we wanted to deliver and the priority of each task. When time and resources are against you it’s important to calculate the potential benefit of a feature, against it’s ‘cost’ in terms of development effort. I’d love to sit around all day tweaking code, but unfortunately we live in a business world where ROI matters most of all.

Would we use it again?
Yes, most definitely. For projects where the requirements are less than clear and where a rapidly developed prototype is required to ‘test’ the waters, it’s a great approach.

1. The daily meetings really helped keep us on target and focused on the task in hand.
2. I particularly liked the idea of freezing sprints to a certain set of tasks, this helps reduce scope creep and delays. There’s nothing worse for a developer than moving goalposts!
3. By outlining user stories in the project backlog we were easily able to prioritise development of features which added the most value to the project. We’re full of ideas, and we still have 1,000 other things to add in, but for now, we have a working version of the service up and running.

So give it a go create an rss feed and give us some feedback.