If you’re in the learning design business, then you’ve probably come across the term “Agile” recently. You also might have heard terms that sound like a different language, like Kanban or Scrum. All this new terminology can get confusing, so that’s why we’re going to try and make sense of it. For almost 40 years the ADDIE model has reigned as king—the unquestionable framework for learning and development professionals. Now that has finally begun to change.
Agile is a fresh approach to learning design that takes the ADDIE model to a new level. So let’s dive in and learn about Agile Learning Design.
It All Started With a Problem
Agile started as a software development process. It was a reaction to the cumbersome “waterfall” methodology that had been brought over from older manufacturing practices. Early software development companies had no model for their new trade, so they simply borrowed what had been established for years in other industries where products are made.
The problem is that this method is extremely impractical for software development. This is because in order to move to the next stage of development, the stage before it must be 100% complete, perfect, and documented… and that’s just not how software development works. (I’m sure you can already start to see how this applies to learning design).
The Manifesto for Agile Software Development
By the mid-90s, software developers had had enough, and they came up with their own ways of doing things. They created the Scrum and Adaptive Software Development processes along with many others. And in 2001, 17 software developers came together to talk about what they were doing—thus, the Manifesto for Agile Software Development was born.
It defined the Agile development process as an iterative method based on collaboration. Agile would focus on adaptation, evolving development, rapid prototyping, and constant feedback and evaluation.
So What Does This Mean for Me?
I’m sure by now you are eager to find out what this has to do with us, the learning designers. Well I’ll tell you: We are like software developers, our learning solutions are our metaphorical software—and an inflexible approach to ADDIE is our Waterfall.
I will be careful not to make many more comparisons between ADDIE and Waterfall, because while Waterfall was a flawed method from the start, ADDIE has been a successful model for learning designers for years. My point here (the whole reason we are taking time to explain Agile) is that the rigidity of ADDIE is now holding back learning design. It could be costing you time and money, on top of hindering your ability to come to the best learning solution through iterations and refinement.
But let’s make this more real. Here at Bottom-Line Performance we’ve begun to use an Agile learning design process, and we have quite a bit to say about it. As part of this post I interviewed Jennifer Bertram, the Director of Instructional Design at Bottom-Line Performance, and here’s what she said:
What has the switch to an Agile process done for you and BLP’s service teams?
“[Agile] has allowed our teams to collaborate a lot more between Instructional Designers and Multimedia, and I think we’re creating more innovative solutions and focusing less on dry content and info screens. Our clients have also really enjoyed getting to see things that work much earlier in the process. They also like the flexibility and having more opportunities to provide input.”
What has this upgrade from ADDIE helped you do that you couldn’t do before?
“Well I think that we’re still doing all of the steps of ADDIE… but what it has done is it has given us a better way to move through the phases of ADDIE and keep coming back to them again, mainly the first three—Analysis, Design, and Development—because as you’re creating this design proof you’re certainly in design mode, but you’re also already developing a little bit. Then when you’re thinking about development, when we’re getting to Alpha, we’re already going back and redesigning things.
This way we’re just planning for it so it doesn’t cause so much frustration and anxiety, on both sides really, for the client— if we say “oh, well you didn’t tell us that back then,” but now we’re having a lot more conversations with them about the design—and then for the development side as well.”
What’s something new about Agile that you like?
“More client interactions and more iterations. So now we’re not going away and creating something and saying “what do you think?”—we’re saying together what our ideas are. So we’re getting solutions that our clients are happy with, and we have a more solid foundation early in the process.”
Don’t worry, there’s more! We continue this interview here: Agile vs ADDIE: Which Is Better for Learning Design?
So What Is Agile; What’s the Process?
By now we’ve defined Agile learning design as an extremely iterative process. Through the use of collaborative teams—client collaboration included—and constant iterations/feedback, you end up with a faster and more flexible process. But this is still a fairly vague description of Agile, only accounting for the big picture. How does an Agile process actually work? Where does it even differ from ADDIE? Take a look at this flowchart and see for yourself:
Well there you have it, Agile learning design in a nutshell. Something that started with a bunch of software designers coming together to shoot down Waterfall Methodology became the secret to more efficient (and innovative) learning design. Stay tuned for next week’s post on Agile vs ADDIE where we’ll further break down the differences between the two processes and show you when it makes sense to be more Agile.
Interested in learning more about agile learning design? Watch our webinar: Agile Learning Design: A Practical Perspective.
but don’t we do this already with constant formative evaluation (you know…the E in ADDIE?). certainly, i have participated in similar processes during my ID career, most of which was short-term contracts where clients needed to know and (hopefully) understand the design and development process as it unfolded in front of the.
i know a little bit about the agile software development process, having been a system administrator and former programmer myself prior to moving into the training and development field. the key aspect of Agile programming is collaboration — typically pairs of programmers that solve a problem either in part or the whole of any software development project. literally, that is the whole point of agile where the buddy system is at work to support through the entire software dev cycle. checks and balances occur during the programming by these small encapsulated teams prior to getting comments from the project manager (who may oversee more than one buddy team as an aspect of the complexity of the software).
i think the chart at the end is overreaching. ADDIE works just fine and other than checking in with clients (presumably for approval of different milestones of a project), i don’t see the Agile aspect truly coming into play. as matter of fact, agile with ADDIE seems like wordplay and nothing more.
sorry, bro.
@Jake: Very interesting, as I’ve been keeping an eye on using SCRUM for a long time now… But I have a few questions, which you may reply that they’ll be covered in future posts… 🙂
First, the Agile Learning Process you described, does the Goldmaster include ALL content of a learning project, like a course, or a part of it? The latter would be in line with the software analogy (portion of the backlog).
Second, how do you budget/sell this to the client? Some (probably a lot) would argue that there is too much uncertainty, not knowing how much in the end a project will cost…
@Manny: I think it’s about having a series of ADDIE cycles, instead of one big one, to make sure you get not only want you need in the end (especially in large projects), but also the best you can get: you can never, never fully know everything at the beginning. So no, I for one don’t think it’s just wordplay.
Sorry bro 😉
Hi David,
Greetings from BLP’s prez! Great questions. I’ll try to deliver some answers but some of them are going to be the wonderful, “It depends.” FYI – when we say “agile,” we aren’t trying to be exactly like a SCRUM process. SCRUM is all about product development – with new versions pushed out LIVE to users as you iterate. Agile is still a development process (in our eyes) where the final piece doesn’t go out to the large population of users until the client says, “It’s finished.”
1) For us, Gold Master does include all the content. This still equates to the final deliverab.e
2) We budget by agreeing to a specific # of iterations. What’s really different for us between Agile and ADDIe is what we’re walking INTO the initial design meeting with (a straw model of objectives that have been drafted based on a pre-meeting with stakeholders) and what we walk OUT of meeting with – preliminary prototypes that are functional in nature. They show what learner will DO and describe what content will be part of them. If you really have NO IDEA what you are going to build, then obviously you cannot budget. So – we have some concept of parameters – complexity, size.
3) Re: your comment about it “being a series of ADDIE cycles,” it sort of is…and it sort of isn’t. In ADDIE, you often produce a “design document” at the end of the design phase. For us, we are producing “functional prototypes” that actually mimic the functionality the user will encounter. This is totally different than what we produced in more traditional ADDIE model. It is different from what Dick and Carey described in their book on ADDIE process. Stuff works and the client can see it working. What ISN’T there are pretty pictures or beautiful UI designs. That comes later – after client agrees on functionality.
We’re stil piloting agile at BLP – and the jury is out though our clients are giving us lots of positive feedback on it so far. They feel like they get farther faster – and they know exactly what they are getting sooner. Problems get identified faster, too. When we show a functional prototype to a client and they say, “Oh, I didn’t know it would work like that,” our hearts don’t sink because we haven’t spent 40 hours programming it and making it look beautiful.
In closing, don’t think of agile as equal to SCRUM. It’s not. We ARE using a SCRUM model for product development – but that is a different animal entirely.
As I am reading about SAM, it seems that it is a fuller description of the ADDIE process, as it too is cyclical and goes through many iterations. Having developed training for the past 15 years, I have yet to see design happen in a totally linear process. I suspect that SAM may be the flavor of the month, as some want to create something “new” that isn’t really new.
I’ve always known course development to be an iterative process even before Agile was widely discussed. I think the principles of agile like collaboration, customer involvement, continuously challenging assumptions and looking for ways to innovate have always been a part of my own experience. I have only ever developed training for new and emerging technologies, some of which are developed using Agile so it’s a natural fit for me. Some people however, based on my experience, are rather insistent that course design and development be linear and that the process be executed like a relay race where the baton is handed from one to the next step in the process. Of course, none of those people actually ever had responsibility for producing a course, they were just process wonks. I’m not saying that the process cannot be linear, I’m just saying that if your goal is to deliver a course on time and to the satisfaction of your customer, the principles of Agile are useful even if it’s not called Agile.
“Waterfall was a flawed method from the start.” you say. Was it? Even nowadays, many Projects are successfully planned and put to work using waterfall Project planning methods. It is not the method of choice when developing SW in a quickly changing Environment for customers that will want the next Feature before you even know how to design the last one.
Same goes for ADDIES “vs.” Agile Learning: Both have their merits, both have their flaws. The better you understand both, the better you can choose the right Approach to the challenge infront of you.
Thanks for shedding light on the new possibilities, and for sharing with the General public!
Hey Jake,
Thanks for putting together this post on Agile Software designe. it is a great read. I particularly find your thoughts about the manifesto for Agile Software Development interesting .Keep up these insightful posts.
Cheers!