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 - YAGNIThe 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 PostsThe 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