WEBVTT

99:59:59.999 --> 99:59:59.999
(Stephen Downes) So, hello everyone.

99:59:59.999 --> 99:59:59.999
I'd like to state and for the record,


99:59:59.999 --> 99:59:59.999
I love the blue dots.

99:59:59.999 --> 99:59:59.999
(LAUGHTER)

99:59:59.999 --> 99:59:59.999
I've been sitting there
watching the blue dots.

99:59:59.999 --> 99:59:59.999
So, I've been cast in the role of 
the person who finds the problems

99:59:59.999 --> 99:59:59.999
with the topic that we're all praising.

99:59:59.999 --> 99:59:59.999
I do like agile design, I like it a lot.

99:59:59.999 --> 99:59:59.999
And I like the concept of 
agile <i>learning</i> design,

99:59:59.999 --> 99:59:59.999
I like it a lot.

99:59:59.999 --> 99:59:59.999
But, you know, I've been in the field 
of programming for many years.

99:59:59.999 --> 99:59:59.999
I've been in the field of learning design 
for many years.

99:59:59.999 --> 99:59:59.999
I've worked on small projects,
I've worked on big projects,

99:59:59.999 --> 99:59:59.999
I've been the peon 
at the bottom of the pile

99:59:59.999 --> 99:59:59.999
and currently I'm the program leader
responsible for producing outcomes.

99:59:59.999 --> 99:59:59.999
So I've seen it from different angles.

99:59:59.999 --> 99:59:59.999
And there's so many ways it can go wrong,

99:59:59.999 --> 99:59:59.999
especially when we move from the 
fairly static domain of software design

99:59:59.999 --> 99:59:59.999
to the far less static domain
of learning design.

99:59:59.999 --> 99:59:59.999
That's learning design.


99:59:59.999 --> 99:59:59.999
It's the least agile thing 
you'll ever see.

99:59:59.999 --> 99:59:59.999
That's actually a graphic from IMS

99:59:59.999 --> 99:59:59.999
which produced the learning design 
specification.

99:59:59.999 --> 99:59:59.999
That's supposed to be 
pretty open and flexible,

99:59:59.999 --> 99:59:59.999
It's like a play with a director and roles
and all of that.

99:59:59.999 --> 99:59:59.999
But, you know, once you're into the thing,

99:59:59.999 --> 99:59:59.999
there isn't a whole lot of flexibility 
happening

99:59:59.999 --> 99:59:59.999
and it leads to questioning just 
what is it that we're up to

99:59:59.999 --> 99:59:59.999
when we are talking about 
agile learning design?

99:59:59.999 --> 99:59:59.999
Are we talking about 
agile 'learning design'

99:59:59.999 --> 99:59:59.999
or are we talking about 
the design of agile learning?

99:59:59.999 --> 99:59:59.999
Two different things,

99:59:59.999 --> 99:59:59.999
and it seems to me that 
it doesn't make sense

99:59:59.999 --> 99:59:59.999
to give the instructional designers
all that freedom and flexibility

99:59:59.999 --> 99:59:59.999
if we're going to march students
lockstep through

99:59:59.999 --> 99:59:59.999
a predefined kind of process.

99:59:59.999 --> 99:59:59.999
Here's what agile learning design
ought to look like.

99:59:59.999 --> 99:59:59.999
There's a flow.

99:59:59.999 --> 99:59:59.999
This is agile design generally, right?


99:59:59.999 --> 99:59:59.999
And it's an iterative thing,

99:59:59.999 --> 99:59:59.999
and yet people don't talk 
about that so much

99:59:59.999 --> 99:59:59.999
but it's an iterative thing.

99:59:59.999 --> 99:59:59.999
Each iteration is like designing a full
and complete product,

99:59:59.999 --> 99:59:59.999
and then you might spin off 
some side things, some prototype things

99:59:59.999 --> 99:59:59.999
as you need to, but, you know, 
version 1, version 2,

99:59:59.999 --> 99:59:59.999
you're doing the same thing over again.

99:59:59.999 --> 99:59:59.999
No course in the world,
well, maybe not no course,

99:59:59.999 --> 99:59:59.999
but few courses in the world 
are designed that way.

99:59:59.999 --> 99:59:59.999
Courses progress from Lesson 1, 
Lesson 2, Lesson 3, Lesson 4.

99:59:59.999 --> 99:59:59.999
They don't cover all of geometry 
and then all of geometry in more detail

99:59:59.999 --> 99:59:59.999
and all of geometry in more detail.

99:59:59.999 --> 99:59:59.999
It's a different way of thinking
about the process.

99:59:59.999 --> 99:59:59.999
So, one of the major concepts
in agile learning design,

99:59:59.999 --> 99:59:59.999
in agile design generally, it's the Scrum.

99:59:59.999 --> 99:59:59.999
The Scrum is basically a self-organizing
development team.

99:59:59.999 --> 99:59:59.999
It is originally drawn from the idea that

99:59:59.999 --> 99:59:59.999
programmers are the smartest people 
in the world and do not need management.

99:59:59.999 --> 99:59:59.999
No, I'm just kidding, but there is 
the idea here that

99:59:59.999 --> 99:59:59.999
the programmers know how to program, and
they know how to produce the outcomes,

99:59:59.999 --> 99:59:59.999
if they're left to do the job for 
themselves, to organize for themselves.

99:59:59.999 --> 99:59:59.999
And indeed, in the Scrum meeting,
as you are mapping out the task,

99:59:59.999 --> 99:59:59.999
each of the tasks, in the Scrum itself,
selected by the programmer.

99:59:59.999 --> 99:59:59.999
So, they're volunteering to jump in,
to do these things.

99:59:59.999 --> 99:59:59.999
They're taking commitments on themselves,
they're specifying how much time,

99:59:59.999 --> 99:59:59.999
how much effort will be required 
to produce the commitment.

99:59:59.999 --> 99:59:59.999
So, OK: that's good
but this doesn't happen by magic.

99:59:59.999 --> 99:59:59.999
It takes time, and agile 
is typically employed

99:59:59.999 --> 99:59:59.999
in larger software development projects.

99:59:59.999 --> 99:59:59.999
But when we're doing learning design,
we're doing something a lot smaller

99:59:59.999 --> 99:59:59.999
and a lot more precise.

99:59:59.999 --> 99:59:59.999
The question came up earlier, you know:

99:59:59.999 --> 99:59:59.999
"What about, you know, high-volume
instructional design?"

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

99:59:59.999 --> 99:59:59.999
of your development team 
organizing itself.

99:59:59.999 --> 99:59:59.999
Another problem:

99:59:59.999 --> 99:59:59.999
as your projects get bigger -- and we've 
worked on some very large projects --

99:59:59.999 --> 99:59:59.999
your teams get very large.

99:59:59.999 --> 99:59:59.999
If you think about 
all the different people who can,

99:59:59.999 --> 99:59:59.999
and eventually will get involved
in the design of your learning,

99:59:59.999 --> 99:59:59.999
or in the delivery of your agile learning,

99:59:59.999 --> 99:59:59.999
you've got designers, you've got
subject matter experts,

99:59:59.999 --> 99:59:59.999
you've got programmers, you've got
human interaction specialists, etc.

99:59:59.999 --> 99:59:59.999
......... (check) do you get a very large,
very complex team.

99:59:59.999 --> 99:59:59.999
As you get larger teams, you will not
generate more efficiency, it's well known:

99:59:59.999 --> 99:59:59.999
you generate less efficiency.

99:59:59.999 --> 99:59:59.999
So, what's the solution?
Split the teams.

99:59:59.999 --> 99:59:59.999
OK. Now you have competing development 
teams working on the same project.

99:59:59.999 --> 99:59:59.999
This sounds, like, you know, OK, 
we've split the task, it's great.

99:59:59.999 --> 99:59:59.999
But when you split the task,

99:59:59.999 --> 99:59:59.999
you now have two different groups 
of people with different objectives,

99:59:59.999 --> 99:59:59.999
different responsibilities.

99:59:59.999 --> 99:59:59.999
They're competing often for resources,
they're competing often for priority.

99:59:59.999 --> 99:59:59.999
We have a project where we had 
two agile teams.

99:59:59.999 --> 99:59:59.999
We ended up with two versions 
of the thing that we were developing.

99:59:59.999 --> 99:59:59.999
Basically, they had -- they didn't split
into functional groups,

99:59:59.999 --> 99:59:59.999
they -- what's the word for it? 
errh one-cell devide: mitosis --

99:59:59.999 --> 99:59:59.999
So basically, we got two small versions
of the project we were trying to create.

99:59:59.999 --> 99:59:59.999
Another pitfall:

99:59:59.999 --> 99:59:59.999
if you try to organize your groups into,
you know, OK,

99:59:59.999 --> 99:59:59.999
this group will do <i>this</i> part of it,
this group will do <i>that</i> part of it,

99:59:59.999 --> 99:59:59.999
you get specialized Scrums.

99:59:59.999 --> 99:59:59.999
So now, nobody's working on 
the final project and the final product.

