PBL Diary - T minus One week - Lego City and Beyond

Project based learning in the technology classroom diary: T minus one week

After spending 3 weeks teaching my grade 9's project management using Scrum, we finally moved on to Alexey Krivitsky's terrific and well-known Lego City simulation. Lego City Scrum Simulation  Although I've done this in the workplace, I didn't have any idea how it would go with a bunch of 13 year olds!

But project management is routinely located at the edge of a cliff - you get used to problems you'll figure out how to solve when you get to them, and the vast, unknowable future that you pretend to wrestle into a so-called "plan". This activity felt a lot like that! But we did it anyway.

 We didn't have any special Lego pieces, but still managed to create a pretty good looking city, complete with churches, mosques, low and high rise apartments, houses, cars, a courthouse, a hospital, an arena, shopping malls and traffic.

These took a vast amount of Lego, which I sourced at Northern Technology - a small injection molding plant off Markham Road. They are really decent people with great prices for Lego knockoffs. Northern Technology. 

 The point of the whole exercise was to let the students try the scrum process from end to end. I often find students don't automatically connect content with application. They can calculate burndown charts, and do requirements and task analysis, but when we started the simulation, they couldn't just reason out how to apply all the skills they had just learned. I had to take them through step-by-step. My hope is that when they start their large project assignments, they'll be able to transfer everything better having done the simulation.

Fortunately, after an initial run through, they appeared to get the hang of how everything fits together.

One observation I make about the finished cities. I have two classes. The class whose city is on the left is the class that typically is a lot harder to work with, and their class average is about 10% lower than the class whose city is on the right. And yet the left city has way more buildings done - they were both faster, and did a better job building stuff to meet requirements. This is educational theory in action - many, many kinesthetic learners in the left class. They are not so great with book work, and they have a hard time sitting still, but give them something active to do and a little competition and they shine.

 The video is a bit crappy. Eventually we'll have a lovely documentary of our project based learning experience (since making such a documentary is one of our projects) - this is just raw footage.  The discussion isn't quite as structured as I would like, but they get it done!

The only downside of the Lego experience is the sheer logistics nightmare. 15,000 pieces of Lego plus 32 kids equals unmitigated mayhem. Thirty-two is a slightly bigger than optimum group, too. Twenty would be better, but one has to work with the class one has.  I also had a problem getting them to stop - although I used to have that problem with my staff doing development work as well, so it's not like it's an unrealistic result. (I am reminded of a young software developer named Rain. I would send her home at 8 o'clock and watch her leave through the front door. I would go back to my office, and she would sneak in the back door! HAlf an hour later, I would spot her and send her home again. Repeat. Eventually, I would just go home!)  Finally, I had to be really clear that their marks would be for their status charts (sprint plan, burn down and notes from the retrospective, rather than for their building). They'll do anything for marks - even put down the cool Lego and meet for 5 minutes!

Anyway, we did planning, plus two sprints - each sprint of three 10-minute "days" - held "daily" standup meetings, made status charts and had a review and retrospective at the end of each sprint. I think the review was the funnest part (for me at least!). I think I (gleefully) only accepted two things from the first sprint - which led to both whining and much more focus on getting the requirements right for the second sprint.

The kids had the hardest time with the sprint retrospective. They often have a hard time generating ideas from scratch, and, since they are only 13/14, they haven't had the workplace  experience that helps you get a sense of what a good process should feel like. Maybe next time I'll try to find a way to model it better. Or maybe I'll just let them learn the way I did - the way all my colleagues did - by experience. A horrible, poorly planned project with crappy requirements and a useless product owner is a good teacher of how NOT to do something.

So if we think about teaching them using the "gradual release of responsibility" model: I taught them, they have now practiced with guidance, and I believe they are ready to work independently.

I met with a former colleague last week - he is still in the software development biz, still running teams - and he was so delighted that I was teaching the kids scrum. He said that he was always frustrated by how hard it can be to teach to adults! I think there are two important differences: 1. The kids are in school - so they are in learning mode. 2. The kids are so much less uptight and ego driven. I ask them to try something, they try it. They aren't yet locked into their ways.

So next week, I'll be doing overviews of all the projects, and getting the students to apply for the projects and roles they are most interested in. I want them to see what there is to choose from, and to think about their own learning goals. By the end of next week, they should all have their project assignments.