5 Misconceptions Instructional Designers Make About Agile Workflows

5 Misconceptions Instructional Designers Make About Agile Workflows

We have all at least heard of Agile methodologies. Despite being around for years, Agile is still sometimes touted as “the next big thing.” This popularity has led to multiple interpretations and misconceptions about what Agile actually is, though.

In today’s blog, we will explore five common misconceptions about Agile workflows, while asking how we can make the most of its principles.

1. A Sprint lasts two weeks

Instructional Design often means working on longer projects with many moving parts. A Sprint allows us to focus on a smaller task or goal within that project. We might say, “During this Sprint, we will write the first draft of the storyboard.” or “During this Sprint, we will implement our findings from our usability testing.”

Sprints help us recognize the amount of progress we are making, while providing a chance to regularly review the overall project, which allows us to pivot if we need to. With Sprints, we develop regular items of value to share with our stakeholders for their review, ensuring that everyone is on the same page.


Sprints last a set amount of time, and the common belief seems to be that they should always be two weeks. This misunderstanding may stem from two weeks often being used as an example when we train or introduce Agile to new audiences.

In truth, while Sprints should last a consistent length of time to form a rhythm and flow, it doesn’t have to be two weeks. We might find that two weeks is too long or too short for our team, our project, or our stakeholders. Maybe our Sprint length for this project is three weeks? Maybe it’s one? We can experiment and find the right fit for us.

2. Agile is always better than the Waterfall approach


The Waterfall method is seen as a stricter, more linear, and less flexible form of project management where each stage is fully completed before moving on to the next. It is commonly viewed as presenting barriers and pockets of “dead time” as one party must stop and wait for another.

In truth, Waterfall is just as valid as Agile. Let’s assume the project is artwork for a comic page. The artist pencils the page, then it goes to the inker, and finally the colorist. Without pencils, there’s nothing to ink. Without inks, the page is not ready to be colored. In this instance, a Waterfall approach can be suitable.

We select our methodologies based on the needs of the project and business, not our personal preferences. We might even mix and match our approaches in some cases. Do what’s right for our task, rather than assuming we must use the same techniques every time.

3. Agile means diving straight into development

There are assumptions that Agile solely means that we learn by doing. That we start by rapidly iterating on low-fidelity prototypes. If we do this without conducting a root cause analysis or developing end user personas , then we are likely to fall into assumptive design patterns, crafting a solution that is ultimately ineffective.

Agile can actually have more documentation than other approaches. Our first Sprints will likely include that root cause analysis. Our Sprint reviews and Sprint plans provide an opportunity to hit pause, assess how the project is going, and pivot if needed. Those reviews are documented and happen more often than they might with other methodologies.

While we focus on our tasks for the current Sprint, our Product Manager prepares for the next Sprint, allowing us to work in parallel and move seamlessly from one Sprint to the next. The Project Manager’s actions will also generate documentation.

Agile can be efficient and collaborative. Its results can reach early stages of development sooner by dedicating time to understanding the problem and audience, offering more reviews at earlier stages, and involving key stakeholders more often. Agile does not skip these important key stages.

4. Agile is only used for digital design


When people think of Agile, they often think about digital outputs. Software Engineering, Game Development, and Instructional Design come to mind. We might assume that it is only used by professionals in those industries.

Agile is designed to be used across a variety of industries for a wide variety of projects. Agile can be implemented into city planning, customer experience, zookeeping, or pretty much any role or task that you can imagine.

Let’s take the zookeeping example and investigate it further. You might be participating in a breeding program. You may have a selection of potential mates with different bloodlines, ages, and personalities to consider. You might have to regularly review a pair’s compatibility, potentially trying different bonding techniques or even changing partners. Agile frameworks could provide a great way to review progress, assess key success indicators, and identify changes we need to consider.

Agile is much more flexible than we give it credit for. By changing our mindset, we can make it seem less scary to our stakeholders and business partners.

5. Agile is just another buzzword

The zeitgeist and language of design is constantly evolving. There’s always a hot new thing that’s everyone is clamoring over. It can be easy for us to write off Agile as being just another fad.

Agile has been around for more than 20 years. Its persistent popularity over those two decades speaks to its value and effectiveness. It also suggests that Agile is here to stay.
Over that time, many people have interpreted, represented, and communicated Agile in different ways. In some cases, people have over-simplified, watered down, or misrepresented Agile, and that can cause us to misunderstand it or apply it incorrectly. In those cases, we might not see the desired results or benefits, and we may write Agile off as being just another buzzword.

We can best take advantage of Agile by applying its core loop of discover, develop, and test on small, focused portions of projects at regular intervals. This process allows us to identify what is, and isn’t, working earlier in development. It can help us adjust our approach, which can lead to better outcomes. We must keep an open mind, which might mean adjusting Agile to suit our team, our business, or our users.

In summary

While there are a lot of different interpretations and applications of Agile, the underlying principles can provide huge advantages. Experiment with it, play, and adapt it as necessary. Remain open to combining it with other methodologies and accept that Agile is not a silver bullet or cure-all. Like everything else at our disposal, Agile is a tool that we can use, and only a bad workman blames their tools.

You can find more blogs on our website, https://www.pulselearning.com. If you have an upcoming Learning and Development project, and you would like to partner with an industry leader with over 20 years’ experience, book a call with us today!

Skip to content