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.
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).
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.
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 |
|
|
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
|
| 
|
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.
No comments:
Post a Comment