FiveRuns Blog

For fun, I though I’d share some tidbits about development at FiveRuns.

Let me start by setting the stage…

We have a stunningly sharp team of five Ruby on Rails developers – Bruce, Mike, Brian, Eric and Adam – four of them here in Austin and one remote. Additionally, we work with Chad Fowler, Rich Kilmer and Dave Craine at InfoEther as well as two other contractors part-time (Ian Warshak and Ryan Heneise).

At any given point in time, there’s several different projects underway – we are maintaining two existing applications already in production, doing a huge amount of work on a new version of an application as well as some smaller projects we’re kicking off or maintaining.

From my POV, the underlying principle to our development approach is simple: feedback loops – make sure they’re closed, make them tight / small, look for open loops and figure out how to make them closed.

So how is this realized in our day-to-day work right now?

We take Scrum as our starting point and adapt it. Looking at our work from a ‘feedback loop’ POV, you would see:

• Release – this is our largest / longest ‘feedback loop’
  • at the beginning of the release, we take off the ‘right’ set of user stories from the product backlog, using their high-level estimate, we create the release plan (aka release backlog)
  • while in development for a release, we may adjust what’s in the release in response to new knowledge (e.g. market changes, new product knowledge, new project knowledge, etc.) – by adding or removing user stories from the release or by changing the scope of user stories in the release.
  • the feedback loop is closed by the results of the release – actual release into production – the marketplace gets to see the results and we use their feedback to adjust course for the next release.
• Sprint – this ‘feedback loop’ is typically two weeks long
  • at the beginning of a ‘sprint’, we take off the most important user stories off the release backlog, estimate out how much we can get done by the end of sprint and identify the tasks for each user story.
  • at the end of the sprint, we take whatever user stories are complete and present the development results in the sprint review. This garners feedback internally – the larger company gets to see the results and we use their feedback to adjust course for the next sprint.
• Daily stand-up – our smallest ‘feedback loop’
  • each day individual developers identify what they’ve done since the last standup, what’s to be done between now and the next stand-up and any obstacles; this organizes the flow of the teams work into smaller increments around a similar feedback pattern, results from each developer are visible and this visibility enables feedback to adjust course as needed.

Additionally, for tools we are happily using Mingle to manage the user stories, product backlog, release backlog / plan and sprint backlog. As somewhat of a tool junkie, I’ve used a variety of tools and Mingle comes closest to the tool I’ve wanted to build myself.

This is working well for us now and we’ll continue to evolve from here.

However, I can’t go over all of this without some what of a commentary: most of the approaches & tools I’ve seen pre-suppose a single team works on a single product / project, i.e. a 1-to-1 relationship between a project and a team. It’s surprising how often this is baked into both tools and approaches – yet I can’t remember the last time this was true for me or any of the teams I’ve worked with. In my experience, and here at FiveRuns, there’s typically a single team and mutliple projects that may be underway – even during a single sprint, i.e. a 1-to-many relationship.

Mingle (Trac, and the other tools I’ve tried) come by default with a 1-to-1 relationship baked in – they treat the project as the largest container, and the team is assembled within the container. So not only does this place the project as the highest order concept, it insists on the 1-to-1 relationship. This is especially noticeable in Mingle because it is so close in its inherent flexibility, e.g. defining different cards, properties and views – but it doesn’t extend that same flexibility to the relationship between teams and projects. I hope Mingle moves toward more flexibility in this way and enables us to use Mingle to better model our actual situation.