Every once in a while, if you’re lucky, you get to be part of an event that seems simple, but isn’t. An event that appears effortless, but is in fact based on a subtle combination of deep insight and hard-won experience. An event that quietly encodes a massive amount of tacit wisdom bubbling just beneath the surface.
That was how I felt when I attended my first Plone “sprint” last month.
A sprint (I don’t like calling them “code sprints” because a good sprint has a lot more going on that just the writing of computer code) is one of those deceptively simple-seeming events whose story deserves to be told more widely.
The sprint was invented by Tres Seaver from the Zope community back in 2002 as a way to drive forward the development of Zope 3. (It may well be based on the longer-form “hackathon” model pioneered by the OpenBSD community.) Since the Plone community is closely tied to the Zope world, the concept of sprinting quickly diffused over to us. The first Plone sprint was held in Berne, Switzerland in February 2003. Since then, there have been about 25 Plone sprints.
Here’s the gist. I think a lot of the details get lost in translation, because like so many experiences, the description of the is really no substitute for the experience itself. Let me know in the comments what I’m getting wrong.
A bunch of programmers, often of widely varying skill & experience levels, come together, possibly along with folks who can write documentation, speak to feature requirements, address usability issues, etc. They’re all volunteers, donating their time to the community.
The sprint starts with a short all-hands meeting coordinated by a sprint coach, who lays out the goals and helps folks break the problem into chunks and to organize themselves into workteams. There’s usually a couple of hours while folks get setup with the software and tools they need to be productive, and perhaps a presentation or two to bring people up to speed on specific bits of technology.
The teams go off and work, each with an experienced leader, break down into even smaller groups of 2-3 people, and start working away. At the end of the day (or at some interval) there is usually another all-hands meeting where folks report out on what they’ve accomplished. Cheers all around. A sprint can last anywhere from a day to a week, and can be dedicated to one very specific topic, or run in a more “open-space” fashion where many loosely related things are addressed in parallel. A sprint can be as small as 3-4 people, and as large as 60-70.
Sounds pretty simple, right? Well, yes. And no.
Ok, let’s break it down. A sprint is all-volunteer. It’s not a consulting gig. Some sprint organizers, especially folks organizing sprints to tackle very specific, complicated problems, will sponsor the travel costs of key attendees. But nobody’s getting paid for their time. Sprints are flat, non-hierarchical events (like open-source itself!) and that’s important.
Sprints are strongly rooted in the concepts of “extreme programming” (or “XP). That’s why we work in pairs (or occasionally, groups of 3-4). Extreme programming teaches us that having two sets of eyes but only one pair of hands on the keyboard results in better quality work. It’s not an approach that works for everyone, and it’s certainly not a panacea for software development, but for the talented, highly social generalists that tend to be attracted to open-source web application frameworks, it’s a great fit. More importantly, working in small teams, especially teams that mix experienced folks with newbies, results in a huge amount of hands-on teaching and learning.
As you might expect, sprints are highly social events. Along with conferences, they’re among the few face-to-face events where the globally-distributed Plone community comes together. And technology, as we know, is no substitute for beer. As bread is broken, the social ties that are the lifeblood of any productive community are formed. Sprints are part of the glue that binds us together.
The corollary is that sprints are one of the most powerful tools the Plone community has to bring new folks into the tribe. All you have to do is show up. Because of the open format for most sprints, you’ll get a chance to be part of a team, work with more experienced folks, share what you know, and achieve tangible results. You’ll have a great time, and leave feeling capable, confident and passionate. And even more that refreshing the social connections among existing community members, creating a smooth way to bring new folks in the door is what has allowed the Plone community to remain cohesive even as it’s grown exponentially over the past five years.
The Plone community has had sprints all over the world, and in some pretty fantastic locations. A castle in Austria (twice). A ski cabin in the Alps. A decommissioned military base on a Norwegian island. New York City. Vancouver. Vienna. Houston. My hometown of Seattle. 
What impressed me the most about seeing a sprint in action was the way so many small elements came together to produce an experience that was in many ways larger than the sum of its parts. The model has a lot of room for innovation, but certain core things you just have to get right in order to produce that magic blend of productive work and intense, immersive, peer-to-peer learning.
