It's amazing how much one can learn from a simple game using a marshmallow and some spaghetti. I first came across the so-called Marshmallow challenge when I discovered Tom Wujec's Ted talk. I later also found his site where he generously shares detailed step-by-step instructions as well as presentations one can use as facilitation aids.
In short, small groups compete to see who can build the tallest FREESTANDING structure in 18 minutes, using only the items provided (20 sticks of spaghetti, one marshmallow, a meter of string and a meter of tape) with the entire marshmallow on top.
I've used this game several times as part of my complexity presentations, with diverse groups ranging Exco teams to Honors students; and small to large (I've done it with 300+ leaders in a large financial services company). The exercise allows for interesting group dynamics to play out, these can be explored afterward and often opens the door to deeper conversations, especially in teams. For example, in an OD team, I decided to deviate from the standard approach and include a couple of disruptive elements in the process. After the first 5 minutes or so, I told them that they were no longer allowed to talk to each other. Almost immediately the groups started whispering, and when challenged rationalised their rule-breaking by arguing that whispering and talking weren't the same. This opened the door to a great reflective conversation on afterwards!
Exploring team dynamics is not the main application I utilise this exercise for though. I use it primarily to illustrate the danger of assumptions and the difference between a fail-safe design vs a safe-to-fail experimental approach.
- Assumptions are dangerous
In virtually ALL the groups I've done this with, regardless of seniority or role, they almost never start with the marshmallow. They invariably start with a fail-safe design of intricate spaghetti pyramids - usually with the shared assumption that they "need a strong base". They normally spend about 16 of their 18 minutes building and perfecting this designed structure. The marshmallow lies to one side, all but forgotten (One would think that the fact that it's called the Marshmallow challenge not the Spaghetti challenge would be a clue ... ). When the 2 minute countdown starts, the groups finally get to the marshmallow, and in almost every instance, they realise that they made a fatal assumption ... that the marshmallow is light and fluffy and should therefore present no problem when they put it on top of their perfectly designed structure. Wujec describes the impact of this assumption perfectly: "the ta-da moment quickly turns into an uh-oh" when their structure promptly collapses under the weight of the marshmallow.Ironically, in most cases if a group simply stuck 3 pieces of spaghetti into the marshmallow and got it to stand, they would've won the challenge.
2. Safe-to-fail experimentation and fast iteration trumps fail-safe design
In Wujec's presentation, he presents some data about who's typically really bad at this (recent MBA graduates), and who excels (recent kindergarten graduates). The key reason he provides has proven to be correct every time I've use this exercise: the MBA graduates start with the spaghetti and try to design the perfect structure without testing early. The children start with the marshmallow, and iterate. They build taller and taller structures through trial and error: they're not afraid to experiment and fail. Also, as Wujec rightly says, none of the children wants to be CEO of Marshmallow Inc, so they spend a lot less time orienting and jockeying for position.
3. What is your marshmallow?
In addition to the fail-safe design vs experimentation conversation, another really interesting topic to explore is what the marshmallow represents in their context. For example, most of my clients are adopting a strategy of customer or client centricity. It's really interesting to have the group reflect on how often they've spent months (and millions) developing intricate products or systems based on assumptions about their clients, while never actually testing the idea with a real client. Like the marshmallow, the client is all but forgotten until right at the end of the project when it's too late to make a difference.
I've been pleasantly surprised by the value of this simple exercise. This exercise really brings the message across that it's important to question assumptions and that there is value in experimentation, developing minimal viable products, failing fast and iterating. I'm sure there are many other applications and lessons one can extract from it. If you've used it, I'd love to hear about your experiences!