The Agile Approach to Learning Design

Short panel presentation to Online Educa Berlin in which I reflect on the ways the agile process can go wrong when applied to learning design. Not that it always goes wrong, but this is the topic I drew in the panel.
[Added to Youtube by Stephen Downes, Dec 27, 2015]

(Stephen Downes) So, hello everyone.

I'd like to state and for the record,

I love the blue dots.

(LAUGHTER)

I've been sitting there
watching the blue dots.

So, I've been cast in the role of
the person who finds the problems

with the topic that we're all praising.

I do like agile design, I like it a lot.

And I like the concept of
agile learning design,

I like it a lot.

But, you know, I've been in the field
of programming for many years.

I've been in the field of learning design
for many years.

I've worked on small projects,
I've worked on big projects,

I've been the peon
at the bottom of the pile

and currently I'm the program leader
responsible for producing outcomes.

So I've seen it from different angles.

And there's so many ways it can go wrong,

especially when we move from the
fairly static domain of software design

to the far less static domain
of learning design.

That's learning design.

It's the least agile thing
you'll ever see.

That's actually a graphic from IMS

which produced the learning design
specification.

That's supposed to be
pretty open and flexible,

It's like a play with a director and roles
and all of that.

But, you know, once you're into the thing,

there isn't a whole lot of flexibility
happening

and it leads to questioning just
what is it that we're up to

when we are talking about
agile learning design?

Are we talking about
agile 'learning design'

or are we talking about
the design of agile learning?

Two different things,

and it seems to me that
it doesn't make sense

to give the instructional designers
all that freedom and flexibility

if we're going to march students
lockstep through

a predefined kind of process.

Here's what agile learning design
ought to look like.

There's a flow.

This is agile design generally, right?

And it's an iterative thing,

and yet people don't talk
about that so much

but it's an iterative thing.

Each iteration is like designing a full
and complete product,

and then you might spin off
some side things, some prototype things

as you need to, but, you know,
version 1, version 2,

you're doing the same thing over again.

No course in the world,
well, maybe not no course,

but few courses in the world
are designed that way.

Courses progress from Lesson 1,
Lesson 2, Lesson 3, Lesson 4.

They don't cover all of geometry
and then all of geometry in more detail

and all of geometry in more detail.

It's a different way of thinking
about the process.

So, one of the major concepts
in agile learning design,

in agile design generally, it's the Scrum.

The Scrum is basically a self-organizing
development team.

It is originally drawn from the idea that

programmers are the smartest people
in the world and do not need management.

No, I'm just kidding, but there is
the idea here that

the programmers know how to program, and
they know how to produce the outcomes,

if they're left to do the job for
themselves, to organize for themselves.

And indeed, in the Scrum meeting,
as you are mapping out the task,

each of the tasks, in the Scrum itself,
selected by the programmer.

So, they're volunteering to jump in,
to do these things.

They're taking commitments on themselves,
they're specifying how much time,

how much effort will be required
to produce the commitment.

So, OK: that's good
but this doesn't happen by magic.

It takes time, and