Okay, maybe the title of this article is a bit extravagant and not entirely honest.
Why do I say that?
Because comparing agile software development to instructional design is the wrong comparison. Not only that, but trying to unite them isn’t always productive either. They work together well, but agile isn’t a framework, so it’s wrong to call it agile instructional design. It’s instructional design, but you could use an agile mindset in your process using a real instructional design framework like ADDIE.
That’s why uniting them is perfect, but it’s not agile instructional design.
With software development, the solution is already determined to be developing software to do xyz. Part of the process isn’t to analyze the needs (needs analysis) but rather to build software. Instructional design goes beyond that because analysis is always a requirement to some degree (even if analysis doesn’t tell us everything).
Software development doesn’t have anything similar except perhaps the project manager who oversees the whole process. So, an instructional designer is to training design as a project manager is to software development.
Nobody in a business thinks up the software and starts developing it. They plan for it and must have a business case for it. A lot goes into software development before a single thing is developed. Agile fits into the software development part, not the entire process.
The project manager oversees and manages the agile process in software development.
Guess what?
An instructional designer could oversee the agile process in training design.
That silly thing we call ADDIE, which is anything but silly, is a comprehensive process that goes beyond what could be agile in the instructional design process. Without the initial phase of ADDIE, analysis, you’re liable to end up with a course for every problem.
Agile isn’t exactly useless in the scheme of the entire instructional design process, though. It can be extremely powerful when combined with a solid instructional design process framework.
Is an eLearning course the answer to the goals of the organization?
Then you might be in luck! Agile is a perfect combination for custom eLearning development and probably training videos, too. Neither is instructional design, but rather a small part of the process. Of course, the instructional designer may or may not perform it.
One question always remains in instructional design as we’re pulled in one direction or another. How do you create effective training that effectively meets the needs of employees while also being able to adapt to the changing needs of the modern workplace quickly?
This post will help you apply an agile process similar to agile software development so it makes sense in the instructional design process.
What is Agile?
Agile began with a mission to “uncover better ways of developing software,” according to the Agile Manifesto. Everything is relatively generic in the terms it covers and the twelve principles below.
You could replace the word software with training, and it’s as easy as that. However, iteration and such don’t always apply well to the analysis stage of ADDIE. It’s not to say that you can never go back to analysis or reevaluate what you decided initially, but you wouldn’t do that without a great reason.
It doesn’t make sense to go back through analysis again in the instructional systems design process just because. There’s got to be a reason!
Agile is an idea and way to work, not a process or framework.
But that’s okay; not every part of instructional design can or should be agile.
Let me familiarize you with agile software development first, and then I’ll get into how it might apply in the instructional design world. Those will be broken down into each principle and what it might mean to instructional design.
We won’t call it agile instructional design, though. That term is deceptive and shouldn’t be used.
Agile Software Development
The manifesto for agile software development was created by a group of software developers long ago (but not in a galaxy far-far away).
There are twelve principles of agile software, which is exactly what would apply to the instructional design process in bits and pieces. So you’re familiar with those twelve principles, here they are.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
That’s it!
That’s what makes up the core of agile software development. It guides how things are done and how to iterate throughout the process. It’s not exactly a framework, process, or anything like that. It’s simply a list of ideas (or a credo) for creating an agile software development environment.
Agile Instructional Design
I couldn’t say this enough. Agile instructional design isn’t a thing and can’t/shouldn’t be.
It’s something somebody made up because they thought agile software development sounded cool and was a popular process for software development; therefore, it would be a good process for instructional design. Oops, it’s not. It’s just another buzzword that doesn’t fit and is somewhat meaningless.
But there’s no reason you can’t apply some of the principles of agile software development to some parts of instructional design. Just never forget that it doesn’t make it agile instructional design.
Let’s start by breaking down each principle.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Replace software with training, and you’re set. If training is the right solution, this could apply to the entire instructional design process. Part of the needs analysis may uncover that training is a horrible solution to the business problem, though.
If training isn’t the answer, then the priority should not be to satisfy the customer but to fulfill the business need. That business need may not be to deliver training.
So, again, this could only apply to the DDIE and never to the A in ADDIE.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This is a biggie for agile and a good one to apply to DDIE, but not so much analysis. The end goal shouldn’t necessarily be to deliver the customer’s competitive advantage because sometimes the customer isn’t what brings competitiveness but rather the business goal. Sometimes they’re the same, but not always. Never assume the customer always has the best interest of the business goal at heart.
It’s hard to say that instructional designers shouldn’t welcome changing requirements. That’s especially true when it comes to custom software training. Because software is typically developed with an agile process, some instructional design processes must also be agile. That means changing requirements or how it’s developed even late in the process.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
This one may be a bit more difficult, depending on how the training is being developed. I wouldn’t call a storyboard working software, but sometimes, in instructional design, this is better than going too far with something working, unlike in software development.
ADDIE has the design phase specifically because training is a different beast than software. You must plan and build that framework before developing something that works too much. But, once you’re creating a working course, video, or whatever, then ya, go all in with frequent updates and perhaps build a simple prototype first.
Just don’t build that prototype before doing any planning. If you’re applying agile to ADDIE, it’s fair to say you could deliver in a few weeks or months.
Business people and developers must work together daily throughout the project.
This one can’t be argued with at all. At every step of the ADDIE process, you must work with business people (aka project stakeholders or owners). Your first meetings will be with the business owners, and regular meetings will follow. You may meet with the subject matter expert (SME) more after kicking things off, but initially, it’s all about the business people.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
We at techstructional come from the world of designing software training. That means we could not resonate more with “the environment and support they need,” but we, of course, take it much more literally. We just need training, QA, or any non-production environment to get the job done.
Of course, we understand that you generally want a working environment and support so you can get the job done. That’s slightly different from our first thought of the software environment, but we’ll let that go. This one, of course, applies to everything instructional design.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
If “face-to-face conversation” means a real person’s voice to another person’s, we’re all for this! It shouldn’t ever mean literally face-to-face, though. Any job that can be remote should be remote, including instructional design. We’re not living in archaic Neanderthal times, for goodness sake.
But yes, it’s always best to communicate synchronously rather than asynchronously, where information gets lost and miscommunication happens. This one has another slam dunk application to the ADDIE process. No complaints.
Working software is the primary measure of progress.
This is another one where you can replace software with training, and you’re set. If the training works, then progress is made. If you can continuously improve the training and get better results through the evaluation process, then all the better. This one is best applied to the evaluation stage, but you could use it on small groups in the development stage if necessary.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This is another one that could be applied to the whole ADDIE process for instructional designers. We’d just like to add good luck making sure subject matter experts (SMEs) stay on the same pace indefinitely. Sponsors would like that, but it likely won’t happen unless you have magical powers.
Continuous attention to technical excellence and good design enhances agility.
I’m not sure how this one would apply in the world of instructional design at all. Good design does enhance quality for both, but continuous attention to technical excellence is a little more iffy. I’m not sure that one applies at all.
Simplicity–the art of maximizing the amount of work not done–is essential.
Every single part of this principle is 100% instructional design and the ADDIE process. The problem is when you skip a proper design process and jump right to development. That’s where this one is typically lost.
As we always say, nothing is important if everything is important.
If you stick to the ADDIE process, you’ll always get more from training. That makes this agile principle essential to ADDIE and instructional design. If this were the only principle, I’d say yes, instructional design should be agile.
The best architectures, requirements, and designs emerge from self-organizing teams.
In the world of how instructional design is performed in most companies, this doesn’t always apply. Instructional design used to require a team with everybody chipping in with their specialties. There used to be software developers, graphics designers, voiceover, etc. Some still exist and work with instructional designers, but not often in companies anymore.
So, it’s not typically a matter of self-organizing teams any longer. The world of instructional design is sometimes just the ID, business partner, SME, and rapid development tool. It gets lonely out there sometimes, but it’s much cheaper than it used to be.
I’d rate this one as only applicable to instructional design or ADDIE in some organizations.
Last but not least…
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This one is not least because it’s one of the most essential for instructional designers. The ADDIE process is not a waterfall model and is not linear. At its core, ADDIE is iterative, which is what agile is at its core.
So, even if there is no team or a small team, ADDIE and instructional designers should abide by this agile principle.
What is ADDIE?
If you want to learn more about ADDIE and how we use it, check out the introduction to our ADDIE process. The instructional designer’s use of ADDIE is slightly different, but these steps are always the same overall.
- A: Analyze
- D: Design
- D: Development
- I: Implement
- E: Evaluation
Those are the five stages of instructional design using the ADDIE model. It has been around since 1975 when an early predecessor of ADDIE was developed at Florida State University based on a process that has roots coming from World War 2.
The model outlines the systematic process of gathering and analyzing needs and requirements, designing the learning objectives and overall framework for the type of training, developing and validating the instructional materials, implementing it, which looks different for every kind of training, and evaluating the effectiveness of the training.
Some people say ADDIE is rigid and unsuitable for agile, but I disagree. It’s only rigid and doesn’t fit an agile workflow if you look at it linearly. ADDIE doesn’t have to be linear, though. It’s quite iterative and can quite easily be agile.
Even the original blocks of each instructional system design process phase are somewhat iterative.
Not everyone uses ADDIE by the book, which it wasn’t meant to be. Add a few more arrows that go back at the end of each row, and you have a pretty agile process.
But what about if you unite Agile and ADDIE? Does it work?
Of course it works. You can approach some of the ADDIE processes using the agile principles. But what are the benefits of uniting the two?
Benefits of Uniting the Two
Uniting agile with instructional design doesn’t work; there’s not enough of an actual framework built into agile. It’s just a bunch of lofty ideals, which is great, but it won’t work as an instructional design framework because of the sciency nature of ID. But it will work if you combine an agile mindset with the ADDIE process!
While ADDIE brings the necessary structure to training projects, agile gives it the iterative and continuous improvement mindset required. That is if you’re giving the time, money, and resources to do that, which I suspect is a different battle.
Combining the two allows instructional designers to quickly adapt to changing training requirements. ADDIE is an established instructional design model based on a systematic approach. It encompasses a comprehensive approach to ensure training is effective and efficient.
But why do we need to add agile if ADDIE is so wonderful?
Combining these two approaches can bring tremendous benefits to any training project. For example, by taking a step back to analysis in an instructional design project, you can ensure that you are creating an effective learning experience. By embracing agile, you can ensure that any changes needed in the project are quickly implemented.
But that was already part of your process with our without agile, right?
I hope so, but it couldn’t hurt to have more guidance, even if it’s because of a buzzword. That’s because you can never go wrong in encouraging more collaboration and communication, which is essential to instructional designers.
Having an agile mindset and process will always add to a strong instructional design framework.
An agile approach to instructional design and ADDIE can provide the mechanism to ensure that the project is up-to-date and flexible for any changes needed. ADDIE can provide the structure and comprehensive view to ensure quality learning outcomes.
By uniting the process of ADDIE with ideas of agile, you can benefit from a comprehensive and flexible process for instructional design while increasing collaboration and communication. You’ll also have the ability to adapt to changes quickly. This unified approach is essential to creating powerful learning outcomes.
Just don’t try to say your process or model of instructional design is agile or agile instructional design. That isn’t a thing, shouldn’t be a thing, and isn’t a comprehensive enough model to create quality training that’s backed by science and a process that works consistently.
Instructional design is naturally agile (or should be), so there’s no need to call it agile instructional design.
How To Combine Agile With ADDIE
This one is pretty simple. There’s no reason you can’t apply all the ideals of agile software development to ADDIE. Also, agile software development doesn’t have to be for software development at all. It’s perfectly suited for pretty much anything and can be applied seamlessly to any process for doing any type of work.
Agile complements ADDIE, it doesn’t replace it.
However, you must use ADDIE or some equally comprehensive model to design quality training. You can’t just use agile and say that’s your process (or even say you use an agile process). It’s not a process, and it won’t work.
I recommend sticking with ADDIE because it’s awesome (even SAM doesn’t cut it), then applying the agile manifesto principles where it makes sense. Agile complements ADDIE; it doesn’t replace it.
Wrap Up
Phew!
We covered a lot of ground and put to rest the myth of an agile instructional design model. It doesn’t exist. You can use an instructional design model (like ADDIE, yay!) and apply agile principles. But you can’t practice agile instructional design.
Prove me wrong.
Integrating agile ideas into ADDIE can help create better learning outcomes that hit the business’s mark. Like most people practice ADDIE today, using an agile mindset allows for rapid feedback loops and continuous improvement.
By uniting the mindset of agile software development with the ADDIE framework, organizations can develop efficient and effective training content while still ensuring that they have the right solution that evolves with the needs of the business.
Approaching instructional design with an agile mindset also helps ensure that any content changes can be identified and addressed quickly. This helps to reduce the need for costly rework and can improve the overall learning experience.
If you have a project you need some help achieving an agile mindset with, our instructional design consultants are always available. Or, if you’d rather, schedule a free consultation to discuss how we can help your business and next project.