What is a "Sprint"?

As used by Zope and Python folks, a "sprint" is an intensely focused session, usually lasting less than a week, in which a group of developers work together to design and implement features for a library / framework application. Many conferences now host sprinting in the days before or after the conference proper, but there are also lots of sprints which occur outside of any conference.

Where did the term come from?

Back in the fall of 2001, I had my first (and only) performance review at Zope Corporation (then Digital Creations). As part of the review, Jim Fulton asked if there were any changes I would like to see in the way the company developed software. At that point, the official process we used was pretty heavy, with lots of "Big Design Up Front" artifacts.

I had been following Extreme Programming (XP) via the "mother-of-all-wikis" since the mid 1990s. I suggested that it would be good to find a way to experiment with some of the practices of XP, but in a way that wouldn't involve making a big committment to the whole discipline. We were in the early stages of re-writing the Zope application server, and decided that we would hold a short, in-house session (four days), where we would consciously attempt to apply as many of the XP practices as seemed feasible while working on the next-generation Zope.

Because we had only a short time to experiment, but still wanted to achieve a significant delivery milestone, one of the XP values we didn't embrace was the notion of software development as "long-distance running" (no overtime, etc.) We therefore began to refer to the upcoming experiment as a "sprint".

The goal of that initial sprint was to (re-)implement the "Interface" package, which prototyped the PEP 245 interface semantics (but not syntax) for Zope2. The new package we built, zope.interface, is still the core of the component architecture today, and is used by projects such as Twisted and Pyramid

The results of that first trial was terrific: we found that the practices we applied (pair-programming, test-driven development, YAGNI) led to a very productive outcome. More imporant, we found that the four participants left with a much stronger understanding of the design of the software we had built, and were therefore much better able to keep working on the code separately.

Sprints as Evangelism

Reviewing the successes of the first, in-house sprint, we wanted to find ways to repeat the process. In January of 2002, we were trying to design a new, in-core mechanism for translating software-generated text (from templates and Python code, rather than user-entered content). We came up with the notion of invitng the authors of the main Zope2 i18n/l10n products (Stephan Richter's ZBabel and Juan David Polomar's Localizer) to ZC for an "i18n sprint".

Jim Fulton, Juan David Palomar, and Stephan Richter at the I18n Sprint, hosted at ZC's headquarters, January, 2002.

As we had hoped, this sprint laid the technical foundations for the i18n support in Zope-related code to this day. Beyond our imagining, however, was the impact the sprint had on the non-ZC sprinters: they were fired up about the new technology, and were able to go back to their own communities and rally support for it. Indeed, one of those sprinters, Stephan Richter, went on to write the first Zope3 book: he is still active in the Zope software world to this date.

From that experience of the social/organizational benefits of sprinting, we began scheduling sprints to take advantage of participants expertise and interest in the new Zope software, and were thus able to expand the committer base to 400+ committers over the next three years.