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
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-11.html#e2004-11-12T10_26_28.htm">
   trying new things</A>
in the classroom, I smiled when I read Kevin Rutherford's
story about giving a lecture on agile software development
<A HREF="http://cgi.bramwell.plus.com/krblog/2004/11/an_agile_event.html">
   as an agile presentation project</A>.
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
<A HREF="http://cgi.bramwell.plus.com/krblog/2004/11/an_agile_event.html">
   Kevin's article</A>
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:
<UL>
<LI> other courses in the curriculum, especially those which
     your course is a prerequisite
<LI> other professors, who will work with your students
<LI> the profession that will employ them
<LI> society at large, to which your students will contribute
</UL>
(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 <I>everything</I> 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 <I>really</I> 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...
-----