I come to check briefly on what’s happening, late on an evening, and find a flurry of discussion that prompts reflection. It’s been an ongoing debate, with notables like Ellen Wagner and Brent Schlenker weighing in. In reading another post pointed to by Cammy Bean, I see a cogent discussion of how processes can be stifling or supportive.
I was reminded of a story told many years ago on a listserve, where both new and experienced (10 years) graduates of several ID programs were asked to design projects. The projects by the new graduates were categorizable by school. The projects by the experienced graduates were not, until the accompanying rationales were read. This was never published, unfortunately, but even as an apocryphal story, it’s instructive.
The point being, that the processes we learn are scaffolds for performance. ADDIE is a guide to help ensure hitting all the important points. It’s no guarantee of a good design. It takes understanding the nuances (see Broken ID), and some creativity.
Used appropriately, ADDIE reminds us to dot our i’s and cross our t’s. We ensure an adequate analysis of need (cf HPT), appropriate attention to design and development, care about the implementation, and ensure evaluation. Used inappropriately, we pay lip service to the stages, doing the same cookie-cutter process we butcher when we do bad ID.
So, to my point: ADDIE’s not broken, but the way it’s used is. It’s supposed to be used as a guide, which is fine. However, it’s being used as a crutch, and that’s wrong. The question is, do we impugn the approach because of it’s implementation, as a way to draw attention to the misuse, or only malign the misuse? I’m not sure the latter’s sufficient, nor the former is fair.
So, I say let the debate rage. We need a resolution, but I fear that there aren’t sufficient resources concerted to a) bring together the necessary conceptual inputs, b) to support the debate, and c) to advocate any outcomes. There are broader issues to be talking about, such as how a design process plays out when we consider not just novices, but practitioners and experts, including performance support and social/informal. We’ve some breakdowns conceptually, and then pragmatically in implementation.
I’ll echo Brent’s call to bring the issue to DevLearn, and see where we get. At least, a lot of us will be there!
For some reason, we increasingly seem to think that to solve a problem we should be able to engage a process, or apply a rule, or make a law. Then we can fix the problem without really having to think (or work) hard. Problems are problems because they’re complex – if the solution is easy, then it’s not really a problem!