99:59:59.999 --> 99:59:59.999
And there is the danger -- I've seen this
and we've had this:

99:59:59.999 --> 99:59:59.999
in effect, I'm living this 
at this very moment

99:59:59.999 --> 99:59:59.999
where everybody, all the teams 
want to do the analysis bit,

99:59:59.999 --> 99:59:59.999
or the rapid prototyping bit.

99:59:59.999 --> 99:59:59.999
But we're trying to bring a product 
to actual users, at the end.

99:59:59.999 --> 99:59:59.999
We want it to be a deliverable product.

99:59:59.999 --> 99:59:59.999
Nobody wants to do the last stage
of error testing, of hardening the code.

99:59:59.999 --> 99:59:59.999
That's the least popular scrum.

99:59:59.999 --> 99:59:59.999
So they go back to they are wanting 
to do prototyping again.

99:59:59.999 --> 99:59:59.999
Finally -- well, not quite finally
but we're getting there --

99:59:59.999 --> 99:59:59.999
who is the product owner?

99:59:59.999 --> 99:59:59.999
In the Scrum process, 
you're delivering outcomes

99:59:59.999 --> 99:59:59.999
and the idea is that, 
as you go through each spring,

99:59:59.999 --> 99:59:59.999
which is short-term cycle
through your development process,

99:59:59.999 --> 99:59:59.999
you're producing outcomes,
you're producing deliverables

99:59:59.999 --> 99:59:59.999
and these deliverables 
are delivered to the product owner

99:59:59.999 --> 99:59:59.999
who will set the deliverable,
and even more importantly,

99:59:59.999 --> 99:59:59.999
define the conditions for the completion
of that deliverable.

99:59:59.999 --> 99:59:59.999
Did you do it or not?
How do you know?

99:59:59.999 --> 99:59:59.999
Well, you have to have certain criteria:
pass this test, reproduce this function.

99:59:59.999 --> 99:59:59.999
It has to be really solid 
and ........ (check)-free.

99:59:59.999 --> 99:59:59.999
Well, that good in education -- Sorry, 
that's good in software development,

99:59:59.999 --> 99:59:59.999
your product owner is your client,

99:59:59.999 --> 99:59:59.999
perhaps your architect, 
somebody like that.

99:59:59.999 --> 99:59:59.999
They know what they want.

99:59:59.999 --> 99:59:59.999
Education is completely different.

99:59:59.999 --> 99:59:59.999
In education, there is 
no product owner per se.

99:59:59.999 --> 99:59:59.999
Think about it, think about the different
populations that are involved in learning.

99:59:59.999 --> 99:59:59.999
There is the end user, 
also known as the student,

99:59:59.999 --> 99:59:59.999
who, in the typical instructional design
process, does not show up until

99:59:59.999 --> 99:59:59.999
after the instructional design 
has been done.

99:59:59.999 --> 99:59:59.999
It makes it very hard to be agile.

99:59:59.999 --> 99:59:59.999
There is the subject matter expert,
also known as the professor.

99:59:59.999 --> 99:59:59.999
The professor has his or her own ideas
of what this deliverable must be.

99:59:59.999 --> 99:59:59.999
Then there is the administrator, 
the dean or the president,

99:59:59.999 --> 99:59:59.999
or the Department of extended learning,
or whatever,

99:59:59.999 --> 99:59:59.999
who have other objectives of, then 
revenue objectives,

99:59:59.999 --> 99:59:59.999
or course completion objectives:
they have their own definition.

99:59:59.999 --> 99:59:59.999
All of these definitions are different.

99:59:59.999 --> 99:59:59.999
I guarantee you they are conflicting
and they are competing.

99:59:59.999 --> 99:59:59.999
You can't just pick one, 
because if you pick one,

99:59:59.999 --> 99:59:59.999
you're not being agile for the others.

99:59:59.999 --> 99:59:59.999
What's worse?

99:59:59.999 --> 99:59:59.999
To have not only competing interests,
to have different levels of expertise.

99:59:59.999 --> 99:59:59.999
We're designing this system right now,

99:59:59.999 --> 99:59:59.999
where we're trying to create 
agile learning itself.

99:59:59.999 --> 99:59:59.999
This is -- I'm not going to talk 
about that,

99:59:59.999 --> 99:59:59.999
that's not the purpose 
of this particular talk --

99:59:59.999 --> 99:59:59.999
but but the ideas here is that
as the learning is unfolding,

99:59:59.999 --> 99:59:59.999
the process, the outcomes, 
the deliverables and all of that

99:59:59.999 --> 99:59:59.999
can change 
as the needs of the learner change.

