The world of programming is seeing a lot of change in methodology, much of it is associated with "agile" techniques such as Scrum and pair programming. If there's anything traditional in the world of agile development, sprints are the traditional way to give a project a boost by focusing the efforts of a group on specific development issues. While typically a real rather than a virtual event, a sprint takes advantage of physical proximity of team members. This makes it popular at events such as conferences, which naturally increase the developer density above normal levels. Open source conferences now frequently feature a sprint before or after the conference proper.
Open source is taking over more of the software infrastructure in commercial enterprises. The commercial world has woken upto open source techniques and technologies in a big way, and with this comes the realization that a sprint is a practical way to support and encourage improvements in the open source software on which businesses are increasingly reliant. By organizing or supporting a sprint, the users of open source software can ensure that their infrastructure continues to receive attention, sometimes with a focus on specific development goals.
The Python Need for Speed sprint in Reykjavik, Iceland in June 2006 would not have occurred without the encouragement and support of a commercial sponsor with a specific interest in improving Python's execution speed. Google has just held its first sponsored sprint (also Python-related), with parallel sessions in New York and Mountain View. While these two sprints were quite different in nature, they both aimed at improving the implementation of the Python language.
Organizing a sprint like the Need for Speed is demanding, and sponsors are entitled to fair return on the resources they provide. My goal is to highlight some of the organizational aspects.
In the U.S., Python conferences started sprinting at the last independent International Python Conference (IPC), and sprints have been a major feature of PyCon since its inception in 2003 (the IPC is now a track of O'Reilly's OSCON). For some Python projects, PyCon has been the only chance for project members to get together in person, and the community conference has been an important stimulus and annual focal point for projects as diverse as the Twisted asynchronous networking framework, the GNU mailing list manager Mailman, the three-tier application development platform Dabo, and many others.
Projects such as ZOPE and PyPy use sprints as the primary way of maintaining developer involvement, and travel the world running sprints. Clearly not everyone can afford to travel internationally, so migrating your sprints is one way to recruit wider participation in your project.
Organizing a sprint is a great opportunity to represent your concerns directly to a cross-section of the developers, possibly over dinner or a libation or two (or both). You can learn useful things from the developers, and again some fairly modest entertainment is a gesture of appreciation.
Open source's increased popularity means that many newcomers will join the developer community in the foreseeable future. These programmers may need training, and a sprint is a great way to pass on the knowledge required of developers. A sprint can teach new programmers about the intricacies of the design, show them how to use the build system and any reporting mechanisms and so on.
How do you go about organizing a sprint? While there are no hard and fast rules, by looking at the options you might be able to maximize your returns. This means being clear about your sprint's objectives, communicating well about its purpose, and getting people enthusiastic about the goal.
First, do you want your sprint to be an independent event, or will you piggy-back on some existing activity? By going on your own, you reduce the number of distracting activities, but you also face the work of recruiting the (right) sprint members. That is why conferences are a popular choice as a sprint venue: a variety of projects will be able to draw talent from the conference, and there is also the chance for the sprints of different projects to interact with each other. This crossover is natural and frequent.
If several sprints are happening at the same time and place (a multi-project sprint) it helps to have an overall organizer. Each individual sprint should have a chair or leader who can set the agenda and keep individual participants in the loop. The overall organizer can recruit the chairs, ensure that there are sufficient resources for the individual sprints (or set limits on the sprint when no more resources are available), and help to publicise the sprint opportunity. Here is an example of a sprint announcement.
Delegates can be invited by the organizer or the sprint chairs, but in the open source world even commercially-sponsored events are usually open to anyone who can contribute. For the Need for Speed sprint, the main sponsor invited several individuals, paying their air fares to the venue and accommodation costs. That particular venue was expensive in open source terms and so, despite a couple of inquiries, nobody else attended.
Communications between the organizer and the chairs, and between the chairs and their participants, can use email but often a medium such as a Wiki is more suitable for recording decisions as the nature of the event becomes clearer. Not only does this make group communications easier, it also allows newcomers to get up to speed faster, with decisions being recorded as they are made. The Need For Speed sprint's Wiki pages are an example of what you can do without too much formality. If you require an issue tracking system, then it will usually be available from the relevant project across the Internet (underlining the need for good connectivity).
The role of the sprint chair before the sprint involves recruiting the right people, helping to establish the technical goals, and determining what methods to use to ensure that everyone gets a chance to contribute to the extent of their knowledge and abilities. Once the event is underway, the chair can take the leadership role or can act as a non-programming administrator.
Sprints are a good way to induct newcomers to a project, but if you don't want to leave them feeling stranded. When newcomers join it's a good idea to make sure they have studied any necessary background materials and start then with an introductory session so they don't feel lost. The techniques used in the sprint can also be helpful here--pair programming is a commonly-used agile technique. So by putting the less experienced members of the group with older hands you can ensure that they pick up the needed knowledge as they proceed with their chosen task. It's also important to make sure that newcomers are sufficiently fluent with any necessary toolkits.
Location can be very important. While exotic faraway places seem initially attractive, they can reduce attendance if travel there and back is too expensive. The same is also true of the cost of living--you don't want people to have to live too cheaply and not afford to enjoy a little sightseeing in their spare time. To some extent, this depends on how the sprint is funded. The PyPy project, for example, has received funding from the European Union and has adopted an evangelical approach to sprints, holding them in locations from Ireland to Japan.
Choice of venue can be tricky. Hotels and conference centers can usually offer everything you need in the way of facilities, but will expect you to pay (and often handsomely) to use them. One way to keep costs down is to find a company that will support the sprint by hosting it on its premises. This will limit the available facilities, but as long as the company performs some sort of software development, it will probably have everything you need. If you can't find a helpful company, then consider an academic institution or a professional body: both these types of organization are used to renting out space and they are usually competitive with more openly commercial venues.
Whatever your choice, it is important to establish contact early on with a single individual who will be able to put everything together for you at the venue. There is no time to learn the structure of the organization, so you need a single point of contact for all your needs. It is extremely helpful to be able to make a visit to the site in advance of the sprint to get an accurate idea of what will be available. Brochures make it look as though everything will be perfect, but the reality on the ground can occasionally offer a stark contrast.
The facilities required by a sprint are relatively simple. Clearly, you need some dedicated space, and it helps if there's one area where people can work undisturbed and another where they can hold discussions to iron out tricky design and implementation problems. There's no substitute for good Internet connectivity, which is essential because most projects use a source code repository on the Net. Email is also essential to most participants. Internet relay chat (IRC) or other instant messaging services can also be helpful, and some sprints use teleconferencing facilities from time to time (though few might consider them essential yet).
Physical connectivity is less of a problem than it used to be, as nowadays most sprint participants will have 802.11g-compliant networking. Make sure that network access doesn't become a bottleneck by providing several access points. It's also a good idea to provide a few hard-wired ports for the occasional participant who arrives without a wireless card. Network topology can be important if you use peer-to-peer networking: most modern wireless access points combine routers that hide their client addresses behind a NAT gateway. This can make it difficult or impossible for the individual hosts to communicate with each other, though standard Internet client applications requiring only outbound connections work fine. (Beware also the number of available TCP ports; developers tend to make many more connections at a time than do average users.)
Telephones are a less problematic than they used to be now that most people have cellphones. Do bear in mind that international roaming charges can be fierce, although you can mitigate this somewhat by contacting your provider in advance. Many cellphone companies can provide preferential rates with advance notification. Of course, nowadays Skype and similar VoIP services can offer significant savings on international calls.
Once everyone arrives, it's up to the sprint chair(s) to put everyone to work. There is room for all kinds of approaches and way too much variation to be able to summarize them, but the main chair's main focus should be primarily logistic.
The surroundings should be comfortable rather than spartan. People will be spending a great deal of time on those chairs, so try to make sure that they are bearable for a full day. Some groups like to have a white board or flip chart easel available, and pens and paper are always useful. Coffee is likely to disappear in great quantities and, ideally, water should be available at all times (coffee is a diuretic, so the water helps to avoid dehydration as well as providing something for the odd participant who isn't addicted to caffeine).
It's useful to have periodic review sessions in which each participant or team can report back about the progress they have made and solicit help from others. These sessions don't need to be formal or lengthy--in fact usually the less formal they are the better. Be sure to record goals and progress; a Wiki is an excellent medium for such records.
Occasionally, some team members might become discouraged by an apparent lack of progress and this can call for some coaching skill on the part of the sprint chair. Although sprint participants are generally undemanding, everyone needs to eat, so it helps to have a list of local eateries--many people will eat and work, but some enjoy the chance of a break for a meal. At the Need for Speed sprint, the chair bought the first day's lunch at the (hotel) venue to promote social interactions that might otherwise not have occurred until later in the week.
IRC channels can help to maintain communications with interested parties who aren't able to attend, providing additional resources for the development work. If the project has a mailing list or newsgroup, then it is probably a good idea to post occasional feedback about progress (or the lack thereof) to keep the broader community informed.
Although sprinters will usually work hard without the need for external applications of pressure they also need to relax. Social events can help team members form relationships to the ultimate benefit of the sprint, and a change of scenery for a meal (or something a little more out of the ordinary) makes a welcome break and provides a useful change of pace. It's also a nice way for sponsors to say thank you to hard-working developers.
Nowadays, many people carry digital cameras with them as a matter of course, so you will probably find that many images of sprints are available. Try to get the photographers to upload photos to a service like Flickr with a unique tag (pyneedfor speed on Flickr). This can serve as another record of the sprint and hopefully encourage others to create similar events and allow participants to look back fondly on their experiences.
Sprints are a great way to move a software project forward, and it seems likely that they will spread outward from the open source world (assuming that proprietary software remains a feature of the landscape). They can be fun and can enhance other events running in parallel, attracting wider participation in worthwhile software projects.
Even open source software costs something to develop, though programmers and designers frequently provide their services free of charge. If you want to encourage open source developments, think about organizing a sprint for the development team of your choice. If you lack experience, there's always the option of sponsoring the sprint and letting someone else put it together.
Steve Holden chaired the first three PyCon conferences and organized the Need for Speed sprint. He will be happy to help you if you would like to sponsor a sprint of your own.
Return to the Python DevCenter.
Copyright © 2009 O'Reilly Media, Inc.