Note: This is a guest post by one of our event sponsors, The Frontier Group

48 hours. Sounds like the perfect amount of time to run a sprint or two.

At The Frontier Group we’re big on Agile development. The Agile methodology encourages thorough analysis, strong teamwork, stakeholder collaboration, visibility, flexibility, accountability (and some other buzzwords). Ruby on Rails and Agile development really do go hand in hand though, so lets get down to business.

A typical Agile sprint might involve the following:

1. sprint planning - where the team gets together and assigns themself a set of tasks (or stories) to work on in the coming development sprint.
2. sprint work - the team starts building out the features chosen, hopefully by pair programming.
3. showcase and sprint review - at the end of the sprint, the team shows the end product, as well as recapping on any problems faced.

You’ve got 48 hours so what are you going to do? If you’ve done your planning up front, you’re probably ready to grab your team and jump in front of that shiny Macbook Pro and start banging around on your idea. If you’re looking for a bit more formality though, you could split your 48 hours in two and run two 24 hour sprints!

Before the Rumble begins, grab your team and spend an hour planning your first sprint of work. Be reasonable and ensure you’re committing to an amount of work you can get done. The kicker here is that after 23 hours, you have a full team regroup and showcase the features you were working towards in that sprint. The idea being your team should have a workable application at this point and it’s only the halfway mark.

Rinse and repeat for the next 24 hour block. Just like a typical Agile sprint, there should be no mad rush towards the end. You’re committing to a realistic set of deliverables from the outset, and you will get a great sense of satisfaction when your team delivers a measurable block of work by the halfway mark of the Rumble.

Given the naturally urgency of a 48 hour competition, it can be easy to throw any formalities out and just code, code, code. Adding a measurable process to your team effort might just see you as the winner of Rails Rumble 2010.