We’re a small team of professional developers by most people’s standards. By day, we all work on a product using some pretty cool, modern technology and by night, we’re transformed into intergalactic space cops or horse murderers (that’s a reference to Red Dead Redemption, just to be clear). Well at least, that’s what happens when we don’t decide to work and/or procrastinate on Meteor. I thought it would be an interesting idea to let everyone know how we juggle the rigors of full time work with the trickling momentum of a project that we’re doing for fun; both the good and the bad.

Momentum

One thing that we’ve struggled with consistently is momentum. In a team of 4 guys who all have hobbies and other commitments and annoying partners (just kidding; not all of us have partners), there is always that “other thing” to do; always that rustler to hogtie, always that zombie to kill and always that hill or staircase to sprint up, and as such, a project that we’re doing for fun suffers the inevitable peaks and troughs. Generally, we’ve been fortunate in that when one of us is having a lull, another is working full-steam ahead and so on. There have been times, in the last couple of weeks, especially, however that all work has ground to a halt. There are some things that we’ve done to get around this, and in general, they’ve been effective.

Being Agile

One of the things we’ve picked up at work that I think’s been pretty effective is Agile development; Scrum in particular. It’s one of those things that’s really good for a small team like us to keep focused, but it’s also not so rigid that we can’t just flip over and try something else out if something isn’t working. Just as a warning: the next couple of paragraphs have a few terms in them that require some familiarity of Agile and Scrum to really understand. It’s not necessary though.

Now, as far as this project is concerned, we’re not following the process down to a T; more picking and choosing things that will work for us and the environment that we find ourselves in. Basically, what with full-time work and other commitments, we’re looking at having 3 hours a day per person to work on Meteor at the very most, which isn’t really an ideal work situation. As such, we’re not doing things like daily scrums as that would just be impractical and we’re not keeping daily burndown charts to see what our progress is because, again, that is pretty impractical. We are however using the Scrum way of tracking work, in chunks called “Sprints”.

Another important process that we’ve taken on at our day jobs and something we’ve adopted for our own projects is the process of creating User Stories. The link is better at explaining this than I am, but basically a User Story is an item of work, written in the perspective of an actual user that contains no implementation details, just the core “needs” or “wants” that a user has. I think it’s a very important distinction from a regular RFE which often contains bias from the reporter. It took us a really long time to convince the product owners at our actual job to remove all of their bullshit; I mean, perfectly legitimate implementation strategies; from their requests and then we can go about the job of prototyping, reassessing and then implementing. Now that it’s been fully embraced, I think it’s an absolutely excellent way to do things. Building software that fits what a user wants? What an amazing concept.

Technology

So, what we’ve done is we’ve taken some of the parts of Scrum that suit our project; like Sprints, which are “chunks” of user stories implemented over a set period of time with a particular goal in mind as well as User and Technical stories and combined them with some really good online technology and it’s managed to keep most of the momentum up across the board.

The technology aspect of how we work is obviously extremely important. We need things like source control, we need things like project tracking and we need things like work/issue tracking; I used to actually work without any of these things and it just absolutely amazes me how anything managed to get done without them. So we spent quite a long time looking through online services looking for something that fit us. We started with an account with a service called Unfuddle. It’s probably easy enough to read the website, so I won’t go into everything that they offer, but we found that for a small group of developers, they had a fairly robust set of features: source control, project management and issue tracking; basically all that we were looking for. However, there were some restrictions that we found that we couldn’t really work around, so we had to look elsewhere.

Eventually, we came across a service called Codespaces. They offer a very similar service to Unfuddle, but for about the same price, there were definitely really compelling differences. Not only do they offer unlimited subversion repositories, but their website offers a user experience that really allowed us to go “all in” with the Agile stuff that we wanted to implement. We could set up milestones (sprints) and assign chunks of user stories to them and track how they were going. It’s not perfect, but for the price, it’s absolutely compelling and it’s been working really well for us.

For reference, at work we use Atlassian’s excellent JIRA along with another product of theirs called GreenHopper for all of our Agile project management needs, and it’s actually a really good system now that it’s all been set up. That sounds like an absolute shill, but I wouldn’t recommend something if it was garbage. These things actually really help, so use them if you need them!

Filling the Gaps and Having Fun

Honestly, we’ve had far from a perfect run. We’ve had times where we’ve all been standing around a whiteboard in the middle of a day thinking “what the ef do we do now?”. Similarly, we’ve had times where we’ve just had so much to do and so much momentum going that everyone is just too busy to think about what to do next; it’s a bit of a balancing act that we haven’t really managed to get 100% right, but we’ve been doing pretty well.

One thing that we’ve done to try and get the fires burning again is what Simon assures me is called a “codejam”. Basically, what it involves is everyone getting together on a particular day and just coding – pretty much for the whole day. Most people would just call this a “day of work”, but when you’re not actually getting paid for this stuff, it’s a little bit more difficult to clear it with the partners who all think that you should be spending more time with them! In all honesty, we’ve really only had time to have one of these codejams, but it was pretty successful; though I will say that if you’re going to attend one to do some actual work, it’s probably a good idea to bring a machine that you can do work on, and not just a netbook. While they’re fantastic for doing things like browsing the internet and getting email, they’re not the best things for serious development work.

Here are some snapshots of our last codejam:

I'm doing my best impression of origami in this shot. Fitting a 6'5" guy in the back of a Holden Astra is not the easiest thing ever.

Here's our work area, complete with requisite iced coffee and coke bottles; a programmer's fuel.

Does this help?

The goal of this post was to let everyone know how we, as a really small team of developers, who all work day jobs manage to get things done outside of work hours. It’s not the easiest thing to do, and hopefully I’ve shed some light on our processes. We’ve spent a long time developing them both professionally and personally and find them to be really condusive to “getting things done”, and in the end, that’s what it’s all about. Getting great software done and out into people’s hands.