Megan Stemm-Wade

Course Development: Is On the Fly Always Bad?

In the world of instructional design, it is a given that a set lead time is necessary for online-course development. With faculty availability, course load, and designer workload in mind, the instructional designer wants to plan up front to make as much time and room for the development process as possible. To nail down course objectives, learning activities that meet those objectives, media assets, and any of the other myriad pieces of course content, an instructional designer generally favors the cushion of perhaps two terms ahead of when the course is to be taught to coordinate with the instructor and the other members of the design team.

On the other hand, “on the fly” course development—that is, building a course as it is being taught, week by week—is a common, if little desired, practice. Instructors have many priorities, including academic travel, which too often trump their commitment to developing new courses. Resourceful instructional designers make a course happen, even when bumping against (and past) deadlines. Designing on the fly can seem like the least-desired way to develop an online course offering, but is it always?

Software development, a field not too far flung from online training and teaching, has recently begun to realize a sea change in the dominant process philosophy: from traditional, upfront “waterfall” process to iterative, adaptive, “agile” methods. Waterfall is a process where the activities flow down an orderly succession of steps, such as:

  1. Concept
  2. Requirements
  3. Architectural design
  4. Detailed design
  5. Coding and development
  6. Testing and implementation

This linear series of steps is in contrast to the “agile” concept of development, where projects are built in iterations, with regular retrospection into the needs of the customer and how the evolving project should adapt to meet them.

iterative design
Image courtesy Kumido Adaptive Strategies

At its core, agile believes that it is impossible to know everything required to build software up front, that the customer can only gain that knowledge from the process itself.1 And so it often is with course development! Until a course is actually taught to students, it can be impossible to determine whether it will meet their learning needs as it is designed. That tool for the synchronous session never worked as it was promised and will need to be abandoned for a better option, or you realized during the quarter that those five-point discussions need to be turned into written assignments.

This isn’t to say that the structure of a course should be changed midstream. The syllabus given to students at the beginning of the offering term is essentially a learning contract and sets an expectation for the learning experience to come. But what if the process of developing the course allowed for a more iterative model? What would a more agile approach to instructional design look like? How could we design learning modules that are highly adaptable and easily changed? Can we embrace the idea that learning materials and programs are not designed, then built, and only then evaluated—let alone that they are produced with the expectation of updates and new versions to be produced? How do we adapt the course-development process to allow for much, much more feedback from the learners and educational stakeholders?

As e-learning becomes online learning and online learning becomes a major component of the educational model, our development techniques and philosophies must also evolve. All development up front is an ideal, but perhaps it is an ideal of the past.

1 Extracted from: Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, James R. Trott – NetObjectives Lean-Agile Series.

4 thoughts on “Course Development: Is On the Fly Always Bad?

  1. This is so true. As an employee of a software company that specifically designs for the academic market, I’ve experienced the overlap between course and software design first-hand. I can tell you that the agile method has by far been our best model. It’s kind of like writing; the more iterations and chances you take to review your work, the better it ends up being in the end. The key: Solid Feedback. Feedback is just as crucial to the design process in software as it is in course design.

  2. I agree that, while instructional design outcomes may benefit from a more formal process with plenty of development time, this is not always possible for instructional designers, let alone teachers tasked with the self-sufficient instructional design projects (e.g. Designing a blended version of an. Existing course on their own).

    I’m actually currently writing a chapter targeted at this latter audience, explaining how ideas from iterative and rapid prototyping process models can be quickly and easily leveraged to improve short lead-time or even on-the-fly design projects.

  3. Luis, thanks for your thoughts. I agree that feedback is key.

    Jared, I’m interested in what you’re writing on this topic. After almost a year since I first touched on it, I’ve seen the benefits of a more formal process and the definite problems with being locked in a more waterfall scheme.

Leave a Reply