Why Working Iteratively Works for Me (And How It Can for You, Too)

How can an Iterative Approach improve the online course development process?

Have you ever tried to train your brain and break yourself out of a bad habit? We’ve all got one (or some). But as anyone who’s tried to cold turkey biting their nails or finally respond to their (dozens? hundreds?) of emails knows, sometimes phasing out a bad habit means establishing a good one in its place. And as it turns out, making good habits can be just as difficult as breaking bad ones. Since this is an educational site chock full of tips and tricks to better your online course, the good habit I’ve been training my brain in, and the one I want to share with you here, is a huge game-changer for course development strategies (more on that to come): working iteratively.

Working iteratively involves successive refinement, aka processing separate pieces (or chunks, as I like to call them) over and over again with varying degrees of increasing detail until that specific portion is complete. And this method does not come naturally to me at all.


What does come naturally, and the habit I’m trying to replace working iteratively with, is what’s known as the Waterfall Method. The Waterfall Method is one of the most common approaches to project work, and is undoubtedly one you’ve come across before. It involves a linear project approach that advances phase by phase.

So, if working in phases is my default way of thinking, why bother switching things up? And why’s it worth all this cerebral effort to retrain my brain? Because the courses I apply an iterative approach to are more successful than the ones I don’t.


When work is organized into phases, only the tools, people, and processes applicable to that specific, particular phase get tested. One of the most frustrating situations I’ve repeatedly encountered when not working iteratively (that is, when I stick to the Waterfall Method) is learning something in a subsequent phase that invalidates a decision I made in an earlier phase. Not just an annoying occurrence typical of the more inflexible Waterfall Method, but one that can have a significant impact on the project as a whole, often either leading to rework of an earlier phase or the development of a weird and oftentimes awkward workaround. Neither of these is great for any project. Rework messes up the schedule and feels like a punch to the gut. (I mean, who really loves repeating steps they already completed?) And workarounds lead to maintenance issues and/or lousy student experiences.


Though the two issues presented above are my most frequently encountered, here are some other things that’ve gone wrong when I failed to work iteratively:

  • A tool we assumed would work for our use case didn’t, well, work

  • A resource we thought we could purchase cheaply turned out to be expensive

  • A team member we thought would be capable of a certain step lacked the skills

  • A process we intended to reuse from a previous project had to be adjusted for the new project

  • A step we assumed would take an hour each time ended up taking four hours

Over time, a pretty clear pattern (and a pretty strong case) has appeared for working iteratively vs. working more linearly.


How I’ve Begun to Build My Courses Iteratively


Throughout my research, I’ve learned that the concept of an iterative approach is well-known in the software development world, but it absolutely applies to building an online course as well. Here are some of the steps I’ve taken to build an online course iteratively.


Organize the Project into Meaningful Chunks


The goal is to organize the project into pieces that can be built incrementally. To do this, I first had to determine how to break my projects into “chunks” that could be delivered independently of each other. In most courses, a single module (or a single lesson) makes a natural chunk. A prospective student will understand that if they are viewing a completed version of Module 3, similar modules will come before and after in the final product.


The chunk that should be built first is one that is representative of the large majority of the course.



If a particular chunk is much simpler than the rest, it won’t be a thorough test of all the components that will be used in building the course. If a chunk is overly specialized and requires many components, while I’ve found it very helpful to build that chunk as soon as possible to avoid surprises, it may not be the best choice for the first chunk. The perfect chunk for this step is one that falls in the middle of the two extremes.


Lastly, it’s important to note that a chunk is a poor choice if it is difficult to see how it will fit in the final product or if it is not representative of other chunks.


Build the First Chunk from Start to Finish


After organizing my project into its meaningful chunks, I then build the selected chunk through all the steps into its final delivery format. All of the components intended to appear in the final course should be built for the selected chunk. This may include interactive elements, video, audio, quizzes, handouts, discussion boards, LMS settings, etc. I always build the chunk in the same format that the whole course will be built in.


In my experience this is by far the longest and most complex step, one reason being that building a complete chunk isn’t a solo endeavor. Every member of the course development team should be involved. But don’t be daunted by getting the whole team involved so quickly, because this step presents a fantastic opportunity for tests. Some of your course’s components that can be tested during this portion include:

  • Whether each person understands their role in the project

  • Whether existing communication channels and standards will be sufficient

  • The order in which things are built and what items are dependent on each other

  • All of the tools involved

  • Procedural mistakes

I’ve found this process is an excellent way to reflect on what is going well and where improvements need to be made.


Don’t be afraid to change the process. It's still early in the project, which is the whole point of working iteratively!


Get Feedback on the First Chunk


So far only one chunk of the course has been built. Any insights gained and any large-scale changes that arose (and you know there will inevitably be some) only need to be applied to a small percentage of the overall course. Were I to have found out about any of these changes later in the course (something likely to have happened with a Waterfall Method approach), the chances of encountering the list of issues I’ve encountered outlined above would have increased exponentially.


Thus, once I’ve facilitated one chunk of the project all the way through the pipeline, I’ve come upon the best possible time for feedback. I’m most interested in getting feedback directly from students, since they’re the ones I’m building a course for. Their opinion matters the most.

When asking for feedback, my goal is always to give open-ended but guided prompts so that I don’t end up with unactionable feedback such as “I like it” or “I was confused.”


Here are some examples of guided prompts I’ve found most effective when asking for feedback:

  • I would like this course a lot better if __________.

  • I was disappointed to see that __________.

  • I found it confusing when __________.

  • I’d like to see more of __________.

  • My favorite part was __________.

Unfortunately, it is sometimes difficult to get feedback directly from students. (This may be especially true if a person has few connections to the target student group or if the course will be used in an environment such as academia where feedback is not commonly part of the teacher/student dynamic.)


If it’s not possible to talk with current and future students, the next best option I turn to is other invested parties who understand the goals of the course and the needs of the students. This could include former students, the sales and marketing department, subject matter experts, or others who were not directly part of the course development team.


Update Your Chunk, Build Some More Chunks, and Keep the Feedback Coming (In Chunks)


Once I’ve gotten feedback on the first chunk of the project, I can update that chunk where needed and my subsequent chunks can be built. Ideally, these would also be released to the target audience as they are completed instead of in one giant lump at the end, so that feedback can be collected and applied continuously (and any glaring oversights caught quickly and early on).