Monday, January 7, 2013

I ran across an article the other day that rekindled my interest in applying agile software development methods for eLearning development. The gist of the argument made was that the traditional ISD Approach, that is, analyze, design, develop, and evaluate (ADDIE) doesn't lend itself well to accommodating frequent changes in requirements and ultimately leads to waste. Instead, many people are considering using more of an agile software development approach to develop elearning through frequent iterations; each iteration bringing the solution closer to a more refined state. All of the articles I read, however, describe the current application of ADDIE as a lockstep, linear (waterfall) approach. That is, the ISD follows the ADDIE process linearly, not moving to the next process step till the previous one is complete. I don't think, however, that this is how ADDIE is typically applied in practice. Rather, I've worked on many projects that applied ADDIE in an iterative way. One of the most practical tips I took away from a mentor during my first week on the job at a consulting firm was, "the customer shouldn't be seeing the product for the first time at the end of the project. NOTHING should be a surprise. In other words, we should we working with the customer throughout the entire process to gather requirements, validate assumptions, design approaches, and evaluate solutions. Hoping to have every bit of information necessary to move from one process step to the next is a pipe dream. That's why it's said that projects are progressively elaborated. Count on learning more details as the project unfolds, accept there's an ammount of risk that must be factored for, and have a plan in place to manage changes to the project. Perhaps this all just boils down to how you see the ADDIE process. If you see it as a linear, waterfall process, then it can use an overhaul. If, however, you see it as iterative anyway, I don't think you'll find much need to change.

No comments: