Mindstorm Team-Building: Better than climbing walls together
Interesting read in May 2009 issue Servo Magazine, which I got free at Maker Faire about new ways to teach groups.
The writer/editor, Bryan Bergeron, teaches a course on technology and the future of healthcare at Harvard Medical School. Each year, a session of the class simulates the creation of a business to give students a brief sense of the hours, adrenaline rush, complexity, and many dimensions of a tech start-up. This year, he did something new. He had his class break into two teams and gave each of them a Lego Mindstorm NXT kit and an hour (another link here). The assignment was to “design, build, and program a robot that could traverse 32″ and then stop just before the obstacle.” (This is a classic, and continually revisitable, robotics program - a combination of “hello world” and a sorting algorithm. There are a million ways to have a robot measure/detect/sense/calculate the distance it has traveled with various tradeoffs around accuracy, amount of code, use of resources, speed, etc.) The winner would be whichever person’s robot got closest to the goal. (In the case of a tie they would look at business plans. This course didn’t teach the immutable law of marketing that quality and performance just don’t matter, apparently.)
The two groups further subdivided themselves into teams: the business crew which figured out a model for selling the robot; the programming crew which learned how to program the thing; the “alogrithm” group addressed the problem of how to measure 32 inches; and a fourth group that attempted to spy and prevent spying(!). Both groups built their robots successfully and the difference in performance was one millimeter.
It’s important to point out, and this is the point of the column, that these people were not technical. They weren’t programmers. They learned the NXT language and interface on-the-fly and then applied that knowledge to the solution of their problem. They focused their time mostly on solving the problem (creating an algorithm for moving the distance, essentially designing the product), implementing it (figuring out the production and engineering), and debugging and trying additional ideas (optimizing). Valuable modes of learning both for individuals and teams, enough technology to open people’s eyes to some of the complexities of tech development (but not so much as to kill the exercise).
Most important, though, it was a real-life problem to solve. Lots of team building exercises tend to focus on hypothetical situations into which you can throw hypothetical answers. The intangibility of the assignment forces us to say the process is what matters, not the outcome. But, really the process can suck too — one person can do it all so it looks good when you present back to the group, the conversations can be blue sky with no grounding, etc. This exercise forces people to think analytically, solve a problem, communicate, and really, really work together.
Kind of an adult version of another President Nerd charge featured at Maker Faire:
