Is ADDIE Appropriate in Agile Projects?

ADDIE

ADDIE (Analysis, Design, Develop, Implement, Evaluate) has been a benchmark model for instructional designers since the 1970’s. It’s used as a method for creating training materials and making sure they are a good fit for the people who will be taking them. Typically it is shown as a waterfall project methodology although other more modern adapatations of it also show it as a circular process.

However – as many projects that we now work within are Agile, I find myself questioning the value of ADDIE as a good fit for these projects, along with some other forward looking thinkers. e.g.

https://www.slideshare.net/chrisking/sra-agile-presentation-final-v1print

https://performancexdesign.wordpress.com/2009/09/09/addie-is-dead-long-live-addie/

Software Projects

ADDIE was, and arguably still is, a good model to use when thinking about the development of a training programme. It is certainly better than no model or methodology at all, but I think there are some cracks beginnning to show. When projects use a waterfall project methodology then ADDIE certainly seems to complement them, but what happens when what you are creating training materials on, seems to be like quicksand beneath your feet? Specifically, in a software development project (where the GUI for the software that is being developed can change rapidly) waterfall methodologies don’t work. The reason for this, is that each time there is a change, you go back to the start of the methodology again. This means you are always playing catchup and not actually developing any of the training materials at all.

When we use ADDIE we tend to use it in the development of training modules which we combine together to form courses and learning paths. If there is a change in a single part of a module, then we have to spend time modifying and republishing the module, then the course and then the learning path. This makes it very inefficient in the way that it can handle change. As as result of this, I no longer think that ADDIE fits well with agile projects.

A Way Forward..

..for creating training materials on how to use an application (systems training).

I think there are two developments that are key enablers for moving away from ADDIE and into a more efficient method of developing training materials. These are learning objects and the software that support the development of them and object recognition, which allows rapid updates to learning objects that have already been created by automatic re-recording of them.

When you start using learning objects and object recognition, then you can adapt your training methodology to fit alongside the agile methods and tools being used. For example, many agile software development projects nowadays use JIRA for the creation of issues, scrum and kanban boards, product roadmaps etc.. It is very easy to export a list of JIRA stories into a spreadsheet that can then be used as the basis for a training development plan. As a sprint progresses and it becomes clearer what is being included in it, then this list can be refined to create learning objects in the authoring tool (ideally by importing them from a spreadsheet). Workflows are then used to manage the development and review activities. Finally, an automatic release process can be used and the learning objects used to populate knowledge bases in a support desk tool as well as being used for training people.

Here is an example of how you might embed a training development process into an agile project.

Learning Objects in an Agile Methodology

Sprint Planning and Feature List

At the start of the sprint a list of features that are going to be developed are agreed upon by the project sponsor, product management and development team. A backlog of features can also be stored, for inclusion into future sprints. The backlog is also the place where if a feature is put on hold, then that feature goes back, into the backlog. Each feature has an amount of documentation about it explaining at a high level what is needed.

Training Plan

Coming out of the feature list we can begin to make a training plan. This should consist of:

  • How many instructional designers do we think we will need?
  • When will development activities (creating LO’s begin)?
  • What sort of workflow are we going to need and who is going to be participating in that workflow?
  • Are any templates needed?
  • What courses and course modules are needed? (This is similar to the Analysis stage in ADDIE but makes more assumptions based on the knowledge about what the software is being developed for and the intended users of that software) Crucially, this course and course module list is flexible and can change.
  • What are the key dates for the sprint that the training development activities need to align to?
  • Where is the software and how do we access it?

Stories and Learning Objects

An agile story is used to describe how a piece of software will be used by the end user of that software. They align very closely to the concept of a learning object, although it frequently happens that one learning object can include multiple user stories. An export of the story list is the best starting place to define the learning objects that are needed. This requires some Instructional Design support and a large dose of common sense.

Sprint and Daily Scrum

As the sprint progresses, there will be a daily scrum meeting in an agile project, where the development activities and updates on progress will be shared with the team members. A training representative or the scrum master should listen out for stories which have been completed. When they are, they can set a flag in the development software showing that the development activities for the creation of training materials on that learning object can then begin.

Demo

At the end of a sprint all of the learning objects are collated (curated) into modules and courses and combined together. They can then be published as eLearning, training manuals, quick reference guides, instructor PowerPoints etc and demonstrated to the project sponsor and stakeholders. This is the stage of the process that is most akin to the Evaluation stage in ADDIE.

Sprint Hardening and Update LO’s

Any feedback from the demo is incorporated into the version of the software application that is going to be released and bugs fixed if they have been found in testing. If any changes impact a learning object then it will need to be either updated using Photoshop or re-recorded. It goes back through the review and release workflow again before being published.

Publish

At the end of the sprint hardening, all the learning objects are collated again and the modules and courses re-published, inlcuding any LMS updates that are needed.

Summary

By using learning objects and re-recording them using object recognition you can now embed your training development methodology into agile projects and actually keep up with the execution of them because you are aligned with them. The training project should no longer be thought of as outside of the main development project.

Let me know what you think and if you have any comments, then please make them in the space below.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.