Applying Agile Principles to Training Development

I’ve been fortunate to lead a number of training development engagements, and it’s one of the things I love about training. It’s creating something new. It’s creative, it’s messy, and it’s hard work, but it sets the stage for great training delivery. Thinking about how to best convey material, what learners will need, what will best meet them where they are, and what’s scalable are really interesting questions – and ultimately, developing training ideas and concepts into tangible work products can be a lot of fun.

In my previous projects, we used a waterfall approach where each phase was distinct and things unfolded more or less sequentially. Waterfall has certain advantages when it comes to training curriculum development because there are often harder dependencies between stages and pieces of content. In software, by contrast, you may be able to make a lot of progress on one item without having to interact with another work stream.

With training material, the bar for what constitutes a minimum viable product is often a bit higher. Training materials need to achieve a certain level of completeness and quality or they will simply not be useful to students. In training development, you may also need to complete certain activities before you start others. You can start writing a curriculum without first having a syllabus, objectives, or outline, but your chances of success are much lower and your chances of needing rework much higher.

Given this tension, it might be tempting to think that Agile principles can’t really be applied to training development. But while it may not be the perfect implementation of Agile, we found that many of the principles can be highly useful and also usable when it comes to training development projects. Here are 8 things we learned about what you need to do to develop training materials in an Agile way.

Define your course syllabus

Having a clear idea of what knowledge and skills need to be covered in a class is still incredibly important. So is knowing when those skills will be taught. Just because things are being done in a more Agile way doesn’t mean you can avoid planning. Once the scope and sequence have been agreed on, plan for how to deal with changes. As with software development, change can really disrupt progress. Figure out how much change can be tolerated without impacting your timeline or have a plan for how you will adjust your expectations and timeline accordingly.

Define your deliverables

Get really clear on what your deliverables are and what’s involved in each one. What types of deliverables do you need? What must be included in each for it to be accepted? Many courses need outlines, storyboards, student guides, and quizzes, but you need to define specifics for what’s needed in each of these components before you get started. Create deliverable prototypes or artifacts to refine what each deliverable should be, and describe what a deliverable needs to be considered complete.

Agree on a review process

Reviews can be a bottleneck and can kill your forward progress, so you need agreement in terms of what needs to be reviewed and how it needs to be reviewed. You also need buy-in that reviews will happen timely. When designing your review process, aim for the smallest number of reviews required to support the level of quality you want to achieve. At the same time, find ways to review materials in earlier stages when they can more easily be changed and take on new directions. Decide who needs to review at each step and make sure that they are empowered with the right level of authority to keep things moving forward. Decide how you will collaborate and what tools you’ll use. Lastly, don’t be afraid to adjust your review process as you go. You may find that fewer reviews will suffice or that what you thought was important has changed.

Start with your workflow and development process

This is a critical step in the whole endeavor. Here, you are taking the syllabus, deliverables, and review process, and aligning them into a coherent development process. Break down deliverables into interim stages so that there can be a continuous feedback loop along the way. Figure out how you will incorporate edits and updates into the process. Each round of review will generate some required updates, so you need to know how you’re going to deal with those in terms of tracking whether they were completed. We recommend building some trust into the process here. Don’t send for a second round of review to validate that updates were made until you get to the final deliverables. Remember, reviews can really stall the process, so you want to use them wisely.

Set up your sprint cadence and milestones

Plan milestones and don’t force yourself to align them with sprint deadlines. Use your estimates for how long deliverables will take to outline your sprints. Plan ahead but leave flexibility for your plan to change as you learn more about how long things actually take. Then use your velocity estimates and actuals to refine future sprint planning and adjust your milestones. It’s important to build in some flexibility here because you’ll probably find that things take a bit longer than you expected. 

Determine how you will track the work

I’d propose using JIRA (or something like it) with a Kanban-style setup. The setup might have more columns than you’re used to if you’re more accustomed to software development, but I found it was really useful for visualization and ownership purposes. Because instructional design projects usually involve a number of team and client team members, it’s helpful to have columns that can be assigned to an individual or group. This helps to drive accountability and can also help uncover blockers or areas where folks need support. Here’s an example of what that could look like in practice.

Backlog

Current Sprint

In Progress

Ready for Team Review

Ready for Stakeholder Review

Final Updates

Complete

Another reason I like this setup is that it makes it easy to see where the work is in process and where the bottlenecks are.

Now cover your ears, purists. We used a combination of Kanban and Scrum approaches. We used Kanban for the workflow and actual board setup. This can help to visualize where work is in the process and can help to simplify it for the development team. But we found that scrum principles were still needed to set up a sprint cadence and understand velocity.

Focus on progress, collaboration, and feedback

Focus the team on doing their part efficiently and with the right level of quality. Encourage collaboration: peer reviews, reviews by other disciplines, and client (or stakeholder) reviews are all opportunities for collaboration and further refinement of objectives. Take advantage of those opportunities. Prepare your team for feedback. With all of the reviews, your team members are going to get a ton of feedback. In general, this is a good thing and leads to a higher quality product. But it can be overwhelming for team members who aren’t used to having others in their work to that extent.

Anticipate slower going in the early stages

As with any project, there is a learning curve. Be prepared for it. The velocity you achieve in the first few sprints may not be what you can achieve at full productivity. Moreover, the first rounds of production and review will likely take longer because the team is still feeling out the specifics of the requirements. It’s one thing to agree on something in principle, but it’s another to agree on the finished product. Leave some time and space for this norming to occur. It will save you time as you get further into development. You may even find that as these requirements become clearer, you can drop some of the review cycles.

We found that this was the case for our team. Even though we had gone through the exercise of clarifying expectations, the team still needed to calibrate to the right level of detail, what points to address, and how to balance all of the competing priorities. Once we got to this point, we were able to drop a couple of the reviews which helped to increase the team’s velocity.

Applying Agile principles to training development can have a lot of benefits. It enables a continuous feedback process and creates a more iterative environment where collaboration is encouraged and changes can be more easily facilitated. It enables team members to break their work down into meaningful and achievable chunks and helps you continuously refine estimates, due dates, and milestones.