99:59:59.999 --> 99:59:59.999
Very ambitious, really hard.

99:59:59.999 --> 99:59:59.999
We have to think about learning 
differently, in order to do that.

99:59:59.999 --> 99:59:59.999
Well, we've got our development teams.

99:59:59.999 --> 99:59:59.999
Our development teams were raised
in the traditional educational system.

99:59:59.999 --> 99:59:59.999
<i>Their</i> idea of education 
and online learning is:

99:59:59.999 --> 99:59:59.999
create some videos, put them online.

99:59:59.999 --> 99:59:59.999
Well, if we're iterating old world project
the first version of the project,

99:59:59.999 --> 99:59:59.999
also known as 
the minimally viable product,

99:59:59.999 --> 99:59:59.999
it's going to be pretty simple and it's 
going to be something that you could do

99:59:59.999 --> 99:59:59.999
with fairly traditional methods.

99:59:59.999 --> 99:59:59.999
And your programmers and developers,
all other things being equal,

99:59:59.999 --> 99:59:59.999
will fall back on the traditional methods.

99:59:59.999 --> 99:59:59.999
Because they're not being challenged
with the minimal viable product.

99:59:59.999 --> 99:59:59.999
The end goal where you want to get to
is something really flexible and dynamic,

99:59:59.999 --> 99:59:59.999
but by the time you get to stage 5 or so,

99:59:59.999 --> 99:59:59.999
they've built many, many 
static structures,

99:59:59.999 --> 99:59:59.999
because that's what it took to 
the minimally viable product

99:59:59.999 --> 99:59:59.999
at each release, at each iteration.

99:59:59.999 --> 99:59:59.999
So you have to start over.

99:59:59.999 --> 99:59:59.999
And you start over and everybody agrees,

99:59:59.999 --> 99:59:59.999
OK the project is about something
a lot more flexible than that

99:59:59.999 --> 99:59:59.999
and you start developing again
and the same sort of problem happens

99:59:59.999 --> 99:59:59.999
because your developers and your designer

99:59:59.999 --> 99:59:59.999
did not acquire that expertise 
in the meantime.

99:59:59.999 --> 99:59:59.999
So they go back on what they already know.

99:59:59.999 --> 99:59:59.999
So there's a difficulty here.

99:59:59.999 --> 99:59:59.999
In instructional design, we're attempting
to create an outcome

99:59:59.999 --> 99:59:59.999
that is not part of the skill set of the
people producing the product

99:59:59.999 --> 99:59:59.999
that results in the instructional design.

99:59:59.999 --> 99:59:59.999
Finally, learning objectives.

99:59:59.999 --> 99:59:59.999
This is the madder thing, right?

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

99:59:59.999 --> 99:59:59.999
the connectivist-style MOOC, we say
there is no curriculum,

99:59:59.999 --> 99:59:59.999
it's not about acquiring a certain 
predefined body of content,

99:59:59.999 --> 99:59:59.999
because we want to meet 
participants' needs

99:59:59.999 --> 99:59:59.999
as they go through the course, and 
these needs are different for every person

99:59:59.999 --> 99:59:59.999
and these needs change over time.

99:59:59.999 --> 99:59:59.999
And it should be up to the participant,
who ought to be the product owner,

99:59:59.999 --> 99:59:59.999
to define what success is and 
define what the outcome should be.

99:59:59.999 --> 99:59:59.999
It's a moving target.

99:59:59.999 --> 99:59:59.999
Nobody who funds education 
wants to deal with that. Nobody.

99:59:59.999 --> 99:59:59.999
Every last one of them wants to see
course completions, certificates,

99:59:59.999 --> 99:59:59.999
competencies, curricular outcomes.

99:59:59.999 --> 99:59:59.999
They want them defined ahead of time,
they want them approved

99:59:59.999 --> 99:59:59.999
by the curriculum board or 
the school board or whoever is in charge.

99:59:59.999 --> 99:59:59.999
All of this must be set ahead of time.

99:59:59.999 --> 99:59:59.999
And then you're supposed to go on ..... (check)

99:59:59.999 --> 99:59:59.999
It is two very contradictory perspectives 
at work here.

99:59:59.999 --> 99:59:59.999
It's not possible to do agile learning,
much less agile learning design

99:59:59.999 --> 99:59:59.999
in an environment where the structures
and the outcomes are predefined.

99:59:59.999 --> 99:59:59.999
That's meek (check), that's my short talk
and I thank you very much.

99:59:59.999 --> 99:59:59.999
(LAUGHTER - APPLAUSE)