The Agile Elearning Design Manual - Iterations huh?

I was unsure about what I should write in this blog post. I realized that I had perhaps generated some sort of interest in iterative elearning development, but I hadn't written enough about what goes into an iteration. So it doesn't take any guessing why I've chosen this as the topic for today's post. The key is not in a process or a tool. In keeping with the Agile Manifesto, our preference is for individuals and interactions. In fact "Individuals and Interactions" will be my theme for the next few posts as well.

What's an iteration again?

When I mention an iteration, I'm talking about a fixed duration of time (1 or 2 weeks). That said, to iterate is equivalent to painting a picture. You start with a rough idea in mind, you draw a pencil sketch, you then start adding shades, then you add colour and finally you blend the colours in, to create a final picture. There's also the concept of incrementing, where you gradually add blocks to come up with the final product. This is analogous to assembling a product in a factory. You have a set of previously fabricated parts which you can then put together to build your final product.

Agile elearning development uses both these strategies. During a fixed length iteration, we build elearning for various actions which incrementally add up to the customer's desired elearning solution. For other actions, we may be working artistically -- from rough sketch to final picture. Here we build in as many feedback cycles as we need to -- so as to ask the customer if we're on the right track!

So where do we start?

Here's an example of a partial action map. Its always nice to model your action map on a whiteboard with post-its or index cards. Index cards definitely last longer and are sturdier than post-its. The larger surface area and the ability to write on both sides is nice too. Anyways, I like to model my action map with Index cards and I stay Lo-Fi until the last responsible moment.

As you can see, the Actions are indicated by blue cards, the Activities in pink and the minimum information needed for these activities are indicated in yellow. The blue index cards are critical to our planning process and represent a mini module each.

Weren't we talking about what goes into an iteration?

Woah! Let's get back on track. In short, its the customer who decides what goes into an iteration. But before that, its important for you and your team to decide how much work can get done within an iteration. Its best to keep this simple as you go on, though with large complex projects you may need to figure out a science behind your estimation techniques. As of now, lets consider that your understand how much work you can get done within your iteration (which is always a fixed length-1 week or 2).

The key from this point on, is for the customer to work with you which pieces of elearning get done in which iteration. This is purely dependent on the customer's business goals and priorities. Your release plan could look something like this. I like to size mini modules in such a way that none of them span more than one iteration's worth of work.

This of course is only a plan. Reality could be significantly different. This plan however gives you an indication of the customer's priority and you know what order of development will generate maximum value for the customer. We all know that a plan is subject to change, but you can change your plan only if you have one!

Sometimes the answer is - YAGNI

The cool thing about developing in an Agile fashion is that the customer can see the highest value elearning really quickly. The Pareto principle says that 80% of the effects come from 20% of the causes. At times, this translates itself into elearning development as well. Often, by the time you've developed 7 out of 10 mini-modules, the customer could realize that they've either already achieved their business objective or that they are well and truly on their way to doing so.

What about the remaining elearning? You Aint Gonna Need It -- YAGNI! Dividing our huge project into small chunks means that we don't create elearning until the time the customer really needs it. Highest priorities come first!

If you do run into such a situation, it means the customer can use their budget elsewhere and they obviously trust you to help with more work in another area. That's obviously great for the team, since you get to do more interesting work! It saves you the effort and your customer the money!

Remember that YAGNI could apply to other things as well. For example that expensive custom interaction in Flash -- is there a simpler way to do it? Does the customer really need all the fancy things he is asking for? Maybe not -- always suggest the simplest, instructionally sound solution that works. The bells and whistles are not really critical to the purpose. What the customer really needs is high quality, interactive learning and he needs it fast! So the next time the customer asks for a seemingly unnecessary feature/ interaction, ask him if he really, really needs it. What's the value he's trying to achieve? What's the simplest solution?

---

As you can see, planning simple iterations isn't all that tough! Please feel free to let me know what you think about this approach. I know that I'm illustrating only happy paths for now. Do you have questions specific to your situation? Please feel free to ask me those questions!

