Bowst Team
On June 5th through 7th, Bōwst was proud to host NH DevDays 2, which was part of the New Hampshire Drupal Group’s series of contribution sprints. Scott Reeves already wrote a detailed post about what was accomplished during the sprint, so I thought I would share some lessons I learned about organizing sprints in general. 
1. Watch this webinar from the Drupal Association.
It contains a lot of great information about how to host a successful sprint. There are a ton of logistical details to follow when organizing any event, and sprints have their own specific set of guidelines. For example, you’re supposed to notify the Drupal Infrastructure Team that you’re having a sprint.
2. Let people use the IDE they are used to.
This suggestion is mostly for the people who need mentoring during the sprint. We had several attendees, including myself, who were relatively new to sprinting (which was great). New contributors already have a lot to do at their first sprint, so having one less thing for them to get used to helps.
3. Teach Git, especially branching.
Git can make the process of contributing so much easier. There are many great Git tutorials out there, but Git Immersion by Neo is my go-to. Speaking of Git…
4. Pull!
Keep in mind that since D8 is in active development, attendees may need to pull Drupal on multi-day sprints.
4. Recruit your dream team.
I was fortunate to have a team of some of my favorite Drupalers help plan and execute the code sprint. Chris Wells, Kevin Baringer, and Leslie Glynn joined me on the organizing team for the sprint. They were instrumental in the sprint’s success. Thanks to the Drupal Association’s D8 Accelerate Grant program, Scott and Joël Pittet’s travel expenses were fully funded. Having two of the Drupal 8 theme system — co-maintainers attend the sprint helped us in two ways: first, it allowed us to have on-site experts. Second, it helped legitimize the sprint.
5. A sprint is also a marathon.
Before attending my first sprint, I thought that attendees would just dive right in, silently code for a few hours, then be done. There was some of that, but what I really liked about this sprint was that we actually started slow — really slow. In addition to mentoring first-time sprinters, Chris and Scott spent about an hour walking the entire group through the process of resolving an actual issue. Of course, they could have resolved the issue much more quickly on their own; however, by walking the entire group through the issue step by step, they provided a detailed demonstration of how to do things the right way, which saved time in the long run. 
6. Take time to teach.
In addition to mentoring, I recommend taking time to teach every sprint attendee a little bit about the bigger picture of the issue(s) they are sprinting on. Here is one example of what I mean: First, Joël and Scott discussed the concept of generating safe markup in Drupal 8 and how the issues we worked on related to that concept.
7. Feed people well.
Having decent meals, a variety of beverages, and multiple snacks is important. Keep in mind that sprinters are either volunteering their time or their company is donating its time.
8. At any given time, at least one person will not be sprinting.
At the end of the day, a sprint is an event, and every successful event needs an event planning team. Someone on that team needs to go on coffee runs, confirm the after-party reservation, and dozens of other event-related tasks. I recommend that you identify that team in advance (see #4 above) and clearly communicate their expectations before, during, and after the sprint. Also, be sure to spread these responsibilities out during the sprint so that one person doesn’t end up handling 100% of the logistics.
9. Pair program.
In an interview with Harvard Business Review, Gina Tripani, one of my favorite tech people, explains how working directly with someone can improve performance. She said, “I think there can be a huge amount of value in cross-pollinating people’s work styles. A few years back, I did a fair amount of pair programming, and while it was at times frustrating and awkward, I learned a lot from seeing how someone else does things and thinks.” I completely agree and suggest that sprinters find a partner with whom to work while sprinting. These partnerships can be fluid and informal, but I encourage you to give it a try. As Gina points out, pair programming is really just collaboration.
10. Roll with the punches.
An event planner once told me that there are no perfect events. It’s true; something will go wrong. For us, one thing that went wrong was that Drupal.org was down for a few hours on Sunday morning. We made the best of the situation, which was completely out of our control. Even when things that are in your control go wrong, don’t worry about it; just fix it as best you can and move on. In closing, I want to encourage you to reach out to people who have organized a sprint before and ask them for some advice. In fact, feel free to contact me directly, and I’ll be happy to help! Happy contributing!
