TITLE: Agile Course Design AUTHOR: Eugene Wallingford DATE: August 28, 2009 7:28 PM DESC: ----- BODY: A few days ago, I tweeted:
Everything looks worse in black and white.
Including course designs.
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, Brian Marick tweeted:
1/2: Agile often requires greybeards to admit how much snotty-nosed 20-year-olds have to teach them.
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! -----