One Man’s Walk in work

I’m teaching the Ruby on Rails course at University of Washington Extension this quarter. I’m pretty excited to teach a 10 week course for a university. The one thing that makes it completely different from corporate and conference gigs is that I’ll need to grade homework! It is pass / fail, but still. Weird.

There are a lot of problems with grading. There is a huge loss of knowledge between when a student submits the work and I pick it up. I’ve got to figure out a lot of things before I can even begin to check it – where is it? is it working? why isn’t it working? And if it doesn’t do exactly what I wanted it to, I have to decide if that’s okay, or if I should throw it back over the wall. If I have any questions, I need to e-mail / phone the student. Also, if I let students do different projects, then every time I switch from one project to the next, I also need a huge context switch.

I could go on, but I’m hoping you’ve started seeing what I saw.

It’s almost like the students are developers, I am the customer, and I’m describing a traditional development project. WAIT A SECOND! I have all kinds of tools to make these projects suck less.

What agile grading might look like

Here’s what I’m thinking right now :

1. We have 3 hour classes that I was going to let students work through most of anyway, so why not do all the grading there, face to face, on their computers.
2. Pair (and rotate) the students. They’ll learn more, and I’ll have half as many streams of work to manage.
3. Instead of grading “assignments” (or releases), I’ll break up my assignments into stories, each of which will have acceptance criteria.
4. In class, I’ll put a story board up, with the one strange characteristic that each pair has its own backlog. It might look like this :
   
   Work will flow from “assigned”, to “in progress”, to “to grade”, to “accepted”. Only I can move a story from “to grade” to accepted.
5. In addition to all of this, I’ll break the 3 hours into hour long “iterations”. At the beginning of each, I’ll present any more stories to add, do some lecture, and we’ll talk about where we are on the board.

So how does this solve our problems? If I am not completely happy about a story, instead of accepting it, I move it back to assigned. If I have questions, I ask them. There is little ramp up, because the student will be there trying to get me to mark off each story.

It’s still early, but this seems to make so much more sense.

Push vs. Pull

One interesting thing is that after I’ve solved all the other problems, I’m still left with a push system. In my experience, push systems are almost always suboptimal. They will yield some teams that are frustrated because they can’t keep up, and other teams that are wasting time because they’re done. When I need to interrupt people to give them the next few stories, it won’t be at the right time for anyone, and it will be breaking their flow.

There are pull models for learning, though. In Montessori schools, the guide’s (teacher’s) job is to go and give individual lessons to each student as they are ready for them. Then, at their own pace, the students practice each lesson on their own. Watching the students, the guide then decides when they’re ready for the next thing. Of course, the student often asks for the next lesson too!

Don’t think I’m quite brave enough to try this the first time out… Maybe next time.

Thoughts? Suggestions?

This entry was posted on Saturday, December 12th, 2009 at 7:45 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.