ilén

This weekend, I coordinated volunteers for the August Ruby on Rails Outreach Workshop for Women from RailsBridge. Over 50 people attended as students, and we had almost half as many volunteers as attendees. Sarah Allen has a great post  on the workshop overall, and everything that went into it. I’d like to address what was, for me, the most intriguing aspect of the weekend — the way the teachers and volunteers self-organized to create a more effective workshop. The concept of self-organizing/self-directed teams is not a new one, it dates back to at least the 1940′s. But the wide acceptance of agile development methodologies have brought this approach to the forefront over the past few years. Although their benefits are touted frequently, in practice, they can be challenging to create and sustain; this weekend’s workshop offered some interesting insights on how to create an environment that encourages self-organization.

Theoretically, self-organizing teams evolve over time from hierarchical teams… but in this case 24 people, who knew each other only slightly, came together and taught 50 other people complex technical skills over the course of 10 hours. This happened with relatively little advance planning for the bulk of the participants. Despite, or perhaps because of (more on this later), the typical chaos of last-minute additions and cancellations, the weekend went more smoothly than many heavily-organized corporate trainings.

Here’s some of why I think it worked:

• Start informally. Installation had been previously identified as a roadblock to learning, so the first night of these workshops is an installfest where volunteers are available to troubleshoot as attendees go through the process of setting up a development environment. This had the added advantage of letting people get to know each other in a fluid, non-hierarchical manner so that they were better able to work together during the instruction portion of the workshop the following day.
• Establish clear goals and leave the details to the people doing the work. Excellent leadership counts for a lot; the Sarahs set (and repeated as often as necessary) a clear goal — everyone should leave the workshop having successfully deployed a web application. They provided the tools necessary to achieve that, but did not dictate how those tools should be used. Teachers were given a framework curriculum for instruction, but not a step by step training manual. The same materials were used by all the instructors but the details of how they were used varied per group and per experience level.
• Just-in-time roles. By nature, attendance of both volunteers and participants is unpredictable. This forces class assignments to happen at the last possible moment. While this was somewhat stressful at the time, ultimately it made for a better experience.  Total novices got a more structured, lecture-oriented morning session that suited the larger group size, people with minimal programming experience were broken into 8 person teams and the remaining participants were divided into 3-4 person groups; a structure that  worked very well for the different levels of experience. Because we were unable to create groups in advance,  the groups that were created were the right ones for the situation… and because they understood the fluid nature of group assignments, our volunteer instructors did a fantastic job of assigning themselves to groups as needed and coordinating the training amongst themselves, with 3 groups merging and separating as needed. This is not something that would have worked nearly as well had we tried to assign everything in advance.
• Resource abundance. Thanks to the overwhelming response from the SFRuby Meetup group, the student to volunteer ratio was 2:1 — in addition to providing attendees with a lot of personal attention, this meant that volunteers could shift roles fluidly from searching for extension cords (lesson learned for next time) to helping with the door to helping teach. I think this is the hardest lesson to translate to the corporate environment. It is critical that there be enough people for priorities to shift without impacting outcomes. I contrast this with the last so-called “tiger team” I worked on, where due to pressure to be “lean” there was only one developer until very late in the project–at the retrospective, we identified that the team was not efficient until the development team was expanded so that the developer could do more than code.  Many hands make light work… they also make better work.

There’s much more that went into the planning and execution of the workshop than I have detailed here, but what binds it all together is trust. Trust is a bountiful commodity in this all-volunteer environment, and perhaps that, most of all, is what allowed the rapid evolution of a large, self-organized team… but that’s a post for another day.