(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, 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, OK: 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 in 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.
Then so (check) you get a very large, very complex team.
As you get larger teams, you will not generate more efficiency, it's well known:
you generate less efficiency.
So, what's the solution? Split the teams.
OK. 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? errh one-cell devide: 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, OK,
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 and the final product.
And there is the danger -- I've seen this and we've had this:
in effect, 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 are wanting 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 spring,
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: pass this test, reproduce this function.
It has to be really solid and ........ (check)-free.
Well, that good in education -- 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 this 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 of, then revenue objectives,
or course completion objectives: they have their own definition.
All of these definitions are different.
I guarantee you they are conflicting and they are 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 only competing interests, to have different levels of expertise.
We're designing this system right now,
where we're trying to create agile learning itself.
This is -- I'm not going to talk about that,
that's not the purpose of this particular talk --
but 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 old world 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 5 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,
OK 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 madder 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 on ..... (check)
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 predefined.
That's meek (check), that's my short talk and I thank you very much.
(LAUGHTER - APPLAUSE)