TITLE: Agile Course Design
AUTHOR: Eugene Wallingford
DATE: August 28, 2009  7:28 PM
DESC: 
-----
BODY:
A few days ago, I
<A HREF="http://twitter.com/wallingf/status/3541871303">
   tweeted</A>:

<BLOCKQUOTE><EM>
Everything looks worse in black and white.  <BR/>
Including course designs.
</EM></BLOCKQUOTE>

It is easy to have fantasies about a new course in the
bloom of summer.  There are no constraints.  I am perfect.
My students are perfect.  Campus life is perfect.  The
course is... perfect.

It's important to stop dreaming.  But I have never been
good at mapping out a new course in its entirety.
Beforehand, I'm still learning what I want to say and
how to say it.  I still need to learn if how I want to
say what I think I need to say will work.  The best way
for me to go is to start teaching.

Before the course starts, I run my own version of the
Planning Game.  This helps me to develop a high-level
picture of the topics I think are essential to cover and
the activities I think are essential for students to do.
The result is something akin to a System Metaphor and a
set of user stories.  I prioritize the topics and select
the topics that should come at the beginning of the course.
This is akin to Release Planning and prepares me for my
first release, which is a one-or two-session unit.

Then I implement.  Teaching the first week grounds all
that thinking I've been doing in reality.  The act of
meeting the first session, seeing the students, and
interacting with them helps me to commit to certain
courses of action and gives me a basis for making other
decisions as we go along.  Initial feedback to a simple
survey helps me to prioritize topics.

With a new prep, especially a course outside my usual
teaching range, agile course development is even more
important for me.  Feedback and adaptation are about
the only way I can feel confident that the course has
a chance to succeed.

While at Agile 2009, I think,
<A HREF="http://twitter.com/marick/status/3557963049">
   Brian Marick tweeted</A>:

<BLOCKQUOTE><EM>
1/2: Agile often requires greybeards to admit how much
snotty-nosed 20-year-olds have to teach them.
</EM></BLOCKQUOTE>

This is true of the agile community, and so it is true
for me to the extent that I engage in agile.  It is also
true of teaching at a university, so it is true for me
on another dimension, too.  Finding the boundary between
where the professor needs to lead where the students
need to lead is the key.

One bit of good news from my first week in class.  I
have reason to believe that this group of students is
willing to participate in the daily business of class
and, I suspect, in leading when they can and should.
That almost always leads to a better course for them,
and a better course -- and experience -- for me.

Thinking about teaching software engineering is going
to be interesting.  I love to make software, and I
love to think about it.  Now that is more a part of
my day job.  There is an extra trade-off to make:
spending time explicitly preparing for class versus
spending time blogging about what I'm thinking along
the way!
-----