Back in 2012 I wrote and presented a bit about ‘agile pedagogy’ – the notion of applying some of the ideas of agile development to the craft of teaching. There’s been some renewed interest of late in this, as well as teaching students about agile development, so I’m taking this opportunity to revisit the them.

I’m not a software engineer, so I come to agile development from the outside.

I think there’s a couple of things going on. One is taking some of the ideas from agile development and applying them to our work as teachers, which is what I was trying to get at in the talk above. The other is teaching students agile development approaches. You can do both at the same time, but it’s probably worth thinking about them separately.

I think the former comes quite naturally to teachers.

We think of the ‘stories’ of our students – Sam loves tinkering with things but struggles with theory; Alex is happy following instructions but finds it hard to get started when faced with a blank screen; Chris will get this immediately but won’t see the point of finishing off the documentation.

We have in mind a minimum viable product – making sure the class know the things they need to / complete the tasks they have to, but I hope we’re not entirely satisfied with just getting them through the exams. Love of learning, reading round the subject, that sort of thing.

We think in terms of time boxed development – here’s my backlog of things we need to teach in this unit, and misconceptions we have to correct.

The job comes into its own when we see our learners as partners in the educational process as Hattie observes:

The biggest effects on student learning occur when … students become their own teachers.

For me, this is a crucial element of any ‘agile pedagogy’. A consequence of this has to be far more responsiveness to what happens in the room: taking their questions, interests and misconceptions as a starting point for what comes next.

I think there’s also a place for test driven development in our work. Check (test?) first whether pupils know something – there’s little point teaching it if they do. Teach the thing. Check (test?) then whether they’ve learnt the thing. There’s evidence, should anyone ask for some) of progress and the impact of your teaching. Don’t stop at that point though – ‘refactor’ the learning, making it better integrated with pupils’ schemata and more readily applicable to solving problems.

See also other folk writing about agile schools, agile classrooms, agile teaching / learning methodology, and agile parenting (seriously).

Teaching agile methods in computing lessons is another matter, but I think we’ve far more chance of being able to do this in primary school and in KS3 than we have under current exam specifications at GCSE / A Level, although even here I see agile and iterative development are now getting a look-in. I reckon that this could be taught through collaborative group project work fairly effectively: starting with groups thinking about what they’re going to make; reviewing lesson by lesson what they’ve done, problems they’ve encountered and things they still need to do; sharing tasks out between the group; working with a partner using pair programming if possible; testing units as they go; getting to a minimum viable product and then developing this further. I think projects like Apps for Good provide some scope for this sort of approach, and I tried to include elements of this in some of the Switched On Computing units.