Running a Sprintby Steve Holden
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.
A Background to Sprinting
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.
Pages: 1, 2