 I came up with this iterative view of instructional design and developing our open education resources. It's a clear adaptation from Kent Beck and his book Extreme Programming Explained. It's about agile software development. I thought in looking at this approach that it was very appropriate to course design. It was not just limited to an approach for programming. This extreme programming or agile approach came about because 85% of computer projects fail. What the agile approach does is it works in short iterations of two weeks. So every two weeks you have something that works. It's like an onion you build in a layered approach using modules. That software program today is more about assembling modules than it is about creating computer programs from scratch. In fact, I remember about a year ago a speaker from Microsoft was saying that they're looking at assembling. They don't consider themselves to be software creators. It's assemblers, so they take all kinds of modules and you put them together. So I thought this is particularly appropriate for people who are developing OERs. You take the OERs from all the different places, assemble them, and you have a course. But before I really get into that I'm going to do a very fast preview on mobile learning because the other point I want to make today is that we need to be designing for mobile devices. You should stop designing for print, stop designing from a PC on your desktop, and start thinking in terms of mobile devices because when you design for mobile you can easily port it to print, you can easily port it on a PC, but the other way around is quite difficult. And the reason I'm pushing that is right now there's 1.6 billion internet connections in the world. Out of a population this Halloween it will be 7 billion people. There's 3.4 billion mobile devices, 1.3 billion mobile internet users. One third of the world's population, sorry, one third of all the people who access the internet only access it using a mobile device. And here's an example, all over the world the smallest villages have mobile devices. And if you look at web usage worldwide and how they reach the web, you can see Asia. It's mobile devices more than anyone else, Africa, in the developing world. So it's a huge share of total web usage by region. And what you've got to do when you're developing for mobile devices is to take a tip from Ken Anderson and you've got to balance usability, the features, the accessibility, functionality, performance and what bandwidth people have. And you need to have it all in balance to ensure that it's workable on a mobile device. So you need fluid design to then make it flexible. Design it so you don't have horizontal scrolling in particular. And it's easy to do if you just think that way from the beginning. So again I'm going to say design for mobile first. Now extreme programming or agile development, it goes from the philosophy of Randy Paws. One good thief is worth ten scholars. And what it means is there's all kinds of stuff out there that we can use and we don't have to create it ourselves. So what is XP? It's extreme programming and approach to be adapted for web-based course development. And you take the requirement to design implementation, verification and maintenance. And the key to using extreme programming methodology is when the requirements are vague or changing. And all the time you find if you're developing a course where things change, the subject matter expert, what you're using, the technology, different things change and you need to be able to adapt to that. So you meet the goals of XP if you use simple design, unit testing. They use pair programming so they have two programmers working on it. And the key is the iterative development. So you build it like the onion. So you always, even after two weeks, you have something that works and that's the key to it. And there's too many, it's sort of the bizarre approach rather than the cathedral. So why do 85% of these projects fail? Why do we overrun in our course development costs? It's because we build a huge program and then in the end you find out it doesn't work and you're trying to fix it and debug it. With an iterative approach you make sure it works right away. Every little module, every tiny part of it. So you do a review, testing, design, simplicity. These are all principles of XP architecture and integration. And the key again, keep saying this, short iterations. So with the review you have two people watching it. And that's quite common in course design anyway. You have an SME and an instructional designer. So it's nothing that we can't do. Functional testing, when you build a module you test it right away, make sure that it works. Refactoring is you go back and test it again. And when you build a second module you go back and test the two of them together. And you pick the simplest possible design. And you go into a major project, you find out what is the minimum requirement for me to succeed in this project. Not the big project with all the bells and whistles. What is the minimum requirement that we need in order to complete? And you build that and make sure you have it and do it right away, do it in two weeks. And then you start adding on the other things. You use a metaphor as architecture. So you're building it and you use storytelling techniques as part of that. And integration is continuous. So when you don't sort of plan at the end you're going to integrate it into something. You do it all the time as you're working. And again I'm going to say it again and again. Really, really short iterations. So as you've always got something that works. Proven techniques. Early concrete feedback between the subject matter expert and the developer. Continuous feedback. Incremental evolving planning. That is you don't build the big and say we're going to build this big thing. You work at it as you go and you change it as you go. Flexible scheduling. Testing all the time. Testing to make sure it works and continuous collaboration. So how is this innovative? All the practices are under one umbrella of extreme programming. Practices thoroughly as possible. Ensure that the practices support each other to the greatest possible degree. And you have a mentality of sufficiency, not scarcity. And that's important to realize that with Infinite Bandwidth now and all of this. I mean we don't have to start thinking we have to design it and let it fit into one little box. So good practice. You have all of these. The review, architecture testing, design, short iterations, integration and simplicity. And we sort of always are adjusting. We adjust these things in all different ways. But with X speed you turn everyone up full volume. You really review the architecture, the testing, etc. You have that full capacity all the time. Because when you're doing short iterations you can do that. If you do a big one then you have to adjust. I'll do the review later. I'll be doing testing later. The design now is done up front. With extreme programming methodologies we can do that all the time as part of our course design. So a problem, your schedule slips. The XP solution use short release cycles. So why would your schedule slip? It means you're trying to do too much in too little time. Maybe you can do less. A project's cancelled. Solution, the smallest release that makes sense. So as if you're working on a project and the funding ends, if you've done it iteratively, you'll have something that works. You won't have to throw it away. Because you've been doing it in short iterations. So every step of the way you have something that works right from the beginning. Problem, the system goes sour and there's too many defects. Continuous testing, you've been testing all the time. So you know what works. Misunderstandings by developers. The content expert is part of the team. So you keep them into it at all times to eliminate any misunderstandings. The course changes shorten the release cycle. XP is perfect for somebody who says, and you always get this, the content, that's not just what I wanted. I said that, but I really wanted it this way. And with these type of changes, if you do it in an iterative way using an XP methodology, you can incorporate that in right away without it unduly affecting your project. Big problem, rich in features you don't need. Address only the high priority tasks. So as you've got something that works, and then you build something else that you need, something else the high priorities, and then at the end you'll find out, hey, we've got lots of time to put in the bells and whistles and features that may not be needed but are good to have. Staff turnover, people leave. You make people accountable for their own work. And we're talking about short iterations, so if somebody goes, they're accountable up to that point of what they've done. And we can be fairly sure that it's working. Control variables. You've got cost, time, quality, and scope. And we've all discussed the iron triangle. If you decrease the cost, it affects the quality, et cetera. And in a project, if you change the cost, if you have too little money or too much, it causes problems. And a lot of people don't realize that, but if you have too much money, it can cause real problems in developing in any type of courseware development. Time is a terrible control variable. You can have short-term gains, but it can be costly. Sorry, yeah. Time is a terrible control variable. You want to do short iterations. If you start stretching the time out, you're going to get yourself in trouble. Quality, you get a short-term gain, but it's costly. So if you sacrifice quality, there will be a little gain, but then you're going to get yourself in trouble. The key is the scope. The less scope equals better quality and less time. So you have a project like this. Reduce it down to its minimal of what you need. And then you've got it built. You have something that works great. Then add the other things on. Build the scope on after that. So in traditional projects, as they go further and further down, the risk goes up. But with agile projects, the risk leads down as you go on because you have something behind you that works. You've tested it, you've made sure it works, and you can be pretty sure you'll have something that works at the end. So the cost of change does not rise over time. So you build these big cathedral projects and channel, we can't change now because it's too much into it. But with XP, you can change at any time. Change is cheap using XP. You can charge ahead. You can defer decisions. You only need to implement what's needed. And quite often a lot of the dollar costs that you think are going to happen don't happen. You already made it. So the values are there. Simplicity, right at the top. Courage, go for it. Feedback, get feedback all the time. Communicate regularly with the people who are accountable and respect for each other. And the values are all there. Keep it simple, stupid. And work on symbol of a design and design it like an onion and have it out like that. The agile manifesto, highest priority is early user satisfaction. So get something that works up as soon as you possibly can and test it. Continuous delivery of valuable coursework. Welcome changing requirements, even if it's late into development. You know, don't panic when the subject matter, well no, I'd like to do this a little bit at the end. You can do that with XP. Deliver the working coursework frequently. Every two weeks have something. That's your goal. Every two weeks you have something that's working with testing. The faculty and developers must work together. Use motivated developers and faculty. Well, that's in anything that is always key. Support them and have face-to-face conversations whenever possible. Working coursework is the measure of progress. So, yack, yack, yack, I've done this, I've done that, and I've heard that from all the time. Oh yeah, I've got it. This is it, but it doesn't work. Yeah, I did exactly what you said, but it doesn't work. So you get working something that works. Sustainable development. You have continuous attention to excellence. Simplicity. Maximize the work that's not done. So pick the work, that kernel of work that needs to be done, and maximize the amount that hasn't been done, and then slowly you build on it. Self-organizing teams. And regular reflection on effectiveness and adjustment. So, the value. There's more value in individuals and interactions over the process and the tools you're using. Working software is more valuable than documentation. And you see some projects, people are very eager to document it. But customer collaboration is more important than negotiating contracts with them. And you see that all the time. Well, the contract said this, and you said that, and I meant this and I meant that. No, work together. Responding to change rather than following a plan. So you don't have a strict plan that you follow. You start responding to the changes as they're needed and come along. So that gives you my introduction to it, and I'll open it up for comments and questions. And I'm not saying that this is the only way you should do course design, but I think it's a good way. It's one good way you can do it. And I don't think that enough of a position doing it that way. I still see too much of the cathedral mentality in course design. Yes, sir. I'm going to ask you this directly. I mean, you work in an institution, which I helped create problems in years ago. And you inherited those. You've got a whole bunch of people that are wedded to that traditional way of doing things with major course teams. I remember our early courses cost over a million dollars each to produce. They were producing beautiful forms so that nobody wanted to even write on them. And they were like PhD thesis because faculty were worried about what they would look like for their peers. There's been a lot of evolution since then, but we all know that these things get quite embedded in our organization. So what happens when you introduce something like XP, the concept at a place like that? I'm going to turn the answer to that over to Cindy. Oh, that's not fair. We're not there yet. I can say that. But Cindy, where are we? We're better than what you're talking about. We've come a long way. We have come a long way. And Ross and I talked about this yesterday, but we are not doing agile development like you're describing it all. I think some of our projects could in fact benefit from something that's closer to that. The problem I have with your methodology is it's not in learning terms. And one of the things that we've found is beginning to work really successfully in working with professors is that we're talking to them in learning terms. So if we were to use this kind of a methodology, we would have to adapt it further so that we would talk about it because what we're really talking about now is a learning design approach. And that has resonance. Faculty are really concerned about what students are learning. And they're also... And they're less concerned, of course, at Athabasca about the teaching piece. And I think now, Ross, they're less concerned about their credibility because of the persistent offer for such a long time. So we need to embed the notion of learning design approach that speeds things up. Some of the resistance is not among the faculty though, I need to say. It's in the administrative systems that supposedly support the design and delivery of courses. And so we need some language that they can also understand. Anyway, it's an interesting idea that they take back and start working on it. But we're not doing it yet. Yeah, and I must say our computer services department say they're doing it. And they're not doing it. There's a few people there who are committed to it. And then you find out it's not really being done maybe partially or something. They're not really getting into it. But your point about it, this has to be described in learning terms. I think it can. I think we can. I think this can be very effectively put into terms of, you know, you get your module, one module, you get it. You don't think of the whole course going, do what I terribly change it as it goes along. I think we can do that. But you're right. And we need to do that. Yes.