[game_edu] ED SIG Roundtable Feedback / Debrief

[Gregory Walek]

A few comments on Jose's Approaches....

On Team Grades:
I've tried this and quickly found myself in situation where a student did their portion of the work but the project failed due to no fault of their own. When this happens you're faced with the this situation, you're penalizing one student because of others failed. The first thing that I started doing is not giving a collective team grade. So that 25% should be expressed as the student's ability to work in a team.


On Project Length & Scope
Two weeks on a final collaborative project is a very short time. If you going forward with this, establishing scope is essential to the project's success. Be up and honest about scope with your students. And then be aggressive. Remind them they're going to design an oak tree and you're cut them back to the branch they'll be able to complete. (I personally tell them I have the elite level mythical chainsaw called "the Rescoper". )

While we're talking about scope, I feel the need to express the need to explain to your students all projects have things cut from it. Explain that cuts can happen at any time. You must stress that they cannot take it personally as what is happening is natural and to be expected. (Also this is where DLC and Sequels come from!).


On the Instructor's Role
Lecturers should not be leads (as in team lead or programming lead). They need to act at a higher level like Executive Producer. Pulling back from leads means the the burden on the Team to to organize itself and do its work. (Hence their roles will emerge from this process) This doesn't mean you don't have a hand in it, it means you're the boss of bosses. But it also means that if the students fail, you are not responsible for their failure.  If you're curious how this works look up information on Valve's Cabal system (an older reference) & Agile\SCRUM Teams.


On the Burden of Failure
I've designed assignment for student to go innovate and take risks. Instead were timid with uninspired bland designs. One of the issues in play with students is they have been afraid to take risks for fear of failing and hurting their grades. Let's be honest here this burden of failure is holding our students back. Yes, let them make mistakes and errors! They will learn from them and get better now. Point out the issue to them and help them understand  why and best practices now. Let them grow from this now instead of seeing them pay for consequences of doing it on-the-job!

In situations where appropriate, I've assigned projects are defined in the following way.
1) Concept ... what they are working towards. An essential part that must be establish before starting work or no grade is given for the project
2) Execution - or the actual work they did
3) Postmortem - a review of the concept, the work they did, what went right, what went wrong, what they would do different (aka what they learned).

I right now grade on all three parts as a whole. This allows students to take risks that might fail, a attempt it anyways. If the project success, the postmortem is a formality. But when the team falls short of their goals, the Postmortem is the saftey net for them to get caught. If they are capable of explaining what went wrong and how they would proceed differently in the future then the project is not for naught. And when this happens, failure isn't a burden or disastrous, but it's beneficial to their education.

Things of note in this process.
* You need a check on the execution... that is make sure they actually did work.
* Be firm with having a concept. With out a objective stated, there's no way measure how close they got to their goals.
* Be mindful of how you use this approach as it is not for every situation. We at NHTI use this with some projects with upper level students in specific situations with great success.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist7.pair.net/pipermail/game_edu/attachments/20160429/3b31e007/attachment.html>