TITLE: More on "Agile Teaching"
AUTHOR: Eugene Wallingford
DATE: August 18, 2006 4:49 PM
DESC:
-----
BODY:
If you've read many of my entries on agile software
development, you know that I run the risk of being
one of those guys who see agile principles everywhere
I look in the world. I've certainly explored the
relationship between agile approaches and my
running.
I've even seen agile truths a
Bill Murray film.
One way to do an analogy, and the people who use it, a
disservice is take it too far, to go beyond where it
adds value to where it misleads. But sometimes when we
see something everywhere it's because it is everywhere,
in some form. What's the pattern?
I was again struck by the similarities between agile
software development and teaching techniques while reading
an article recently. Another department head in my college
shared some of the papers she has been reading on how to
improve the way we teach large, general-education courses.
One of these papers is a product of the
National Center for Academic Transformation,
a project based on two ideas:
- using scientific evidence from cognitive psychology
and learning research to design instruction more
effectively, and then
- using information technology to implement instructional
designs more efficiently and cost-effectively.
One of the papers,
Improving Quality and Reducing Cost:
Designs for Effective Learning by Carol Twigg, motivated the
ideas behind the project and described some of the hallmarks
of courses redesigned according to them.
The project currently focuses on the largest of courses in
order to maximize its effect. According to Twigg, "just 25
courses generate about half of all student enrollments in
community colleges and about a third of all enrollments in
four-year institutions". This had never occurred to me but
isn't too surprising, given that nearly all colleges students
at every school take a common set of introductory courses in
English, mathematics, science, and business. What did
surprise me was the typical failure rates in these courses:
15% at research universities, 30-40% at comprehensive
universities, and 50-60% at community colleges. Some of these
failures are certainly the result of filtering out students
who shouldn't be in college, but I have to think that a
significant percentage of the failures are by people who
have been poorly served by a lecture-only section of 100s
of people.
What does agile software development have to do with all
this? In order to improve the quality of instruction
(including the failure rates in these large and common
courses) and reduce the cost of teaching them (in a
climate of declining funding and rising expenses), this
paper recommends that universities change the way they
design and teach university courses -- in ways that echo
how agile developers work, and using information technology
to automate whatever automation can improve.
One of the fundamental principles of this transformation
is continuous assessment and feedback.
Rather than testing students only with a midterm and a
final, an instructor should keep in continuous touch with
how students are comprehending the material. The traditional
way to do this is to administer frequent quizzes, but that
approach has as many minuses as plusses. Grading all those
quizzes is a pain no sane instructor relishes, and you end
up using a lot of class time taking quizzes.
Technology can help here, if we think about automating
continuous assessment and feedback. On-line quizzes can
give students an opportunity to test their understanding
frequently and receive feedback about what they know and
don't know, and they can provide the instructor with feedback
about both individuals and the group. Other technology
can be more continuous yet, allowing instructors to quiz
students "on the fly" and receive aggregated results
immediately, a la
Who Wants to be a Millionaire?
Folks at my university have begun to use interactive
feedback tools of this sort, but they haven't made their
way into my department yet. Our most common immediate
assessment-and-feedback tool is still the compiler.
But the agile programmers -- and agile-thinking instructors
-- among us know all about automating continuous assessment
and feedback, and use more tools: IDEs that provide
immediate compilation of code ... unit testing frameworks.
Red bar, green bar! These tools help students know right
where they are all the time, getting past some of the
ticky-tack syntax issue that unnecessarily interfere with
new students' progress. I think it's a huge win to let
the IDE point out "you forgot a semicolon..." and "your
code doesn't pass this test...".
There is a risk in allowing students to develop a "do it 'til
you get it right" mindset, but CS folks have already had to
deal with this with the easy availability of compilers. Two
years ago -- almost exactly! -- I wrote about this issue of
multiple iterations and care for programs.
Many professors still don't like that students can and do
go through many compile iterations. Since that time, I've
become even further convinced that students should do this,
but learn how to do it right. People master skills
by careful repetition, so we need to let them use repetition
-- carefully, thoughtfully. In some ays, this seems like
a statistical problem. To succeed by making random tries but
never learning, they need to have time for a lot of tries.
If they have that much time, then they have too little to do!
The rest of the paper outlines other agile-sounding techniques:
increased student interaction (pair programming), continuous
support (the coach, and access to the working system), and
sharing resources (collective ownership). But the key is
feedback, and the use of automation to do this as cleanly
and painlessly as possible.
Ultimately, I just like the mentality these folks have about
teaching. Twigg quotes a math prof involved with the project
as saying, "Students learn math by doing math, not by listening
to somebody talking about doing math." Of course! But you'd
never know it by looking at most university courses.
This sort of re-design requires a big change in how instructors
behave, too, and that change is harder to effect than the one
in students. Instructors are no longer primarily responsible
for introducing basic material. (Isn't that what reading is
for?) Instead, they need to be able to review what students have
done and expand on it in real-time, extending what students do
and leading them to new ideas and to integration of ideas.
That's intimidating to most of us and so requires a whole new
brain.
-----