Short projects: buy-in, energy, and the race to the finish

In the final week of our 3-week Summer Programme, we set our students the task of coming up with a group project, building it, and then presenting it to their faculty on graduation day. It’s a great learning experience, a little bit of pressure, but above all, it’s great fun.

Here’s how we do it.

Groups

We work in groups of three. Group work is a great way to share knowledge but it can also introduce an admin burden best described in the classic Software Engineering text, the Mythical Man Month. It’s tempting to think that larger groups will make your job as instructor easier, but it’s actually much harder: work grinds to a halt because of under-communication and personality clashes.

Three means that, on a small project with a tight, four-day turnaround, everyone has something to do.

Three is the magic number.

Self-determination

We have the groups define their own projects. This is so important as it gives each student the immediate sense of buy-in that you otherwise couldn’t grow organically in such a short time.

In our summer programme in July 2017 we drew up a list of topics we’d already covered, as a reminder of what we knew and what was in scope. The project ideas that we ended up with for our Monday morning brainstorm were, without fail, tractable, relevant, and scope appropriate.

Editing

Here’s where you come in, as an instructor – you know what can get done in four days (Monday – Thursday, with presentation and graduation on Friday), and you know, by now, what each team is capable of.

On Monday morning we went through each group as a class and discussed their proposals. Some groups had one, and one group had three different ideas for submission. All had the kernel of a great idea – “something we can work with”. It’s your job to guide the discussion towards a project you know will be successful. Here’s two writers tricks to help you:

Expand, then contract. Don’t edit the ideas as soon as the come to you – encourage the group to grow their idea first, then trim. “What if we used IFTTT here?”; “would that work with ten sensors? A hundred?”; “What if we had a million dollars instead of none?” It’s a really fun exercise.
“Yes, and”. This classic improv ploy helps to keep the discussion hot. It’s a great way to encourage the growth mindset and prevents you or your students from shutting down ideas. The rule is simple: never say “no”, never say “but” – always say “yes, and…”.

Grind

That doesn’t really leave you with much time left! We had a hard deadline of Thursday at 4pm – when all the project work needed to be done, the room cleaned, and our patter prepared.

Your challenge now is to balance your time between finding incisive and relevant teaching opportunities and getting out of the way. Here’s a few thoughts:

Time management is hard. There’ll be a rush at the end. Time pressure isn’t always a bad thing.
Project planning is necessary, but you don’t have enough time to be explicit about it. You can help by teaching and applying some lightweight critical path analysis.
Teamwork is probably a new thing. All our students are on slack on day #1, but in these small groups they’re all at the same desk. There’s no time for a leader, so it’s probably you.
Division of labour isn’t natural yet. At one point in our 2017 project week, every group in the room was blocked on one of their group members, with the other two looking on hopefully. Talk about splitting up the work, wait for a bit, then when you come back and see that nothing’s changed, assign tasks, Adam Smith.

I found that my Monday and Thursday were intensive, and my Tuesday and Wednesday were quieter – I was walking around every 50 or 60 minutes chivvying and questioning.

Find the success

Realistically, a four-day project build by an inexperienced group isn’t breaking barriers, but if you’ve been careful, your students will have built up a sense of ownership, creativity, and achievement – a can-do attitude.

It might well be the first time any of your students have solved a problem using technology. That’s pretty incredible. So help your groups build the narrative around their solution – whatever they’ve come up with.

Here’s our projects from 2017:

An MQTT system to take inputs from a number of distributed sensors and display them on an LCD screen
A security system that will alert you when someone is at your door, by flashing a light if you’re home or emailing you if you’re away. The system uses a PIR to detect if you’re home.
A device to allow a pregnant lady to press a button and alert the hospital when she goes into labour. A light on the device flashes when help is coming.
A traffic lights system that lets more cars through when the lane is busy, and stops traffic if a motion detector detects a train, or a pedestrian presses a button.
A button on a conference room table that alerts the speaker, by way of a message on an LCD screen, when a delegate has a question.

Global Code is growing! In 2018 we’ll teach 90 students in Ghana, and they all need a Raspberry Bi 3B. Get in touch if you can help us out.

Cheers Sam Moorhouse sam@globalcode.org.uk

Global Code Blog