Date

I have been thinking for years about features for content management applications, and for online learning software, which eventually got me thinking about features for teachers. Not the features the teachers need in their software (and not the size of the teacher’s nose), but the features the learners (remember them?) need in their teachers. So, since I’m going to be a Senior Research Technologist in Flexible Learning Systems come 2005-01-01, I thought I’d better do some research, starting with asking our local experts.

A more detailed post on “Teacher Features” will be forthcoming when I get my head around it and talk to a few more people, and read the stuff they recommend to me, but I’d like to report on an insight I got from talking to one expert online educator today on the phone.

I’ve asked a few people about “Teacher Features” but Shirley Reushle is so far the quickest with a usable quote, which I was too slow to write down verbatim (well I tried, but now I can’t read it).

Key points:

  • Onine teachers need a strong theoretical background in contemporary pedagogical theory.
  • And they have to understand constructivism, what it means to work with interaction, collaboration, activities, empathy.

We talked about the teachers, and then a little about software to support them, and the small role that content plays in successful online learning (but I still think it’s worth looking after the content well).

I have recently formed the opinion that teachers like Shirley could get people to learn under wet cement, but when I put it to her that a decent features set in the teacher would be more important than features in software, she was quick to reply that the software needed to be seamless, responsive and flexible. And if it wasn’t it would not be used. (But I’ve heard Shirley talk about how she has used the far from seamless patchwork of tools we used to provide at NextEd to deliver educational experiences with transcendent results).

Anyway, the point of this piece is that after a few minutes of talking to Shirley, the phrase “Agile Teaching” popped into my head, as she began talking about stuff like ‘content free’ courses where you abandon the planned content and take the group off in another direction, and the importance of continual evaluation rather than the current view of evaluation as a somewhat embarrassing growth on the outside of a course, amongst other things.

I was seeing parallels to Agile Programming Methodologies, the most famous of which is Extreme Programming, a useful set of tools for some kinds of software development with a name that still makes me cringe. The most striking similarity between Shirley’s approach to online education and the XP approach is the way an undertaking is driven like a vehicle, with frequent, small course corrections; rather than a delusional commitment to pointing the nose in that direction and pressing the accelerator, hoping to arrive in a few months time. There’s a lot about this in the Planning Extreme Programming book.

Later: Asked Google about “Agile Teaching”.

Number on hit is a page on “The Agile Teaching/Learning Methodology” by one Dr Andy Chun that says pretty much what flashed through my head when I talked to Shirley, (and Dr Chun even managed to remember to include the learners):

It turns out the software development process, in many ways, is similar to the teaching process. It involves multiple parties with different objectives (sometimes conflicting), a very tight schedule to get things done, a fixed deadline, limited resources and a lot of expected/unexpected changes along the way. The process requires detailed planning/scheduling, tracking and management with continuous assessment and feedback from all parties. Getting a software project done correctly and on time is not easy. Making a sure a course is taught properly and on schedule can also be a challenge sometimes.

I liked the discussion of extreme:

By extreme, I mean if something is good, we go to the extreme and do it constantly. If giving feedback to students on their learning is good, we should give feedback each class. Conversely, if getting feedback from students is good, we should allow students to give feedback whenever they want. If students learn better by teaching, they should be allowed to teach and share their knowledge constantly.

As a part-time computer programmer who has used and profited from agile programming, and worked to support teaching and learning systems I find this an interesting idea. I’m not saying that a young, somewhat cult-like, programming methodology could add much to education theory, just that it may be a good way to explain to our programmers what our teachers are doing and help us construct more flexible, responsive software; the sort we’d like to use to run our knowledge-building projects.

$LastChangedDate: 2005-01-07 05:03:57 -0600 (Fri, 07 Jan 2005) $


Comments

comments powered by Disqus