My following posts will deal with some of the people considerations on such projects and teams. If you have any thoughts about how to empower people in your team, feel free to let me know.

Related Posts

The Agile Elearning Design Manual - Problems with existing Approaches
The Agile Elearning Design Manual - Agile Re-explained
The Agile Elearning Design Manual - Think Small (Iterations, Action Maps, Storyboards, and Mini-Modules

The Agile Elearning Design Manual - Think Small (Iterations, Action Maps, Storyboards, and Mini-Modules)

We explored the waterfall approach towards elearning development in a prior post of this series. As you will notice in the above representation of the model, the issues are:

• Too much time gets spent in upfront design and planning when all of this is quite likely to change.
• Customers get to see working elearning pretty late in the process - as a consequence we run the risk of an endless cycle of amendments.
• Actual deployment takes months from actual initiation of the project - this delays learner feedback, which is key to evolving the training content and increasing effectiveness.

Can we reduce flab in our analysis and design phase? Can we create more opportunities for customer feedback? Can we release working elearning quicker, to harness learner feedback sooner than later? I believe the answer is a resounding "Yes!"

Run Shorter Sprints - Be Iterative

Please refer the diagram above. If you take a look, you'll notice a few things are different:

• We conduct an Elearning Inception to begin the project. We'll discuss the process and outputs of this exercise in a bit
• We are working in shorter cycles of Design, Develop and Deployment -- what I call the D-cube iterations! This replaces the traditional ADDIE marathon.
• The end of an iteration marks the opportunity to showcase working elearning to the customer, seek feedback and to potentially release the module(s) to learners.
• We're always just one iteration away from being able to incorporate learner and customer feedback. This makes our development process truly involved.
• This process continues until you have a complete elearning course developed

The questions that may arise are:

1. What happened to the Training Analysis phase?
2. What's the Inception?
3. What kind of design are you doing in each iteration?

The next section will answer the first two questions.

The Elearning Inception

The Elearning Inception is a visioning exercise cum training analysis phase. This said the outputs of an Elearning Inception should be limited. Here's what you should look at getting out of your inception:

• The Business Vision - what business goals will your elearning support?
• Learner Personas - who are the people you're targetting? What's their role, experience, work environment like? What are their wants and desires?
• How many training modules does your client/ internal customer want this project to span?
• What's the framework you'll use to build your modules? Rapid Elearning? Bespoke Flash? Server based elearning?
• Prototypes that create shared understanding about the project framework and help establish a style guide for your modules.

The most important outputs from an Inception however are your Action Maps.As I've mentioned earlier, I am a devotee of Cathy Moore's Action Mapping approach. If you are an Elearning designer, it doesnt matter how experienced you think you are - I strongly recommend that you subscribe to Cathy's Elearning Blueprint for access to some of the most refined thinking about Elearning Design.

The Action Map replaces your lengthy design document and outline with a non linear, modularized plan. Each Action on the map can effectively answer a "How do I..." question and be a learning object in its own right. This gives you tremendouse benefit and flexibility as you'll see in a bit. Most importantly, it breaks down your big learning problem/ solution into small manageable pieces of work and it replaces lengthy training analysis with an artifact that lends itself easily to change.

Storyboarding - Simple, Lightweight design

The index card is my favorite design tool. Once we've established our Action Map, we move into fixed length iterations. Depending on the size of the "how-to's" we schedule one or more such modules for completion within these iterations which are typically one or two weeks. We now need to break the Actions, Activities and Information into elearning screens. The best way that I've discovered to do this, is by laying out index cards with lo-fi sketches in a storyboard. I'm sorry I don't have a picture of this, but Garrey Reynolds writes most eloquently about this technique. The rules I follow for this exercise are as follows:

• Each index card represents an elearning screen.
• Use post its to simulate elements that are part of click and reveal interactions.
• Try to get at least your rough text onto the card -- this ensures that you know what you need to write in your module.
• Showcase this lo-fi prototype to your customer to seek feedback and to modify your design if necessary.

This is the design work you and your team undertake during the iteration. The key is that everyone's involved - the builder, the designer and the graphic artist. This creates shared ownership about the design and the content and everyone knows what they're trying to achieve. As a consequence, they're empowered to make a trade-off if they see that a certain screen is difficult to build or not feasible or just doesn't provide enough value. The design isn't set in stone with a document. Its just represented by a card, which really is a placeholder for conversation. The card's easy to rip up and move around, so there's very little ego attached as well!

Know your Learning Management System

The last thing I want to touch upon for this blog post, is your Learning Management System (LMS). A common problem that in-house learning teams and consultants face, is that they have no control over how the elearning will be deployed. I feel this should change. As a consultant, you should demand access to the LMS and so should internal learning teams. An LMS hosts your content and can give you great flexibility in deploying your learning. Your LMS can often reduce your work considerably as well. You don't necessarily need to place everything in Elearning! Can something be covered off by a YouTube/ Vimeo video or a Slideshare deck or a Scribd document? Do you have an interview that people can listen to?
The LMS also allows you to deploy as many SCORM files as necessary for your course. So you could deploy a few elearning modules in Iteration 1 and a few in Iteration 2, and a few in Iteration 3. With a little internal marketing, you could even create anticipation in the organization for your next installment of online learning. See the example above to see how different elements make up a non-linear course. Most importantly this reduces a huge overhead of developing course navigation. The LMS now takes care of that. You can now deploy discrete pieces of learning, job aids, templates and what have you and not worry about how your elearning tool will handle all these artifacts. By delegating these concerns to your LMS, you also treat your learners as adults. Does everyone need to go through 2 hours of elearning? Could people just get answers to questions that they have doubts about? The modularized approach allows you to target people at varying experience levels and also helps you develop iteratively.

Your problem does get compounded if you don't have an LMS. You could try creating a simple website with DreamWeaver or RapidWeaver if you like, or work with IT to deploy a Free LMS like Moodle. Moodle is the world's favourite LMS with thousands of registered installations. Most importantly, it can be made to look the way you want and is extensible. So if you feel innovative, nothing stops you from looking under the hood to change how Moodle behaves. Also, Moodle can generate pretty decent reports and if you have a reasonable knowledge of databases, you can generate just about any report you want!

---

The above practices are the few basics to take care of when developing on an Iterative, Agile approach. In the next post I will introduce a few other practices that will help you rapidly deliver lively elearning.

The Agile Elearning Design Manual - Agile Re-explained

In my last post we looked at the problems with our existing approach to building elearning. In summary, the problems we noticed were:

• A lack of shared understanding within the team, about the the customer's learning problem.
• The high risk associated with not having generalists in the team.
• The delay in seeing working pieces of elearning.
• The time spent in creating documentation and in analysis.
• The risk of endless reviews and amendments.

In today's post I'd like to introduce Agile thinking. Now this post may seem very philosophical, but it serves as the context that we keep referring back to each time we start developing elearning. In fact for those who haven't ever heard of this approach before, Agile is an extremely mature software development methodology, and surprise, surprise its the approach we follow at ThoughtWorks! A couple of questions to answer first up:

Why are we using a Software Development Methodology for creating Elearning?

Elearning development isn't very different from Software Development. In fact, if you look at it, any piece of Elearning is really a software program often written in Flash. Now the tools that you use, may have varying levels of sophistication and that's true on software projects as well. The final output requires as much of the scientific mindset of a programmer as it does the creativity of a User Interface designer.

I am a one-woman-team. How does this methodology apply to me?

A lot of the team related practices may not apply to your current situation. Who knows what may happen tomorrow? There are however a lot of practices that you will find relevant whether you're part of a team or not. Stay tuned each week and you'll see what I mean.

Is this your invention?

"One good thief is worth ten scholars." - Randy Pausch.
No, not at all. I'm not wise enough to invent anything -- I am trying to distill the wisdom from various approaches that I've seen and been amazed by in my career as a learning professional and most recently as an elearning designer. So you will find thoughts from Jane Hart, Cathy Moore, Tom Kulhmann, a thousand ThoughtWorkers and many others that I'm "stealing" to piece together what I call the Agile Approach to Elearning. Hopefully, you'll see the nuggets I'm trying to place in front of you and go back to the original source to learn more.

Can I apply these principles to Instructional Design for Classroom Training?

Yes you can! That said, some principles may not apply to your current situation or work. You may have to go on the same journey as mine to determine what works best for you and what doesnt.

If you have more questions, please do comment on these posts or email me and I'll be happy to answer them for you. So, without further ado -- lets set some context!

The Agile Manifesto

If you look at the Agile Manifesto, you'll see that none of the trade offs seem revolutionary. They're exactly what you'll call common sense. If you look at my modified manifesto above, you'll perhaps notice the same common sense.

If a customer had to trade off between Engaging Elearning and Comprehensive Documentation he would certainly choose the former. We know that when we provide a service, its the people that provide the service that matter the most. We also understand the importance of communication and more importantly conversations. So we choose Individuals and Interactions over Processes and Tools. Negotiating scope doesn't solve the customer's problem - Customer Collaboration does! And yes plans are important, but Responding to Change becomes more important, because a customer doesn't change their mind just because they want to! They change their mind or ask for a change in the elearning because it serves their business goal much better!

The key thing to remember is that there's definitely value in the items on the right. In the case of a trade-off, we value the items on the left a lot more.

While I run the risk of metamorphosing this post into a Wikipedia article, there are a few principles that I feel are key to understanding Agile Thinking:

• Customers really appreciate progress when they see working elearning. Getting this out quickly is our primary focus.
• Face to Face conversations are the best way of understanding the customer's problem and designing a viable solution.
• Change is the only thing that's constant - the longer we take to show the customer working elearning, the more likely his needs are to have changed. Shorter releases ensure quicker feedback thereby helping us stay abreast with the customer's requirements.
• A group of motivated and skilled individuals in the right environment will get the job done.
• The best designs will emerge from self-organizing teams rather than those that are heirarchical in their organization and their workflow.

Key Take-away

The manifesto is our guide to making decisions throughout the length of the project (big or small). At each point we should question ourselves against the manifesto. Are we collaborating with the customer? Are we creating documentation as against creating elearning? Are we focussing on conversations or are we following process? Are delivering to plan or delivering to the customer's needs?

I know that elearning project managers who've run fixed price projects will scoff at this approach, but really the contract shouldn't dictate the development process. It should dictate how we engage the customer and it just means that we keep an eye on risks a lot more, talk to the customer early and often! More about this in a later post perhaps!

The Guiding Values

Yet again, the Guiding Values are our benchmarks to ensure that we're on the right track with our approach and our selection of practices. I'll try to be brief in my descriptions:

Communication

The builders deliver business value to the customer. Its important that they have shared understanding about the goal and the task on hand. To this end, we favor simple designs, common metaphors, collaboration of users and builders, frequent verbal communication, and feedback.

Simplicity

We start with the simplest solution that satisfies the customer's need. Bells and whistles can then be added later. We keep our course modular, so that different parts adress how to do different things. We try to keep knowledge acquisition separate from teaching skills. We try to avoid complicated functions that can otherwise be delegated to a Learning Management system. Looks are important -- but we avoid 'complicated' graphics as far as possible. Our design meets today's requirements - not those of a year later! Simplicity in design and building should improve the quality of communication - everyone should be able to understand what different parts of the elearning module do and how they work together.

Feedback

You don't know how well you're doing until you have feedback. We need to show the customer working elearning ASAP, so that we know what we're doing right. The team needs to be able to critique the design and evolve it over time. The design should accomodate this critique. The team needs to be able to give itself feedback about its approach and tweak it from one run to another.

Courage

Courage can be displayed in many ways. Builders can point out issues in the design to the rest of the team. The team should feel comfortable to throw away a piece of work since it didn't serve a purpose. Courage means persistence - we stick at it to solve the customer's business problem. Courage is also a project management thing - we ensure that the team has a sustainable pace and no one's on a deathmarch!

Respect

Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through continuous improvement.

Next up -- the Practices!

Here's the point at which we'll start to talk about the practices. While the values and the manifesto happen to be our guiding light, we need real. solid practices to take to the ground. In the next post, I will get to the stuff beyond the fluff! The contents of my next post will address the life-cycle of an Agile elearning project and how you can conduct an Inception for such a project. Stay tuned, I've got loads to share with you!

The Agile Elearning Design Manual: Problems with existing approaches

In recent months I've met over 50 elearning practitioners and evaluated at least 6 elearning firms. My inspiration for this series of posts has been what I've learnt about their style of learning design and how approaches we've tried internally at ThoughtWorks compare as a stark contrast. In today's post I want to outline the current state of elearning content development in the industry. Understanding the pains of this current state will help us explore the virtues of Agile Thinking in future posts. In order to describe my thinking better, I've gone ahead an adopted Dan Roam's Six Ways of Seeing from The Back of the Napkin. The topics I want to outline today are:

• The composition of the teams that deliver the learning modules.
• The standard process followed by many internal teams and design firms.
• The need for a change

So without further ado, lets get going.

The people behind the scenes on a typical elearning module

On most elearning projects (mind you a project could mean multiple modules and a rather complicated delivery), the key roles I've observed are the ones I mention in the picture above. These roles are:

• The Project Manager
• The Instructional Designer
• The Builder
• The Tester
• and the Freelance/ Multi-departmental Graphic Artist

Those roles are pretty representative of what happens on a software development team as well, except when you consider the following problems in their implementation:

• This is not really a team in the first place -- people depicted in this group generally work on multiple things one of which is the client's elearning project. So, they aren't really dedicated to ONE purpose. They're doing their jobs in a factory atmosphere where every machine has a transactional purpose.
• The only people in contact with the customer are the Instructional Designer and the Project Manager
• The only people that understand the customer's problem and the subject matter of learning are the Instructional Designers
• The builder delivers the most value in the process of elearning development, but is the least respected. Her role is reduced to executing instructions from the Instructional Designers
• The Graphic Artist plays a very transactional role in the project. He works with descriptions provided by the Instructional Designer, without any considerations of whether the final output fits the image of the client or the learning material in the module.

If you look a little deeper into the skills that this team has, you will notice that there is very little overlap between the skills of various people in the team. While yes, there's a small overlap between Builders and Testers, the skills of Graphic Design and Instructional Writing seem to be completely detached from others. Which is to say that the Graphic Designer has no idea how to design an elearning module, the Instructional Designer has no idea what goes into building an online course (even with rapid tools) and the Builder can't even do basic instructional design! I've written earlier about the need for Learning Generalists. The risk on these teams is extremely high, considering that they're groups of extremely uni-dimensional individuals, working with an un-shared purpose.

More about this when we come to the process.

The current process - a rather rigid one

The above picture depicts the method of content creation at most internal teams and design firms. The approach is pretty simple and will remind a lot of us of a modified "Waterfall" model of development. Here's an explanation of the pain points I've indicated:

• The process relies very heavily on the Instructional Designer to write on an MS Word Document (called a script) the details of:
  • What goes into the module
  • What text appears on screen
  • The interactions that'll get used
  • The pictures that'll get used.
  • The choice of media and activities
  
  
• Outwardly there's nothing wrong with this, until you consider that:
  • material is evolved from exisiting Powerpoint presentations than from a business discussion with the customer. Nothing wrong with Powerpoints except that they assume the SME's familiarity with the topic; are written in non-ubiquitous language; could be meant for a completely different audience and are generally poor instructional documents
  • the format used to determine if the customer/SME is happy with what they will SEE is a document that has NO VISUALS. The customer doesn't even see a prototype to know the impact of saying OK or not OK.
  • the approach relies on getting all of the training module nailed down up front which is practically impossible until the customer see's something in action - a problem commonly experienced on Waterfall projects.
• As you will notice, there's no safety net to account for "incorrect" analysis since the Builders, Testers and Graphic Artists have no idea of what the subject matter is.
• As a result if what the customer sees during the showcase is not what he thought he would get, its a whole new cycle of amendments which could go on forever.

Now if you look at the time taken for development and consider a 3 week development period for a training module, the "Script" takes the longest time to create. The actual value adding process of building takes very little time. In the ideal world, all the "Scripting" would be perfect and everyone would be happy. In the real world, people make mistakes and the Script doesn't necessarily reflect the customer's vision and this often leads to an endless cycle of amendments at the end of development which can span multiples of the actual development time required.

The process that you see above, doesn't allow for fast feedback. It doesn't allow for builders to collaboratively develop the module with Instructional Designers. Instead the Builders are expected to follow the script. Many designers believe they would be doing a bad job, if the builder had to come back to them with questions about their script. I remember a team where the builder and the developer were sitting at the same table and the Instructional designer was into her 6th day scripting. I asked her, what if the builder has questions about her script. Her face almost turned pale in horror and she said to me, "Well if I've done my job well and written a good script, there should be no reason for the builder to come back to me for anything!" Its something to think about. 10 days of documentation for 4 days of development work to be passed on to a colleague that sits at the same table! What ever happened to good old conversations? The customer doesn't see working elearning until very late. As a consequence, the showcase is a surprise -- good or bad, depending on the end product!

Time vs Cost vs Effectiveness

The question to ask ourselves however, is why do training organizations and design firms choose such a heavyweight method? The answer is simple -- because the previous method didn't work! The problem is that the previous method was a haphazard, non-scientific, cowboy practice of "Hey lets get going with development!", long before identifying the training need, breaking it down into actions and then learning activities. The "lets develop" attitude was obviously marred by the absence of any planning or visioning, led to different strands of unexpected work emerging, context switches, involved but confused customers, ineffective learning, a huge time to market and a high cost.

So, what did the experts decide? To compensate for not planning, they overplanned. To compensate for not analysing, they over-analysed. To compensate for customers changing their mind all the time, they added levels of documentation for different people to say "I do!". And to stop builders from going all nuts about a new module, they regimented them into following instructions from a Word Document. Sounds like a typical response and I don't fault anyone for this. To be fair, the current solution definitely works well compared to the problem state it tried to address. Is it ideal for the customers though? Does it help create a shared sense of purpose in the team? Does it respect the ability of builders and graphic designers? Does it foster communication within the team or reduce the risk of misrepresentation of customer requirements or plain miscommunication? Does it give the team the ability to fail fast, learn from its mistakes and delight the customer? The answer I'm afraid, is "NO!".

So what's the approach to follow then? That's what the Agile approach is all about. In the next post, I will outline some of the basic principles of Agile as applied in Software Development and how they apply to this particular context. I will also pick the most important practices and substitute them with usable practices for elearning development. If this post interested you, stay tuned for next Monday's article, and I hope you'll find that useful too. Till then, think about your approaches towards online learning and feel free to drop your comments if you'd like. I'll be really happy to hear from you.

From Rapid Elearning to Agile Elearning

I'm taking a bit of a focussed detour with my blog for a couple of months. I will keep posting about my pet topic of learning, but with the spotlight on online learning. During the next 2 months, I plan to run a series of blogposts called "The Agile Elearning Design Manual". Here's what I promise:

• Weekly blogposts outlining how you can make your elearning design simpler, rapid, effective and learner centered, using Agile development principles.
• A set of tools and techniques that you can bring to your training team to help you be aces at interactive content creation.
• This isn't final, but if I see this blossoming into something really useful, I intend to convert it into an e-book, that's freely available for downloads.

I plan to make my first post on Monday, 8th of June and post weekly updates thereafter. I expect this series to span a couple of months, but I'm not sure yet. As I know more, you'll know as well. The key for me is to find a place where I can share some of the thoughts that are buzzing most loudly in my head these days and I feel having a promised schedule to put these down in writing will make me crystallize some of my disparate thoughts in a better manner. Well, good luck to me for that and I hope the future posts are useful.