TITLE: Some Feedback on Agile Development Course
AUTHOR: Eugene Wallingford
DATE: June 11, 2010  7:31 PM
DESC: 
-----
BODY:
Today I finished reviewing materials from my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-06.html#e2010-06-04T16_38_14.htm">
   agile software development course</A>
so that I could assign final grades.  The last thing
that students wrote for me was a short evaluation of
the course and some of the things we did.  Their
comments are definitely valuable to me as I think
about offering the course again.

<B>What worked best this semester</B>?  I was surprised
that the class was nearly unanimous in saying <EM>pair
programming</EM>.  Their reasons were varied but
consistent.  By pairing, they faced less down time
because one of the two developers usually had an idea
for how to proceed.  Talking about the roadblock helped
them get around it. Several students commented that
programming was more fun when working with someone.
One student said that he "learned how to explain things
better".  I imagine that part of this was that, as the
team came to build up trust and respect for each other,
he wanted to be more patient and helpful when responding
to questions.  Another part was probably simply practice;
pair programming increases communication bandwidth.

The students who did not answer "pair programming" said
"learning Ruby".  I was hopeful that students would
enjoy Ruby and pick it up quickly.  But my hope was
not grounded in much empirical evidence, so I was a
little worried.  The language was no worse than a
break even proposition for some students, and it was
a big win for most.  And as a result <B><I>I</I></B>
had more fun!

I asked students, <B>Who were the best partners you
worked with</B>?  The best part of these answers is
that they were not dominated by a few names, as I
thought they might be.  There was a pretty good
spread of names listed, with only a couple of
students mentioned repeatedly.  I take this to mean
that many students contributed relatively well to
the experience of their teammates, which is the sort
of horizontal distribution of knowledge that is
desired for XP teams.  I did note an interesting
distinction made by one student between <I>the
partner I learned the most from</I> and <I>the
partner with whom I felt the most productive</I>.

<B>Which of the assigned readings was most valuable</B>?
I include a list of most of the readings I assigned
over the course of the four weeks.  Of those, two
were identified most frequently by students as being
valuable: Bill Wake's
<A HREF="http://www.xp123.com/xplor/xp0101/">
   The Test-First Stoplight</A>,
which was assigned early in the semester to give
students a sense of the rhythm of test-driven design
before diving in as a team, and
<A HREF="http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm">
   What is Software Design?</A>
by Jack Reeves, which was assigned late in the
semester after the team had worked collaboratively
for a couple of weeks on a system that had no upfront
design and very little documentation.  In class
discussion, a couple of students disagreed with a
few of Reeves's points, but even in those cases
the paper engaged and challenged the reader.  That's
about all I can ask from a paper.

When asked, <B>What did you learn best in the
courses</B>?, the answers fell into roughly two
groups: <I>TDD and the value of tests</I> and
<I>Ruby and OOP</I>.  The flip side is that many
students also said, "I wish I could have learned
more!"  Again, that's about all I can ask from any
course, that it leave students both happy to have
learned something and eager to learn more.

I don't mind that Ruby and object-oriented programming
were the prized learning outcomes of a course on agile
software development.  A couple of times during the
course I noted that a good project course is by its
nature about everything.  We can design courses in
neat little bundles, but the work of making anything
-- and perhaps especially software -- is a tangled
weave of knowledge and discipline and habit that comes
together in the act of creating something real.  If
Ruby and OOP were what some students most needed to
learn in May, I'm glad that's what they learned.  I
will trust that the agile ideas will take root when
they are most Needed.

<B>How could I improve the course</B>?  This is
always a tough question to ask students in an named
setting, because no matter how much they might trust
me I know that some will be reluctant to say what
they really think.  Still, I received some answers
that will help me design the next iteration of this
course.  Several times expressed a desire for <I>more
time</I> -- to write tests, to pair program, to work
on the system outside of class, to practice
refactoring, ....  It seems that desire for more
time is a constant in human experience.  (At least
they weren't so tired of the course that they all
said, "Good riddance!"!)  Clearly, there is a trade-off
between a four-week semester focused on one course
and a fifteen-week semester given over to four or
five courses.  The loss of absolute number of hours
available is a cost of the former.  I'll have to
think about whether that cost is outweighed by its
benefits.

One of the more mature and experienced team members
offered an interesting comment:  Having an instructor
who is a programmer act as client and explain the
project requirements to the developers affected a
lot of things.  He wondered what it would be like
to have a non-technical client with the CS instructor
acting solely as agile coach.  An insightful observation
and question!

All in all, this was valuable feedback.  The students
came through again, as they did throughout the course.
-----