2009/Effective code sprinting

From Open Source Bridge Wiki
Jump to: navigation, search

Code sprints are events where developers quickly complete coding tasks in a collaborative environment. A panel of skilled developers will share their experiences for organizing effective code sprints so you can better participate and organize your own. The panel members have organized and participated in over a hundred sprints (ranging from Django to JRuby) and used sprints as the primary way to develop community-oriented projects (e.g., Calagator). While most of the discussion will be about volunteer-run open source code sprints, many of the ideas will be readily applicable to improving development at your workplace. The panel will offer practical, actionable advice that you can use and answer your questions.

Speakers: Igal Koshevoy, Reid Beels, Audrey Eschright

Return to this session's details

Contributed notes

Slides from this talk


Share knowledge and tasks


how do you get there?

  • build a mission statement (two sentences)
  • invite people that you want to be there
  • build momentum
  • start getting the word out, advertise, put it on a calendar

so you've schedule a sprint, now what?

  • know what tasks (small solve-able tasks) to tackle for this sprint
  • define roles
  • be open to changes as they come up (ie what would you rather work on)
  • build in time for validation/QA for created work
  •  !!! set up project resources (ie source control, what framework, mailing lists, wiki ...)
    • make getting started simple
  • write up any documentation, or point to docs, that would be needed for any members on the sprint.



  • who's here
  • what skills do we have here
  • create an open environment, Encourage collaboration.
    • develop a shared ownership.
  • define standards
    • we need tests
    • all code needs comments...

short iterations (short like 45 minutes)

  • get task
  • do task
  • share what was done, how did it go?
  • take a break get coffee

The goal is to generate small, observable tasks. Make sure that at the end of the sprint you have something deliverable so that everyone can show what they did.

It also helps with keeping everyone on task, if some one starts to get distracted or hung up you get back to the group sooner so that you are forced to regroup and possibly shelve the task for a later date.

pair up, work in small teams

switch it up, share the love, it helps distribute the ownership. More eyes on the problem can help.

If you're leading the sprint then it is going to be your task for building these teams. Also as leader watch for any possible snafus that could show up.

take notes

Document the progress, what works, what didn't.

  • what was the focus
  • who worked on what
  • what was resolved, what wasn't
  • what new issues were reported?
  • you might not remember what happended last month, even 2 hours ago, take notes.

This establishes progress and gratification. It starts the planning for the next sprint.

This would differ from the 'blog post' announcement, thats for the general public and the goal is to generate interest. Where the notes here are for the project.


It helps to have others that can take over if you're out this month. Don't hold any secrets, you don't have to do this all on your own. There are many reasons why you can't make it this month, but that shouldn't hinder progress.

Train your replacement. Others can start to step up and fill your void, if you build the momentum, then it will happen.

Recognize your contributors

  • who submits bugs
  • who is on the mailing list
  • who contributes ideas, designs, code

share this list, make it public. it will help find new people for the project. Remember that they're volunteers, make it easy and fun for them.

Celebrate, have fun

have cupcakes.


not everyone communicates in the same way. Start to become very aware of inter-personal communcations.

Build consensus

This is not the top down model where you are told what to care about. Let go, just let things happen. Some times you just need to go out for beer, and reassess.

As host you sometimes need to play moderator, find the common ground, what are the larger goals.

Really it's not about a single method, it's about getting things done

Do what works. If something is not working try something else.


How do you integrate all the work for the day

submit to shared trunk

  • CON: creates a fragile system
  • CON: becomes hard to merge correctly
  • CON: you lose the ability to require things like tests and docs
  • PRO: the work gets published right away

everyone works on a branch, patch to trunk

  • CON: it's more work for the worker
  • CON: the workers changes might not get published
  • PRO: it's manageable


You can make remote code sprints work but you lose the ability to pick up on verbal cues. You can mix but it's a good idea to at least co-locate at some point.

is it good to have everyone show up?

sure it can cause some slowdowns (start up costs, getting people up to speed...) but aggressive friendliness is almost its own filter. You start to get people outside of the normal developer realm. For example, the FOSS = bad UI problem goes away as you start to have user interaction folks show up so that you start to have more voices.

are there metrics for contributions

You could do a commit level metrics but that misses the point, the most fair way is just keep a list in the notes.

Other resources

Community Built software, what I learned from calagator. http://tr.im/calagator_article

Calagator project wiki code.google.com/p/calagator/wiki