If you’ve worked in the eLearning industry for a while, it’s likely you’ve recently (or not that recently) heard the buzzword “agile,” possibly in combination with other words like “process,” “production methodology,” and so on. We’ve heard it too, I’d like to share our story, perspective, and conclusions about what agile eLearning development means for SweetRush.
As a company that values continuous improvement and raising the bar on our craft, we feel constant pressure to do things faster, better, and more efficiently. In the past few years, every time we discussed these topics, someone would inevitably say, “What if we were more agile? Maybe that would solve our problems.” In these situations, I couldn’t help but wonder, is agile really the magic pill the learning and development industry has been waiting for?
With this and many other questions in mind, we decided last year to have “that agile conversation.” This is what we found.
Our industry has traditionally used the ADDIE model for creation and delivery of instructional design (including eLearning development). If you’re not familiar, ADDIE stands for Analysis, Design, Development, Implementation and Evaluation and it has (again, traditionally) been a linear model. For years, everyone felt comfortable with ADDIE. But with time, its weaknesses started to become more and more evident: it takes quite some time to “really see” something, it does not accommodate spin-offs or variations well, and sometimes it can inhibit creativity once the storyboard is done.
We put together a multidisciplinary group and charged it with the task of remapping our production process to make it more agile. But once we started, we realized that we needed to ask ourselves, what does “agile eLearning development” really mean for us?
As we started sharing our experiences in the group, we learned that every client that had specifically asked for a project to be managed in an “agile” way had a different understanding of what that meant and that we all had our own ideas about it too.
So we had to go back to the books and find the definition of “agile” that we all could use and apply to eLearning development.
We learned that because the ADDIE and waterfall models are linear, the most common mistake people make is to assume that any iterative model is “agile” by definition.
An iterative model is a lot more flexible than linear models, but to be agile (in the strict use of the term), being iterative is not enough; it needs to follow the principles of agile software development. Personally I really like the following three concepts I invite you to read them all at agilemanifesto.org.
“Simplicity—the art of maximizing the amount of work not done—is essential.”
“Individuals and interactions over processes and tools.”
“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”
Besides studying the SAM, Lean, and Scrum models, we also decided to talk to our contacts who have experience in implementing these processes. Coworkers, clients, and partners were more than happy to share their experiences with agile eLearning development.
When we asked about the benefits of implementing agile for their teams, we started to see some patterns. Everyone talked about:
- More motivated teams
- Better relationship with stakeholders
- More communication at the beginning that led to less feedback later
- Higher-quality products
Interestingly enough, almost no one mentioned shorter timelines, profitability, or efficiency as being the main takeaways of the agile production process.
With that information, we decided to compare the strengths and weaknesses of our own process against the benefits of switching completely to agile.
After a thorough analysis, we concluded that we already had some of the strengths agile would provide: we already had a highly motivated team, and the industry has recognized the quality of our eLearning development work with several awards.
We also identified that not all projects are a good fit for agile. Linear processes are still relevant and a good choice for some projects and clients.
As I said, we are always looking to improve, which means challenging long-standing assumptions and not being afraid to experiment to push to the next level. However, we also recognize we need to do so in ways that enhance our relationships with our clients and partners.
So the question remained: What should we do?
We decided that it would be a mistake to switch completely to a new production process that would not be a good fit for every project. But we also saw that it would be a mistake to ignore the good ideas the agile methodology has to offer.
With this guiding philosophy, we’ve made several exciting improvements to our process over the last year that embrace agile eLearning development:
- We embrace and support early collaboration between different stakeholders and team members.
- We are ready and able to create prototypes, wireframes, and proposals as part of the initial stages of the project.
- We are well prepared to take on projects that should be developed using the full agile methodology.
Also, as a result of these discussions, we found and applied a lot of refinements that have improved the efficiency of our existing process.
What’s next?
This experience brought into focus our strong commitment to continuous improvement at SweetRush. Taking it a step further, it’s helped us map out a process and a multidisciplinary approach to continuous improvement that we can apply to aspects of our craft, such as embracing industry trends, remaining competitive, and making sure that our clients and partners feel good—and that we feel good—about the services we offer.
