Note: This guide has been moved to http://drupal.org/node/247987. Please put any further edits there.
Focused "design sprints" - where developers get together for several days of intensive planning and produce a set of proposals for future work - are a new feature of Drupal development, having been piloted in Chicago, USA in February 2008.
The Chicago sprint, http://groups.drupal.org/data-architecture-design-sprint, was felt to be a valuable experience and other design sprints are in the works. This brief guide is intended to provide some pointers for organizers of sprints. Please add in details or ideas.
This writeup draws on experience in the data architecture sprint, including an evaluation participants did at the end of the sprint--see "Lessons learned for future 'Design sprints'" at the bottom of this page: http://groups.drupal.org/node/8714.
Basics
- Assemble a list of the key people to be involved. These might include, obviously, developers most active on the topic, but having participants with a range of perspectives and involvement also helps. It may be useful to have a process oriented faciliator who is a little removed from the issue. Numbers? Six or so participants seemed to work well at the Data Architecture sprint.
- Decide on a location. Features to look for:
* Relatively accessible to most or all participants.
* At least one participant is located there.
* Availability of suitable meeting space, e.g., donated by a participant's employer or client or other group. The facility should have: wifi, whiteboard, sufficient space, privacy (separate room).
* If participants are staying at hotels, arranging to stay at the same one is a good idea.
3. Designate a coordinator to pull together basic logistics.
4. Solicit and secure sponsorships:
* travel and accommodation costs for participants, e.g., from the employers of individual participants
* events at the sprint, e.g., a sponsored supper out.
Before the sprint
While the intensive work will wait for the face to face discussions at the sprint itself, preparation ahead of time will make the in person time much more focused and productive.
Communications
Creating a dedicated group on groups.drupal.org is a useful way to organize the sprint and also share ideas and results with the community. Discussion ahead of time can help define the need, existing solutions and initiatives, and some specific aims.
Need
Why is this design sprint needed? What specific problems are you addressing?
Example from Data Architecture design sprint:
Today, Drupal is a powerful and flexible web application that can be modified and extended to meet many sites' requirements. For the future, Drupal needs to be a powerful and flexible web application-and-services development platform. A development platform requires a consistent, documented set of APIs for accessing all of the platform's functionality.
Existing solutions and initiatives
What existing initiatives are addressing the need you have identified? What are some of their merits and shortcomings?
Specific aims and intended outputs
What do you aim to produce? If the scope seems to large, try to refine it. Select a specific problem that may be representative of a larger problem set. For example, at the Data Architecture design sprint, the problem of bringing CCK fields into core was chosen as a focus to ground the larger discussion of unified Data APIs.
Draft an agenda
See draft below.
At the sprint: sample agenda
Day 1: Groundwork
- Introductions
- Designate roles: recorder (one per day?) to take detailed notes throughout the day; facilitator, to facilitate as needed
- Lightning talks: Each participant presents a 10 minute prepared talk on a topic relevant to the sprint aims.
- Revise agenda
- Confirm aims
- Summary of current status of work
-
Identify main areas needing work, with a focus on components of an overall solution
-
In evening (after session): recorder revises minutes from day, posts to groups.drupal.org group.
Day 2: In depth
- Taking components identified in Day 1, discuss each in detail, focusing on defining solutions.
-
Possibly, break into small groups (two or three per group) and delve into specific issues, reporting back to group.
-
In evening (after session): recorder revises minutes from day, posts to groups.drupal.org group.
Day 3: Plans and tasks
- Define specific tasks
- File issues outlining relevant tasks.
- Potentially, break into small teams (pairs) and draft sample code. E.g., if you have determined the need for a new hook, draft sample hook implementations.
Break the work into concrete tasks with timelines and proposed implementation teams, including leaders and initial proposed membership. - Review broad solution components as identified on day 1. To what extent do the concrete tasks fulfill this vision?
- Review process of design sprint. What worked, what didn't, lessons?
- Assign short term work in documenting design sprint. Who will write up results? How will they be shared? E.g., at an upcoming Drupal conference.
Fun
- Go out for dinner or other social time
- Make sure the work days aren't too long. 8 hours is probably a good max.
After the sprint
- Write up and share results.
- Start in to workplan.
- Look for ways to stay engaged with each other, e.g., through meeting at conferences or arranging code sprints involving two or more participants.