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 and therefore 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 to develop software to do xyz. Part of the process isn’t to analyze the needs (needs analysis) but rather to simply develop 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 just thinks up the software and starts developing it. They plan for it and also have to have a business case for it. There’s a lot that goes into software development before a single thing is developed. Agile fits into the software development part of it, 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 by the way 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 of those is instructional design, but rather a small part of the process. Of course, it may or may not be performed by the instructional designer.
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 that it covers and the twelve principles covered below.
You could simply replace the word software with training and it’s as easy as that. Although the process of iteration and such doesn’t apply well all the time to the analysis stage of ADDIE. It’s not to say that you can never go back to analysis or reevaluate what you decided in the beginning, but you wouldn’t do that without a great reason to do so.
It doesn’t make sense to go back through analysis throughout 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 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 a long-long time 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 to 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 whole process. It’s not exactly a framework, process, or anything like that. It’s simply a list of ideas (or a credo) as to how to create an agile environment for software development.
Agile Instructional Design
I couldn’t say this enough. Agile instructional design isn’t a thing and can’t/shouldn’t be a thing.
It’s something somebody made up because they thought agile software development sounded cool and was a popular process for software development, therefore, 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. This one could apply to the entire instructional design process IF training is the right solution. 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 at all, it should be to satisfy 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 also but not so much analysis. The end goal also 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, though. That’s especially true when it comes to custom software training. Because software is typically developed with an agile process, at least some of the instructional design processes must also be agile. That means changing requirements or at least 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 to 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 developing 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 then it’s fair to say you could deliver in a couple of weeks to a couple of 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 after that. You may meet with the subject matter expert (SME) more after kicking things off but in the beginning, 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 a training, qa, or some sort of not production environment to get the job done.
Of course, we understand in general you do want a working environment and support so you can get the job done. That’s a bit different than 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 by “face-to-face conversation” they mean a real person’s voice to another real person’s voice then 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 cavemen 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. I think this one is best applied to the evaluation stage but you could even 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 then you’re going to get more from training, always. That makes this agile principle essential to ADDIE and instructional design. If this was the only principle then I’d say yes, instructional design should be agile instructional design.
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 of those 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 a lot cheaper than how it used to be done.
This one I’d rate 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 it’s 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 very small team, ADDIE, and instructional designers in general definitely 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. How each instructional designer uses ADDIE is slightly different, but overall these steps are always the same.
- 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 type of training, and evaluating the effectiveness of the training.
Some people say ADDIE is rigid and not fit for agile but I disagree. It’s only rigid and doesn’t fit an agile workflow if you look at it in a linear form. ADDIE doesn’t have to be linear, though. It’s quite iterative and can quite easily be agile.
Even the original blocks of each phase of the instructional system design process are somewhat iterative.
Not everyone uses ADDIE by the book, either, which it wasn’t meant to be. Just add a few more arrows that go back at the end of each row and you’ve got 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 changes to shifting training requirements. ADDIE is an established instructional design model that is based on a systematic approach. It encompasses a comprehensive approach to ensure training is effective and efficient.
But why do we even 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 make sure 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 a little more guidance even if it is 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 quickly adapt to changes. 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 just 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 agile by nature (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. Not only that, 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.
But, you must use ADDIE or some equally comprehensive model for designing 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.
My recommendation is to stick with ADDIE because it’s awesome (even SAM doesn’t cut it) and then apply 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 to it. But you can’t practice agile instructional design.
Prove me wrong.
Integrating the ideas of agile into ADDIE can help to create better learning outcomes overall that hit the mark for the business. Just like how 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 to ensure that any changes to the content 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.