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: 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. -----