Tuesday, 17 September 2013

Agile Learning, or How Half a Course is Better than 95% of One

Agile Learning, or
How half a course is better than 95% of one

Greetings friends and colleagues, today I’d like to talk to you about Agile Learning. In particular, I’d like to show you (yes, show you – I have pictures!) why I feel Agile is better for you when you’re developing your courses (e-Learning, facilitated or otherwise).
As an added bonus (at no extra cost to you!), I’ll show you why half a course is better than 95% of one and how you can use half a course to satisfy training needs.
Let’s get started, shall we?
What is Agile?
Just in case you haven’t already come across the term before (or Googled it since reading the introduction to this post), Agile Learning is derived from Agile Software Development. Agile Software Development came about as a reaction to the more cumbersome Waterfall model (which was inherited from the manufacturing and construction industries).
Image credit: Paulsmith99 at en.wikipedia

Being as perceptive as you are (after all, my readers are all above average), you’ve probably already noticed how much that looks like the ADDIE model (Analysis, Design, Development, Implementation, Evaluation).

Agile, on the other hand, looks more like a loop or a spiral. Each time you get to that “working increment of software” step, you start a new sprint with another set of features from the backlog. You’ll go through several loops before you finish everything, but the total time will be similar to what you would take with ADDIE.

Image credit: Lakeworks at Wikimedia Commons


Let’s have a look at some of the founding principles of Agile Software Development that I feel have the greatest relevance for learning design:
·       Customer satisfaction by rapid delivery of useful software – you’ll get much farther showing working software (or course materials) to the customer than showing them documents with requirements or descriptions.
·         Working software is delivered frequently (weeks rather than months) – a shorter development cycle not only allows for the rapid delivery mentioned above but it critical to enabling the next two principles.
·         Regular adaptation to changing circumstances – Agile expects change. The short development cycle means that there are more frequent opportunities for course correction if circumstances change.
·         Welcome changing requirements, even late in development – late requirements changes are a nightmare for more traditional methods, but not for Agile.
How does Agile compare with ADDIE?
It compares very well.
Oh, you’d like a little more detail than that? That’s what I love about you guys, you’re so inquisitive.
It’s also much prettier, just look at those beautiful swooshes:

ADDIE  
Agile
ADDIE 1  
Agile 1

Pictures don’t do it for you? Don’t you realize that’s two thousand words’ worth up there? Fine, how about bullet points?
  •        More responsive/Easier to tweak: If you go off course (no pun intended), you’ll know about it before you get too far off course.
Because the client has multiple opportunities to provide input, there’s less risk of missing something as compared to having a single review at the very end. You’re going to make changes. Accept it. Why not get something out there faster and then tweak it?
  •         Handles late changes better: Don’t you hate last-minute changes? Particularly after you’ve already done a full analysis, and worked your way through weeks (or months) of design and development.
I can’t tell you how many times this has happened to me, both in my days as a trainer and during my time as a software developer. This is generally not the client’s (or the analyst’s) fault; it’s a shortcoming of the development cycle we were using. Often, when you get to the test or prototype stage you’ll uncover requirements that had been hiding (“You know… now that I look at it, I realise we need X as well.”)
  •         Ready sooner: In a pinch (sudden need, long delays), you can use the latest prototype (or working increment) until the final release is ready. This is where I get to deliver on my earlier statement that half a course is better than 95% of one.
How to make half a course better than 95% of one
First off, this is going to require a change in the way you work. I’d like you to treat each course objective as a “working increment”, “functionality element” or feature. Instead of coming up with all your objectives, then all your test items, then all of your instructional content, try coming up with all your objectives, then for each objective develop the test items and content before moving on to the next objective. That way, you can have the client review soup to nuts for each objective on its own.
I can tell you, as a SME (subject matter expert), that knowing there’s a course in development - but not quite ready - doesn’t help me when we have people who need that training right now. Having a course that’s 50% complete and can be used to deliver 50% of the training would free up a lot more of my time than having a course that’s 95% complete but can’t be used at all. Think about it, which position would you rather be in?

ADDIE
Agile
ADDIE 2 Agile 2


I recently reviewed a document describing a series of related courses a friend of mine is developing. Given the large scope of that program, it’s understandable that there were quite a few course objectives. There were quite a few test items to review as well. Looking back, I don’t know that I can say with certainty that the test items covered every course objective. My impression was that they did, but I’m thinking it’d be way easier to be certain if the document I was reading had each test item appear directly after the objective it related to.
In fact, I think I’ll develop this idea further. Watch the blog for news on that as it develops (pun intended). It might be even better if each objective had its own document. It seems to me this will also make your job easier.

First thing’s (not necessarily) first
Prioritize your functionality elements (i.e. your course objectives), then design and develop each one in priority order. As each element is completed and signed off it becomes available for use.
“But Simon,” I can hear you thinking, “what if the clients lose interest or pull out before we complete all the elements?” No biggie, you’ve covered the most important parts. Even if you never go back and finish the other parts, what does that mean? It means that they weren’t important enough to make the cut. Congratulations! You’ve just saved yourself some unnecessary work. Doesn’t that feel nice?
“Isn’t that a lot of sign-off?” you ask “We can’t possibly bother our clients that much!” I’m glad you asked. Actually, this approach shouldn’t add to your stakeholders’ workload. Yes, they’ll have more frequent reviews, but on the flip side, each review will be smaller. I can tell you from my time as a SME that it’s much easier to find 15 minutes to review something small than it is to find a 3 hour block to review something large. Also (and I’ve been guilty of this myself) when you know that you’ve got several hours worth of reviewing ahead of you it’s hard to motivate yourself to do it. So you put it off. This contributes to delays which can throw your whole project off schedule.

What can go wrong (and why it’s not a problem)
What if the client doesn’t get back to me to review the prototype? If the client won’t make the time to get involved with what is ultimately their project, then maybe it’s not really a priority for them. If that’s the case, wouldn’t you prefer to know about it sooner rather than later? What would happen if you pushed ahead without the client’s involvement? There’s a good change the final product wouldn’t meet their needs. Such a situation only serves to frustrate the client and hurt your reputation.

What are your thoughts on “Agile vs. ADDIE” or “Agile-enhanced ADDIE”? Have you used Agile? Will you?
Do you have any ideas for an Agile-based course development methodology?
Either way, I’d love to hear from you. Sound off in the comments.