To pick up the narrative from my last post, we're currently one week into the First Robotics build season for 2012. Team 811 is busy working away on an initial sprint. The goal is to get a minimum viable product (a drivable robot) up by the end of sprint one, which will then be used as a base to move toward a competitive robot that can play this year's game, Rebound Rumble.

So how did Team 811 get from "huh?" to full-speed prototyping in 4 days? How does anyone get 40+ teenagers moving in the same direction when the number of unknowns is significant and the problems to solve look insurmountable? For team 811, the key was starting with a 3-day process called "Collaborative Problem Solving (CPS)." Think of it as a pre-sprint process to build team buy-in and reduce downstream back-biting and second guessing.

So what is CPS? It's a technique that starts with a problem statement and then encourages divergent thinking to brainstorm creative solutions to that problem. Criteria that allow evaluation of those potential solutions are then applied by the entire group. This starts a process of combining divergent ideas into stronger overlapping concepts and identifying those ideas that have the strongest combination of feasibility and ability. The result would be recognizable to many agile teams: a burndown "punch list" of items and strategies to drive early prototyping and the team's first sprint.

Before I describe how the team ran its CPS sessions last weekend (again, imagine getting 40 teenagers to give up an entire weekend to brainstorm a systems project — and do so willingly), let me give a bit of background. Team 811's use of CPS started in 2006 and was based on the success that another FIRST team, Team 365, had with the process. It's probably no coincidence that Team 365 (A.K.A. Team MOE — the Miracles of Engineering) is sponsored by DuPont. DuPont's pipeline of new, profitable products depends on blending innovation with commercialization, and quickly. This is one area where mentors help FIRST teams: by bringing state-of-the-art process and practices to teams — skills that will serve them well in life. Our use of CPS also highlights one of the cool things about FIRST as an organization: while competition between teams is serious, learning how to blend multiple engineering disciplines into a coordinated whole is the real goal, and a culture of sharing and education trumps information hoarding (empire builders take note).

Here's how the team used CPS over past weekend to get their efforts organized:

Day 1: Develop an understanding of the game (you might substitute "goal" in your own efforts). During the first day, our efforts focus on around developing a common understanding of the game, evaluating potential robot capabilities, and brainstorming game strategies. The team spent time reviewing the rules, description, and video. One of the highlights of Saturday's efforts was the "human player session," where the team members act as if they were robots with different capabilities. It's fun watching six team members acting as robots and trying to simulate realistic speed and shooting capabilities. Think of the human player event as the design equivalent of pencil and paper screen mock-up. These low-tech techniques can provide some startling insight into real constraints that are not as visible in an abstract requirements document. In Team 811's case, it gave us an idea of just how many shots would be attempted, on average, in a 2-minute time period.

After watching the game, with human players acting as stand-ins for robots, the team ended day one by brainstorming robot capabilities and strategies. A list of strategies was developed that would create a competitive (maybe even regional-winning) robot. This is the first step that moved the team beyond an MVP and onto what an end deliverable with better capabilities would look like, and everyone participated in setting the desired list of capabilities. Part of the goal of this divergent phase of CPS is to look for opportunities for concept strengthening — where two or more individual concepts can be mixed to create a resulting combination that is better than the divergent pieces. For example, a robot that can gather balls from the field and then shoot them into baskets is a more competitive robot than one that can just shoot baskets.

Day 2: Creativity. On day two, the team continues the process of divergent design by asking the question: "In what ways might we build a robot to play the game?" In this case, the goal is to come up with as many ideas as possible on the theory that the best way to have a good idea is to have a lot of ideas. We capture these ideas on "concept sheets." These sheets allow a team member to sketch an idea or even a fragment of an idea. Each concept is presented, categorized, and aligned to individual strategy components. When the team originally started the CPS process in 2006, this phase of CPS yielded around 115 concepts. In 2011, the team produced 146 individual concepts. This year, it set a new record at 184 concepts. This process of concept development allows all team members to be heard; there is no judgment of ideas at this point, and team leaders or popular members have no more input than other team members.

Day 3: Concept selection. On the third day, the team meets to begin paring down all the concepts. In essence, they are prioritizing potential features into a prioritized backlog list. The goal is to select final concepts that meet the team's competitive goals, are supported by the team at large, and that won't be second-guessed as build season progresses. The concept selection starts with team members voting on the concepts they like the best. Each team member gets five votes. With 184 concepts and around 200 votes total, a lot of concepts fall by the wayside at this point. (It's actually a bit easier, as some concepts are duplicates of each other). Each concept is then plotted on a chart with the number of overall votes, and the top 10-12 vote-getters move on to the next step.

This is where more experienced team members step in (those that have been through at least one build season before). The veterans rate these top concepts based on the concept's Ability to play the game and the Feasibility that the team can successfully implement it. A scatter plot shows how the concepts map, with the team looking for the concepts that have the highest combination of feasibility and ability. The top 5 concepts become the consensus items for prototyping as the team goes into week 1 of build season.

What You Can Learn From A 10th Grader When It Comes To Collaborative Problem Solving

As you can see, there's nothing about this process that is magic or even that difficult to implement. It gives everyone a voice and still draws on the wisdom and experience of experienced team members. It also focuses on a number of important elements of starting up a successful Agile team:

• It sets the stage for high-performance teaming. As I've written before, trust is an integral component of a high-performance team. Trust can be a real issue when a third of your team is new and you don't know what level on contribution you might get from new members or even new team leaders. The CPS process established an early basis for trust, because all team member feel like they have a say in the process — they get invested in success early.
• It gets teams off and running quickly. When you have six weeks to ship a product (or working software), there's no time for analysis paralysis. Opening the aperture and then quickly closing it to focus on putting first things first sets a project up for a good first sprint. It gets the feedback cycle going quickly so on-the-fly adjustments can be made as the team learns more about the risks they are dealing with.
• A bit of design provides a great deal of clarity. The human player stage may sound a little silly, but it provides a lot of insight into the real mechanics of the game the robot will play. Likewise, paper prototypes or ethnography may seem silly from a technician's point of view, but they work for the same reason the human player exercise does. Don't ignore the value of a little bit of upfront design before you go into your first sprint.

And now onto prototyping...where the real fun (and angst) begins.