And wouldn’t it be great if an apple tree in your backyard got mutated by experimental gamma rays, and now instead of producing apples, it produces crisp $20 bills?
Unfortunately, linear and completely predictable project development is only slightly more likely than the existence of that money tree—learning project managers need to be able to adapt to on-the-fly changes and use a nonlinear process for the sake of efficiency. They need to be iterative, and they need to be agile.
Waterfall is a traditional project management methodology that aligns closely with ADDIE. Both are fundamentally linear in their approach, and both are highly rational, perfectly reasonable, and often unrealistic.
Few L&D projects play out in true Waterfall style, even those that are designed to. It’s more likely that when we create a strategy based on the Waterfall methodology, we realize that part of our job will be to manage the many gaps and changes in direction that will occur along the way. This more reactionary, flexible approach to project management approximates the Agile methodology. Instead of plotting out a perfect path, the Agile approach begins a project with comparatively few facts finalized and takes for granted that every project decision is up for reconsideration and refactoring at any time. In this way, Agile embraces ambiguity as a central theme... and it works. This approach has proven to be capable of maintaining exceptional efficiency, while at the same time allowing greater creative freedom throughout the development lifecycle.Because Agile is not a clearly defined, linear process, it can itself be difficult to define. Ultimately, it is less a process than a collection of 12 guiding principles.
Reading through the principles, five fundamental themes arise: flexibility, efficiency, simplicity, trust, and collaboration. The goal of these principles is to create a methodology that is open-ended enough to encourage free thought, but still simple enough to streamline production. This potential dichotomy requires a great deal of trust and collaboration. Instead of a team being bound together by red tape, this approach fosters a team environment that is united instead with a sense of interdependence and shared responsibility.
These 12 principles can and are applied in a variety of different ways to serve a variety of different management strategies. The most popular Agile-based strategy is known as Scrum, which centers on a series of iterative, piecemeal development cycles known as “sprints.” Streamlined teams take responsibility for various sprints with a focus on maximizing collaboration and minimizing overlap, and frequent meetings are held to manage and mediate conversation on all aspects of project progress. Goals for each sprint are made as explicit and distinct as possible, and the responsibilities for each team member are thoroughly defined, keeping in mind that these requirements and responsibilities can and probably will change many times along the way.
An individual Scrum sprint is similar to a miniature Waterfall cycle. Therefore, in a broader context, iterative Scrum can take on a framework that looks a good bit like a modified ADDIE model.
4 Considerations for Agile ADDIE
There is great potential for an Agile ADDIE methodology, but there are limitations to that potential. While some formal models for Agile ID have been developed, perhaps most notably SAM, the Successive Approximation Model, many organizations may not be willing, ready, or interested in a complete change from their existing development models and methodologies.
The traditional Agile model is generally best suited to managing a single deliverable, whether an eLearning module, a collection of modules, or an instructor-led training course of any duration. Once the deliverable reaches a program level—for example where a collection of assets are to be developed—it would be harder and potentially impossible to manage this work from an Agile perspective.
With that in mind, here are some things to keep in mind in order to make your next instructional design project a little more Agile.
1. Agile is designed to manage a single deliverable.
While a complex deliverable is possible if the project requires the development of multiple deliverables or varied media, Agile may not be the best solution. Some interdependency and overlap is manageable, but there comes a point where the complexity of managing those interrelationships outweighs the benefits of Agile design.
2. Agile is not freeform.
It requires certain decisions be made and maintained over time. Before beginning design work, answer some fundamental questions and create a project plan that outlines those basic ground rules:
- Who is on your team, and what exactly do they do? Create a detailed record of who does what, to help facilitate quick decision making. Keep teams small, eliminate role redundancies, and maintain this clarity both internally and for the stakeholders.
- What do you know about your target audience? Spend time up front gathering this important information. Learn the size of the group, and capture all available demographic information, any information regarding your audience’s background and experience with the content, applicable systems, organization, etc. The more you learn about your audience, the more you can tailor your strategy.
- What are your learning objectives? Spend some time up front to draft the project’s learning objectives based on what is currently known. Take for granted that these objectives will most likely change along the way.
- What is the design theme and mood for your content? The two basic pieces here are client branding/style guidelines and an interpretation of how this particular deliverable should look and feel. Is it a duplication of brand standard? Is it a lighthearted or more serious take on the standard? Is the tone casual and conversational, or is it "just the facts" and to the point? These determinations can be used to shape design decisions along the way.
3. Frequent Meetings, Constant Conversations
Constant collaboration and communication enables agility. Set up weekly meetings with the broader team and daily meetings with your sub-groups. Keep the client team engaged and in the trenches as much as you can. This visibility not only builds relationships, it also builds buy-in and ensures the client can see, and be in agreement with, where the project is heading. When the meetings begin, encourage and even mandate meaningful discussion. While initial discussions can be awkward, unrewarding, or even inefficient, the depth and the viability of these conversations will grow in conjunction with trust in the process and team dynamics. In time, these constant conversations will make project problems appear progressively less daunting until they are that much easier to solve. Eventually, these conversations will also be used to highlight the less obvious, more nuanced needs that can be subtly tweaked and lead a more thoughtfully considered, higher-quality product.
4. Organizing Sprints
Here are some tips for designing sprints for Agile ID.
- Conduct two-week sprint cycles. Standard sprint cycles are 2 weeks long, but should be adjusted according to the needs of that particular sprint.
- Determine the basics. Use your first sprint to determine the basics elements (objectives, players, style) that will be required to plan subsequent sprints.
- Outline the content. Given what you know so far, you may not be able to create a fully detailed final outline, but you may well be able to create one that is 50%, 60%, or even 70% complete. Build an outline that is as complete as it can be, then use that outline to foster conversations on finalizing project goals and closing content gaps.
- Plan the look and feel. With the basics in place, you should be ready to build out draft designs for the look and feel of your program. Beyond colors and layout, make note of other less obvious design decisions, such as tone of voice and use of language. Keeping your client engaged in this decision making should enable you to move from draft mockups to finalized templates entirely within this sprint. Depending on the team size and project requirements, it may make sense to also begin building a pool of design assets for use in later sprints. This could be a collection of source images, iconography, screen layouts, and interactive templates, all customized to the needs of this particular project.
- Begin content development and storyboarding. While it may seem strange to begin developing content before an outline is built, it can be an effective strategy. Are there elements of the curriculum that are clear or independent enough to be produced immediately? If so, have them identified in sprint step 2 and get to work on those. Again, keep your clients involved along to ensure they’re on board with the design direction and to reassure them that progress is being made.