RailsRumble 2010 Redux
“On your mark, get set, GO!” Nothing like the thrill of starting an intense race, whether it be a short hundred-meter dash or a long, grueling marathon.
In our case, October 16-18, 2010, the RailsRumble 2010 48 hour competition, was a bit of both. We, Chris Kelly and myself with help from Jim Hodgson, represented Highgroove in friendly competition with over 150 other teams.
Much like other tests of physical prowess, participating in the RailsRumble becomes more a competition with yourself as you face challenges and battle yourself.
We of course had obstacles to overcome and odd things to bang our heads on, but we minimized our stress by setting up continuous testing and deployment with CruiseControl and Chef. Within minutes we had a deployed Rails 3 app and a failing build, hands free.
Our goal from the beginning was to build an app that helps our Results Only Work Environment track our results, holding us accountable and encouraging us to do so long term for things like team bonuses, quarterly reviews, et al. Having talked internally at Highgroove, especially with Charles Brian Quinn, the lead consulting partner, and Megan Zaki, our office manager, about how we do things and how we should be doing things, we were able to formalize a plan. As soon as the competion began and we had our infrastructure problems solved, we set off immediately to fill our Pivotal Tracker project with lots of stories. We set our velocity ridiculously high and set up releases and the imminent deadline. It was definitely important for us to know our plan of attack and to see what all remained to do.
At the end of our sprint, we had a functional application that could meet the minimum of our needs: Pivotal Tracker integration for results based on stories, helping us keep track of our results for iterations (weeks, in our case), and the minimal reporting needed to make sure we were on track in the short term. We definitely aspire to keep on crafting this into a tool we use daily in our organization and to help us stay organized, but before we do that we will be taking a step back and making sure this first prototype is the right direction.
The most important part of this competition for me is the personal challenge involved: motivating and kicking my own ass to stay focused and productive, making sure I’m not wasting my time doing things wrong, and making sure I’m producing at a high quality consistently.
I recognized in myself stubbornness and determination that is valuable but easy to cut myself with when I don’t learn to fail fast and find a better solution than the one I’m working on (that is clearly not working). I struggled with simple things like buggy Rails 3 support in Authlogic (“surely I’m doing something wrong… just what is it?”) and trying to do things “the right way” according to someone else’s library: I have to remind myself at times that I shouldn’t necessarily trust my tools so much and that my judgement is best for my situation. Essentially, I have to learn to trust myself better, and listen to myself sooner.
I know that I may not be very fast, but what I do produce is high quality. Putting myself under the knife and really pushing myself in a competition like RailsRumble has both underscored these things and helped improve both simultaneously. Practice makes perfect, but it also makes you faster.
Chris is also fairly new to our team and I haven’t had a lot of time to work on any new projects with him, so competing with him in the RailsRumble gave us this opportunity. Being the drivers for once allowed us to butt heads plenty and will help us work together in the future.
Everytime we felt like we might be getting stuck or heading down a rabbit hole, we reminded ourselves to keep a “bias towards action.” We do this in our daily work and it was especially important to keep true to it during the competition. This phrase is definitely at the heart of an agile team.
We crossed the “finish line”, or more accurately the deadline, about an hour before 8PM EST, midnight GMT. Instead of being panicked and running around unhappy and nervous, we sat back confidently sipping beers with our application tested, deployed, and functional. “We won’t win” (we didn’t even make it into the public voting round), but we met our goals and learned more about ourselves.