The sprint's goals must be clear and well-understood, especially since so much is to be accomplished in a few days. "Some sprints encourage each member to bring their manifesto to the sprint," says Whatcott - a personal statement of what should happen, so they aren't staring at a blank white board.
Many projects already have a priority-setting process in place. During the leadup to the sprint organized by Stahl, he says, organizers used UserVoice.com to capture, discuss, and rate ideas from the user and developer community. "While we strongly suspected our highest priority ideas were both uncontroversial and popular, UserVoice helped us validate this, and also surface a bunch of great, complementary ideas that we worked on during the sprint," he says. "It opened a channel for people who couldn't participate [in person] to have some input on the process."
Mostly, it's important for the sprint sponsor to help the community create software. "You don't need to dictate a lot of rules," Englebienne says. "We're just helping the existing virtual group getting together and letting them do their thing," adds Whatcott.
One area in which the sponsor can help is technical guidance and coaching, particularly when the sponsor has expertise to be integrated into the open source project. "You can do tech talks to get them to a certain level on a particular technology," suggests Englebienne.
Every sprint has its specific goals, and enthusiasm can encourage a lot of productivity. In 24 hours, says Globant's Englebienne, the hack-a-thon produced three pieces of software: a mobile application using J2ME, a library management system in Python and Django, and something for the Travelocity portal. While they didn't finish everything intended, the teams noted all known issues and released the software. It's open source, after all; others can add more functionality later.
Stahl's sprint goals were to add a handful of specific features to PloneFormGen to better support features the company is building, among them online donations and online advocacy. A few weeks afterwards, PFG 1.5 was released, including work accomplished during the sprint. "We're now using PFG 1.5 in production with our clients," Stahl says. Not bad for a few hundred bucks worth of investment - for functionality the Plone community already wanted.
Making the Sprint a Success
Your company needs a champion to organize the sprint's logistics and connect with the community. Although Whatcott is a marketing guy, he says the right person ideally is an engineer, as techies often are better received by the development community. (But there's a role for marketing here, too; we'll get to that in a bit.)
Most sprints have 5-10 participants. Globant's sprint had 6 people in Buenos Aires and 12 to 15 in London, for instance. But multiple sprints can happen concurrently. When I participated in a sprint a few years ago, sponsored at Google, two teams worked side-by-side.
Advice for Sprint and Hack-a-Thon Organizers
Jon Stahl, director of Web Solutions at ONE/Northwest, offered several important suggestions for how to make an open source sprint a success.
- Focus, focus, focus. Know what you want to accomplish.
- Get the right people in the room. Include the lead developers of the product, feature or subsystem you’re trying to improve to ensure you have the technical talent you need.
- Check that your ambition matches the time, energy and talent you have available. Communicate with key stakeholders well in advance, so you can be sure the innovations you’re developing fit into the product you’re working on.
- Remember that the sprint model is volunteer based, and thus driven by passion. People sprint most effectively on topics that they care a lot about.
- Structure the sprint to foster learning. Learning (and teaching) are a big motivation for many sprinters to volunteer their time.
- Sprints are social, community building events. Make the time and space for participants to relax and hang out together.
Assign a local host to be with the developers most of the time - "someone who can go grab pencils," explains Whatcott. Among other logistics to consider: Make sure the developers have great Internet connectivity with access to the guest network. Provide a war room where the sprint team can work in privacy; don't make people jump from room to room. Don't forget access cards so developers can get into the building. Rasheed also cautions patience and commitment. "A key thing is to listen, define the requirements and create clearly measurable results," he says.
Some sprint organizations may be managed by the developers themselves. For example, during Englebienne's project, one person acted as scrum master, setting objectives, and running hourly stand-up meetings and hourly sprints to track goals and celebrate progress. Developers organized into groups: one in charge of bug fixing, others to design and build the project site, yet other developers to buzz the experience.
The "buzz" can be important. Englebienne recommends that one participant serves as the sprint's recorder, managing blogging, Twitter, Facebook, including pictures and video. The blog lets people follow the process, and it gives the community a way to remember the event.
Buzz is important for the sponsor's marketing, too. Whatcott recommends a company representative (perhaps the champion) write about the sprint in the corporate blog and its Twitter stream. "It should be part of the face of your company," he says. "One of the objectives is to increase your credibility (without tooting your horn too much)."
The most obvious benefit for a company to sponsor a sprint is that it can help the open source project upon which it depends get the functionality the company desires - for dirt cheap, really. But the ROI is much deeper, even without considering the karmic payback to the open source community. If you attract the project's top developers, it gives your in-house developers access to smart people they can learn from. Also, says Englebienne, a sprint is a good way to detect talent in your organization. And if you've been wanting company management to expand its software development methodology consciousness, they'll see a new paradigm for developing software.
"It's not just about the source code," says Englebienne. "It's the experience and the process."