Dec 04, 2015
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 me, that's my short talk and I thank you very much.
