Running a code sprint

The first time I heard the term “sprint” for software, it was in the context of Zope. A ZopeMag article also credits Tres Seaver at Zope with this and talks about how Zope Sprints are run. I decided to write up how I’m planning to handle this Saturday’s TurboGears “Dilly” Sprint in Ann Arbor in hopes that I’d get some useful commentary. This will also provide tips for the people who are coming.

This is the first sprint for a “new” project. However, true to the ideas behind TurboGears, some of the people who are coming have previously worked with TurboGears parts, mostly CherryPy, before. There’s the possibility that one of the project founders will make it… fingers crossed! Everyone has some level of Python experience.

This sprint is only one day (10AM-3PM). I have no illusions that a group of new people, working together for the first time with new tools, are going to produce thousands of lines of code in a short day. I’d like for people to come there, have fun, get some ideas together for the “Dilly” (0.9) release and write some code in that direction. After the day of the sprint, we can pick up the work that was started and finish it up. By making the sprint just one day, I’m sure it was much easier for people to work into their schedules.

As in the Zope sprints, I’m planning that we’ll do pair programming. For the circumstances that I described in the last paragraph, pair programming will be a big help: two heads are often better than one at generating ideas, and people will be able to help each other find the best way to work on something. Beyond pair programming, I’m planning to use a lightweight, XP-based process that I’ve worked with before. The day will be broken into roughly 1 hour iterations, which will give people a chance to check in with the rest of the group, collectively work through any problems and validate solutions that have come up.

I’m planning to create several team logins with commit access to the svn repository so that we can do frequent integration. As long as all of the computers have Python and Subversion installed at the start of the day, we should be able to get going pretty quickly.

Comments from anyone who has run a sprint or attended a sprint would be greatly appreciated…

5 thoughts on “Running a code sprint”

  1. While we may not be able to get all or any of the projects complete, this should be a good project building exercise.Personally I am looking to learn more about TG and find places where I can contribute.

  2. Here are a couple of things I have found important in making a sprint successful:

    – Get a whiteboard which everyone can see (a wiki can work, e.g.
    http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/CMF20GoldeggSprint2005

    – Especially for such a short sprint, pre-populate the whiteboard with a list of discrete
    tasks, ideally ones a pair could knock off in an hour or two. Normally, the first part
    of a sprint is taken up with brainstorming / prioritizing these tasks, but a single
    day won’t leave enough time to get actual work done as well.

    – Encourage people to change partners between tasks: a lot of the value of a sprint
    is in the relationships your developer community builds, and mixing up the pairs
    helps make a denser mesh.

    – Try to ensure that everybody arrives at the sprint with a working development
    sandbox already on their laptop, so that even in the networking is manky, people
    can still get work done.

    – See if you can get the networking set up the day / night before, and test with several
    different laptops.

    – Arrange for snacks and drinks close at hand, if possible.

    – Plan a wrap-up session where people report progress and issues at the end of the
    “main” day, and then go out for dinner (extending the coding period late into the
    evening can be fun, but is often less productive, and may not fit the circadian
    rhythms of all your sprinters.

  3. Thanks for the links, Martijn!

    Good food for thought there.

    This sprint is a little different from many in that most people are local (members of MichiPUG coming to help out, learn and have fun). There are a couple of out of town people, but they’re just driving in for the day.

    Still, I do realize that one day is very brief, but then TurboGears is a 3 week old project 🙂

    As it matures and people use it more, a larger sprint becomes a real possibility.

Comments are closed.