ADDIE vs. SAM or, why I don't work well on Waterfalls

 

Yesterday I finally turned over what my latest web based class. A module was left off due to a dead laptop, a funeral, and massive illness eating 2 weeks of dev time. If my job had faster iterations per class it wouldn't be so annoying to leave off a module. I'd simply tell myself that I'd get back to it in the next iteration. Unfortunately, there are often months or years between course updates due to the time involved in producing an update as well as shifting corporate priorities. I would my current workplace stuck in an ADDIE process, but that's not quite true. The truth is we do have a waterfall process, but it's not strictly enforced. At least, no one has tried to force me to comply with a waterfall approach. 

I don't work well in waterfalls. 

As always, the biggest factor in my education design decisions is what the material is telling me it wants. The few times I've tried the up-front design approach it felt like a time sink. Extensively mapping out topics and slides on a spreadsheet at the beginning of development doesn't necessarily help. It can weed out a few issues, but often I find holes in the materials that require unplanned slides. 

In a true-to ADDIE process, I wouldn't be able to add those slides. It would throw off the entire workflow. The implication is that I already use a SAM-like process for my course design. The problem is I rarely have someone to specify requirements and provide the kind of input I need to guide my design. This is an unfortunately common problem in IT education design as often a class is built before customers exist. While this is always a bit of a problem, it's exacerbated by the designer/instructor isolation of my current position. Designers write classes, instructors teach them. Rarely are the two put in the same room to hash out an update to the courseware. When I do have the opportunity, my development process then resembles an agile course development process with three phases:

  • What are we teaching?
  • How are we teaching it?
  • Does this teach it?

The first phase, "What are we teaching?" is where desired features of the class are outlined and documented. The goal here isn't to create a detailed slide by slide outline, but to decide on the topics, modality, objectives, and overall shape of the course. This isn't all that dissimilar from how I usually start a new course development project. 

The following phase, "How are we teaching it?" iterates through each feature (or closely related sets of features) to create prototypes of interactions. Design, prototype, review. I did something like this during the orchestrator course where I outlined slides using empty text boxes rather than getting hung up on the graphics. It might have been useful at that point to turn the slides over to the customers (instructors in this case) to review the content. Provided I could even get their input, it would have provided a huge sounding board to the development process that I otherwise lack. 

The last phase is "Does this teach it?". Wireframes are filled in with graphics and material is brought back together. Each feature is reviewed to see if it could be improved, fixed, and most importantly, if it meets the original teaching objectives. If a test audience is available, the class is put in front of them as well. This is more difficult with instructor-led courses, and much more difficult with in-person courses. 

Once the last feature is approved, the course may be published. The question that comes to my mind, however, is "What happens after that?"

For new classes, the above process makes a lot of sense. You need all of those phases in order to build up the class into a cohesive entity. The problem is that it's very time-intensive. Is there a way to make the process shorter when updating the course?

What would be ideal is to update the course feature by feature. Course devs would only need to focus on one feature update at a time before release. This would allow much faster turnover of feature updates, but does expose the material as being incompletely updated.

If teaching in-person, instructor-led, or via a physical medium such as books, you really can't update in piecemeal. It has to be the "big bang" approach because of pragmatic concerns. If the training is online and not instructor-led, new training modules can be updated in this process. A version tagging mechanism would be required to inform users. Some modules might apply to multiple versions or all versions. 

What I would like to see was something more like DevOps for courseware. Small changes are rolled out constantly, rather than large updates that require lengthy development cycles. Perhaps it only works if the product itself is managed under DevOps. Without that, the big bang approach rules.