TITLE: Agile Courses AUTHOR: Eugene Wallingford DATE: November 13, 2004 9:03 AM DESC: We teach agile methodologies as content. But maybe we should use agile methodologies for the process by which we teach... ----- BODY: Continuing with our theme of trying new things in the classroom, I smiled when I read Kevin Rutherford's story about giving a lecture on agile software development as an agile presentation project. I had considered a similar idea while planning for my agile software development course: periodically stop the course and have the students help me set the direction for the next 'iteration'. Indeed, a couple of years ago, I outlined a paper that I wanted to write about applying XP practices to the teaching of a course: I could imagine a spike solution, and using the planning game to steer the course. What would it be like to teach 'test-first', with merciless refactoring? How would the other XP disciplines map onto how I teach, and how my students learn? As with many of my wilder ideas, I have not yet followed through. It's heartening to know that someone like Kevin has tried this idea out and found it workable on a smaller scale. Running a whole course in this way promises some interesting benefits and raises some potential problems. By allowing students to to help steer, it may help to keep them more engaged with the material they are learning. The most concrete benefit might be the periodic feedback the instructor receives. Even if only the professor drives the course, at least he would be able to do so with some knowledge of what the students think about what they have learned. One of the potential problems lies in the fact that students are exactly like the clients in an agile software project. First, students typically don't know all that much about the content of the courses they take. I've occasionally asked students questions at the beginning of a semester to elicit ideas for course direction, and I have found them relatively unaware. But why should they be? At the beginning of a course on algorithms, they have no reason to know all that much about what an algorithms course should or could be like, or even what kinds of algorithms there are. But this problem can be addressed in a reasonable way, and Kevin's article shows how: Start the course with a few pre-written story cards that form the basis of the first iteration. That way, the instructor can lay out some foundation material, present a broad view of the course material, and give the students some ideas about where the course can go. The key to doing the course in an agile way is to keep the number of pre-written cards to a minimum, so that you can get into client interaction as soon as possible. Selecting good starting stories would become an important teaching skill. The second problem is that students are not the only clients of the course. Many different people hold a stake in your courses, including: (The parents who pay for their children's education may want to be on the list, too!) I teach at a state-supported university and so feel a strong obligation to uphold the public trust for the state of Iowa. This problem, too, can be addressed in a manner similar to the first problem. The instructor can inject a few essential stories into the course, spread across the several iterations that make up the semester. These stories can ensure that the course covers material essential for courses downstream and for other stakeholder expectations. Again, it is essential to keep the number of such stories to a minimum. Academics are notorious for thinking that everything is required material, fundamental to the students' futures. (See the state of CS 1 courses around the US...) One side effect of this style of course planning might be to force the instructor to make some tough choices about what really is essential, and then get out of the way and let students help drive. We all might be surprised by the results. Even with the instructor seeding each iteration with a story or two, the students would play a role in ordering material and choosing the direction of the course. If nothing else, this would give the students a sense of ownership and let them take more responsibility for their own learning. Of course, a lower-risk experiment with this idea would be to do more what Kevin did, using it to run a single lecture period or a week-long unit. This sounds like a lot of fun, and maybe a better way to run a course. Spring semester isn't too far away... -----