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]

- So, hello everyone.

I'd like to state and for the record,

I love the blue dots.

(audience laughs)

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 gonna 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 one, version two,

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 one,
lesson two, lesson three, lesson four.

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, is 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,
is self-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, okay, that's good

but this doesn't happen by magic.

It takes time, and agile
is typically employed

in larger software development projects.

But when we're doing learning design,
we're doing something a lot smaller

and a lot more precise.

The question came up earlier, you know,

"What about, you know, high-volume
instructional design?"

Well, high-volume instructional design:
you don't have time for 3,4,5,6,7 weeks

of your development team
organizing itself.

Another problem:

as your projects get bigger, and we've
worked on some very large projects,

your teams get very large.

If you think about
all the different people who can,

and eventually will get involved
in the design of your learning,

or in the delivery of your agile learning,

you've got designers, you've got
subject matter experts,

you've got programmers, you've got
human interaction specialists, etc.

Eventually you get a very large,
very complex team.

As you get larger teams, you do not
generate more efficiency, it's well known,

you generate less efficiency.

So, what's the solution?
Split the teams.

Okay, now you have competing
development teams

working on the same project.

This sounds, like, you know, OK,
we've split the task, it's great.

But when you split the task,

you now have two different groups
of people with different objectives,

different responsibilities.

They're competing often for resources,
they're competing often for priority.

We have a project where we had
two agile teams.

We ended up with two versions
of the thing that we were developing.

Basically, they had, they didn't split
into functional groups,

they, what's the word for it?

Ah, when cells divide, mitosis.

So basically, we got two small versions
of the project we were trying to create.

Another pitfall:

if you try to organize your groups into,
you know, okay,

this group will do this part of it,
this group will do that part of it,

you get specialized Scrums.

So now, nobody's working on
the final project, on the final product.

And there is the danger, and I've
seen this and we've had this,

and in fact, I'm living this
at this very moment

where everybody, all the teams
want to do the analysis bit,

or the rapid prototyping bit.

But we're trying to bring a product
to actual users, at the end.

We want it to be a deliverable product.

Nobody wants to do the last stage
of error testing, of hardening the code.

That's the least popular scrum.

So they go back to, they all want
to do prototyping again.

Finally, well, not quite finally
but we're getting there,

who is the product owner?

In the Scrum process,
you're delivering outcomes

and the idea is that,
as you go through each sprint,

which is short-term cycle
through your development process,

you're producing outcomes,
you're producing deliverables

and these deliverables
are delivered to the product owner

who will set the deliverable,
and even more importantly,

define the conditions for the completion
of that deliverable.

Did you do it or not?
How do you know?

Well, you have to have certain criteria.
It passed this test.

It produced this function.

It has to be really solid
and concrete.

Well, that good in education, or sorry,
that's good in software development,

your product owner is your client,

perhaps your architect,
somebody like that.

They know what they want.

Education is completely different.

In education, there is
no product owner per se.

Think about it, think about the different
populations that are involved in learning.

There is the end user,
also known as the student,

who, in the typical instructional design
process, does not show up until

after the instructional design
has been done.

It makes it very hard to be agile.

There is the subject matter expert,
also known as the professor.

The professor has his or her own ideas
of what the deliverable must be.

Then there is the administrator,
the dean or the president,

or the department of extended learning,
or whatever,

who have other objectives,
often revenue objectives,

or course completion objectives.
They have their own definition.

All of these definitions are different.

I guarantee you they're conflicting
and they're competing.

You can't just pick one,
because if you pick one,

you're not being agile for the others.

What's worse?

To have not just competing interests,
to have different levels of expertise.

We're designing a system right now,

where we're trying to create
agile learning itself.

This is, I'm not going to talk
about that,

but that's not the purpose
of this particular talk,

but the ideas here is that
as the learning is unfolding,

the process, the outcomes,
the deliverables and all of that

can change
as the needs of the learner change.

Very ambitious, really hard.

We have to think about learning
differently, in order to do that.

Well, we've got our development teams.

Our development teams were raised
in the traditional educational system.

Their idea of education
and online learning is

create some videos, put them online.

Well, if we're iterating over a project,
the first version of the project,

also known as
the minimally viable product,

it's going to be pretty simple and it's
going to be something that you could do

with fairly traditional methods.

And your programmers and developers,
all other things being equal,

will fall back on the traditional methods

because they're not being challenged
with the minimal viable product.

The end goal where you want to get to
is something really flexible and dynamic,

but by the time you get
to stage five or so,

they've built many, many
static structures,

because that's what it took to
the minimally viable product

at each release, at each iteration.

So you have to start over.

And you start over and everybody agrees,

okay, the project is about something
a lot more flexible than that

and you start developing again
and the same sort of problem happens

because your developers and your designer

did not acquire that expertise
in the meantime.

So they go back on what they already know.

So there's a difficulty here.

In instructional design, we're attempting
to create an outcome

that is not part of the skill set of the
people producing the product

that results in the instructional design.

Finally, learning objectives.

This is the meta thing, right?

And I get this one all the time: we do
connectivist-style MOOCs,

the connectivist-style MOOC.
We say there is no curriculum.

It's not about acquiring a certain
predefined body of content,

because we want to meet
participants' needs

as they go through the course, and
these needs are different for every person

and these needs change over time.

And it should be up to the participant,
who ought to be the product owner,

to define what success is and
define what the outcome should be.

It's a moving target.

Nobody who funds education
wants to deal with that. Nobody.

Every last one of them wants to see
course completions, certificates,

competencies, curricular outcomes.

They want them defined ahead of time.
They want them approved

by the curriculum board or
the school board or whoever is in charge.

All of this must be set ahead of time.

And then you're supposed to go
and be agile.

It is two very contradictory perspectives
at work here.

It's not possible to do agile learning,
much less agile learning design

in an environment where the structures
and the outcomes are all predefined.

That's meek, that's my short talk
and I thank you very much.

(applause)