I ended up trying out the marshmallow challenge yesterday in my linear algebra course. I had debated it because of the time it would take, but I figured in a 4 credit hour class, I could probably spare it. (I didn't run the demo in my calculus course which is 3 credit hours.)
Of the 7 teams, 5 had their structures fall over or apart during before we could measure the height, and the maximum height achieved was 20 inches. So many failures actually made for a really productive discussion, because each group had an ideas about where they had gone wrong.
I had a small class, so we had mostly teams of three. It was interesting to see each team's process, but there were definitely common themes:
Of the 7 teams, 5 had their structures fall over or apart during before we could measure the height, and the maximum height achieved was 20 inches. So many failures actually made for a really productive discussion, because each group had an ideas about where they had gone wrong.
I had a small class, so we had mostly teams of three. It was interesting to see each team's process, but there were definitely common themes:
- Most teams started building almost immediately.
- Most teams hadn't load tested their structure with just 2 minutes left or so.
- Most teams had at least one person who was significantly less engaged than the others.
- Most teams had significantly underestimated the weight of the marshmallow.
Most of these are the common mistakes, and the challenge's website does a good job of preparing the instructor to talk about how these impacted the team's performance in this challenge, and how these general ideas affect projects all over the place. For instance, assuming that marshmallows are light and fluffy really does impact your prediction of how difficult it will be to support one, and the students can draw a pretty clear (and slightly corny) metaphor from the experience.
Another interesting part was bring in "fail fast, fail cheap" in the discussion of why so few groups prototyped. I pointed out that this isn't just an entrepreneurial princple; we'll be writing some code in this course, and the fastest way to give yourself a headache is try to write a big chunk of code without testing the components. FFF a productive idea all around, and I think the students appreciated seeing it in a different context.
Overall, I thought this was a great first day exercise. The students seemed to really enjoy it. We had a good discussion about a wide range of (non-mathematical) ideas that will be important in the course, including teamwork, prototyping, validation of assumptions, creativity in unstructured problems, etc. And everyone got to eat some marshmallows. What's not to love?
Another interesting part was bring in "fail fast, fail cheap" in the discussion of why so few groups prototyped. I pointed out that this isn't just an entrepreneurial princple; we'll be writing some code in this course, and the fastest way to give yourself a headache is try to write a big chunk of code without testing the components. FFF a productive idea all around, and I think the students appreciated seeing it in a different context.
Overall, I thought this was a great first day exercise. The students seemed to really enjoy it. We had a good discussion about a wide range of (non-mathematical) ideas that will be important in the course, including teamwork, prototyping, validation of assumptions, creativity in unstructured problems, etc. And everyone got to eat some marshmallows. What's not to love?
RSS Feed
