This is a first post in a series of post on Agile eLearning development. This series is sparked by the book ‘Leaving ADDIE for SAM’ by Michael Allen and Richard Sites. I wrote a book review on it (and it love it). I do believe that agile software development can offer us even more very practical ‘best practices’ that we can apply to eLearning. Michael told me that he is working on a new book on agile project management, that will also address this. In the meanwhile I would like to share with you our best practices. The idea is to go over the process of agile software development at easygenerator and translate that into eLearning development. I will start with the ‘long term planning’: The road map and how to connect learning to your business goals.
Before I can do that I have to introduce the roles in this process and map them to ‘e-Learning development roles’.
| Software role | eLearning role |
| The Product Owner (PO), he is the most important person in this process. He is responsible for the ‘What’. What will we develop in the next 12 months. He translate the demands from the market into product demands. | In corporate eLearning terms this will be the manager of the Learning department. He will translate the training demands of the company into goals for the learning department. When we are talking eLearning projects this will be the Project manager |
| Market. Partners, customers, end users, competitors all have developments and demands. This is important input for the road map. | Your market are the users of the learning objects (both managers and end users), but also by general developments in the eLearning market with vendors and other companies and theoretical and technical developments. |
| Innovation. I have put this down as a separate element. Innovation comes from the development team, the organization, users, customers, the market. If you don’t pay separate attention to it, it will be something that you strive for, but never achieve. | Exactly the same here |
| System architect. A ‘double role’. The system architect checks planned development for technical challenges, but at the same time he will have independent input for the road map. In our case things that have to do with our technical backbone, security, performance. | I don’t think that there is a eLearning equivalent for this role. But there should be. Just think of all the technical developments around mobile, standards (like Tincan) and other technical stuff. You need more than a technician to manage this. |
| Road map. The document that contains the global goals and plans for the next 12 months. | This would typically be a year plan for a learning (or HR) department or a ‘customer plan’ for a client. |
| Development team. The team that builds the software. | The team that builds the learning components. |
The road map
We like to look ahead, but no more than 12 months. Therefore the road map documents looks 12 months ahead. We release a new version of easygenerator every 2 or 3 months (we are working on a release every month). This means that it is not a plan for 2013, but it is a plan that always looks 12 months ahead. Before we finish a release we need to renew the road map so it will still look 12 months ahead. The road map is driven by our business goals and will set the development goals on a high level.
Business goals and road map
This means that the first step is to get clarity on the business goals and how they will influence the product development. We use a method called impact mapping. There is a free tool called effectcup that supports this whole process. The Product owner takes the business goals (input CEO) and figures out what this goal means for key persona’s. What activities do they need to be able to do. And which user stories describe these activities. Our business goals are things like:
- Sell more licenses
- Sell easygenerator as internal authoring tool to LMS vendors
- Keep existing partners and customers happy
The road map document is in fact a short document with a bit more explanation about the why of the business goals that you can present to other stakeholders.
eLearning
The trick is to figure out what people need to be able to do in order to achieve these goals. The translation to eLearning is very simple. I love the action mapping approach of Cathy Moore (see a post I wrote about this earlier). It is a one on one translation of impact mapping to eLearning. She also stresses that learning is not what people need to know, but what they need to do. That is the reason she calls it action mapping. You could use a tool like effectcup to assist you in this.
It works for a learning department or a eLearning project. For an eLearning department it is the first step in connecting learning to the business, and it is the foundation of a possible ROI calculation. When you do eLearning projects it is also very helpful. Instead of executing a project this will give you the chance to sit down with your client and talk on a much more strategic level to them.
Another important thing is that you don’t get into solutions at this point. You describe what the learner (worker) needs to be able to do. Not what kind of learning experience you are going to offer. Measuring their (hopefully improved) performance will tell you your ROI.
This post is part of a series on agile eLearning development:
- Post 1: Review on Michael Allen’s book ‘Leaving ADDIE for SAM
- Post 2: Agile eLearning development: business goals and road map
- Post 3: Agile eLearning development (2): Culture
- Post 4: Agile eLearning development (3): Best practices, Demo’s, user stories and backlog
More post will follow over the next few weeks.
The Learning 2019 conference
I have been to a ton of learning conferences but this will be my first time at #learning2019. I’m looking forward to it and I’m planning to report on all interesting sessions via this blog.
