One of the ongoing concerns among L&D leaders is how to deliver better results, faster, and at the same time increase the effectiveness of their organizations within the larger enterprise. One path to these results is Agile, a development and project management discipline.
In a recent interview, Megan Torrance offered her insights into the reasons that Agile has been so successful.
Agile, ADDIE, and business practice
BB: I'd like to begin by asking about how Agile methods can apply in an L&D environment, and why we should care about doing this.
MT: ADDIE doesn't work for us the way it's designed. ADDIE’s premise is that if we do all of the analysis, and all of the design work, and all of the thinking through all of the possibilities up front, we should be able to develop and implement without having to worry about too much change because we thought about everything up front. ADDIE was originally designed to manage our risk that way.
The problem is that our projects, like any projects that are interesting or strategic in nature, tend to change over time, and they change for very good reasons. The underlying business need changes and we find out that something is different than we thought it was going to be, or our priorities or budgets or something else changes. So our project needs tend to change along with the things that we can't have thought through at the beginning of the project. An Agile team has a built in set of rhythms by which they are regularly connecting back to the business sponsor.
This is why we should care about Agile. Agile is based on a design thinking approach, an effective way of designing and building projects. That’s what instructional design tends to be about in eLearning or digital learning solutions. Agile is designed to incorporate change and testing every step of the way. It builds in not only the acceptance of change, but also the expectation of change. One of the big things L&D teams sometimes suffer from is a frustration that their organization constantly changes its mind. ADDIE makes it hard to develop training, and keep it on budget, and keep it on time, and to make changes as often as we must make them. When the business is changing all the time, the underlying project is changing and I think it’s the ADDIE mindset that gets us in trouble.
We know in business practice that businesses have to change all the time, things are changing all the time, and the customers are changing all the time. And so the organization has to respond to change all the time. We just happen to be asking for it not to change so we can get our L&D projects finished. That's one of the big reasons why we would adopt a different approach to our work.
BB: What should an instructional designer or developer know about Agile up front?
MT: Instructional designers and developers need to know a few things about Agile up front that will help them get oriented. One is, a lot of people equate Scrum with Agile, and Scrum is just one way to do Agile. It happens to be the most popular one.
Scrum is an approach to implementing Agile that's used by software teams. The term comes from rugby. In software development, the development team is responsible for accomplishing a number of buckets of scope called stories in a given period of time. That’s what we call a sprint. And the Scrum (and Agile itself) follows a rhythm of rituals. They are sometimes called the ceremonies of Agile: all the events and rituals an Agile team follows. Events and rituals are things like Scrum planning and weekly show and tell meetings. There are daily stand ups and other techniques that are used by the software team to organize their work.
I have found that many instructional design teams struggle when they try to implement a pure Scrum-based Agile model. Our work is, in some cases, very similar to software development, and in other cases very different from software development. We don't work in the same environment as software developers, so a strict adherence to the same methods that software developers use isn't going to work for us as well. Scrum tends not to work well for most L&D teams.
Rhythm
BB: Rhythm seems to be essential to the process.
MT: Rhythm is baked into everything we do. And really, at the beginning of every project, we set up a project's rhythm. Then, depending on the business sponsor's rhythms and needs, we adjust accordingly. So a project team will have a weekly planning rhythm, a weekly status reporting rhythm, a weekly communication. We have either a face to face or a phone meeting, or a video conference meeting with our clients every week or every other week, where we share the results of what we've done in the last two weeks.
That project has its rhythm, It also has a deliverables rhythm every week or every two weeks. We are giving a deliverable on a very regular basis. Our project processes will tend to follow that. Say our team meetings are on Tuesdays. By the Wednesday of any given week, if we're delivering on a Friday, we've got things that are ready for internal reviews, we've got two days to be reviewing those things that we know we've done. We have another set of team meetings, a secondary set that happens on Thursdays. If you're a part-time, work-at-home person, you come in on Tuesdays and Thursdays to have those meetings face to face, if you can. We've taken our larger team, and built the team rhythms around our typical project rhythms so that we know what to expect. All of those rhythms help block out time when we're having meetings versus when we're head-down focused. We can have some sort of reliable quiet work time and we know we can count on that, as well. It does ebb and flow. Sounds like we have a lot of meetings, we have a lot of coming together to work on things. They give an Agile team a built in set of rhythms that regularly connects it back to the business sponsor.
What’s different about software development and eLearning development?
BB: What is different between software development using Agile and eLearning development using Agile?
MT: For example, software is very concerned with features and functions and architectures and so are we in an eLearning space. But we also care about learning objectives, which means the way that we define scope, and what software developers call user stories, will be different.
We have something else that we're doing with our projects that software teams just aren't. Software teams tend to work in continuous sprints and they have very close to immediate feedback on whether or not what they built works because their test feedback is so immediate. Our learning feedback cycle—"release it and see if this works”—can be quite long. So we are not able, like most software teams, to work as a dedicated team for an extended period of time on one project. In fact, pretty reliably when I talk to a group of instructional designers, there isn't a single person in the room with fewer than three simultaneous projects. It's not unusual for instructional designers to say, “Yes, I have double digits—I have two dozen projects going on right now.” And that's because our projects tend to be smaller.
Not only that, we have wait times where we wait on other people, we wait on subject matter experts, we wait on people to review and learn and test our courses and see if they work. So we then pick up other things. As a result, the way we manage work as an instructional design team using Agile is going to be different than the way a software team manages work using Agile. For example, a software team using Scrum will estimate how big a piece of work is in something called points that loosely, but don’t exactly, translate to hours. With instructional design, if we're trying to get a certain amount of work done in a week, we tend to estimate in hours.
So that's a big piece of the difference between software and instructional design projects. And yet we've been able to adopt of the same techniques and the values and principles behind Agile because they work very, very well in instructional design work.
Meeting business needs
BB: What can L&D learn from Agile teams about meeting business needs?
MT: Agile teams do a few things that help them stay very finely tuned to business needs. They start with defining the business goal. And in an Agile for instructional design, we ought to look at the business goal along with the organizational goal and the learner’s goal relative to it. There should be a Venn diagram between the organization's goal and the individual goal. They're rarely exactly the same. But that constant focus on “what is the goal?” is incredibly important.
The business sponsor or the product owner is the one who carries the torch; they're the champion, if you will, for this particular product, whether it's a software product or an instructional product. There’s that regular touch base. You're having weekly or bi-weekly share out meetings. The sponsor or the owner is involved in identifying scope and what will be worked on. They are the final deciders of when something is to be considered done.
Those simple rituals and rhythms really help keep the team very focused on what the business need is. The last thing you want to do as an instructional designer is to take your marching orders and disappear for the next 10 weeks to build yourself some eLearning without any regular connection back to the learners or that business leader.
I think the other thing that L&D can learn from software is this mindset around knowing that things will change and rolling with it. There's a lot of energy sometimes spent by teams feeling frustrated that things are changing. That energy can be harnessed toward changing. There's a line in the Agile principles, that we're harnessing the power of change to deliver the maximum value to the customer or the learner. And that's so huge. It's not that change keeps us from doing our job, it's that change helps us get the maximum value out of what we're doing.
Learn more about Agile and eLearning development
Megan Torrance has more wisdom and experience to share about using Agile to manage eLearning development projects. Join her for "Getting It Done: Leveraging Agile Techniques with SMEs, Sponsors, IT & the Organization" at The eLearning Guild’s online conference The Business of Learning on November 7-8, 2019.
In this session you’ll walk through Agile and its use within the L&D space. You'll explore how L&D teams that use Agile build relationships within the team and other organizational units to get the job done. You'll learn how Agile in L&D is applied differently from the rest of the organization, how Agile supports the relationship that L&D has with SMEs, how Agile helps L&D teams meet business needs, and how L&D teams can best support Agile software teams.
Register today!