5 quick wins for more agile e-learning development

I write and present on agile e-learning development since 2011. People like it a lot, but the response that I often get is that implementing it completely is a bridge too far. People are asking me for a starting point and quick wins. So here they are. 5 quick wins for more agile e-learning development.  If you want to know more on agile, check out my links at the bottom of the post.

agile  1. Create  an agile e-learning customer

  2. Make your Return On Investment measurable

  3. Include agile best practices

  4. Create an agile culture

  5. Test your course


1. Create an agile e-learning customer

This is the most important one. In the old ‘waterfall’ methodologies like ADDIE you will have a lot of contact with the customer (internal or external) during the sales process and the design stage. But during the period of the production there will be hardly any contact. And then suddenly: the delivery of the result. In an agile approach you stay in contact with your contractor all the time. You do a demo every week or every two weeks, showing them what you have done so far and you will get feedback on what you have created. This way you will connect the customer to the process. After a demo you will decide together what the next priorities are (see point 3). The great thing about this is that you give them responsibility in the production process. This makes the process very different. Instead of being ‘we’ (developers) and ‘them’ (customer), it can become us.

2. Make your Return On Investment measurable

The customer wants value for its money. In the past sales of e-learning was mostly driven by the available budget (we want to do e-learning and our budget is $x) or savings (if we don’t have to do a face-to-face training or can cut back on it our savings will be $x, if e-learning is cheaper we have a profit!). But that time is over. You have to prove your added value. You can only have that if your e-learning has real measurable goals. Ans what is more these goals should connect to the business goals of your customer. So if the goal of the customer is to make 10% more sales, or increase efficiency by 10%: figure out what the added value of your e-learning is,  set clear goals  and measure afterwards.

3. Include agile best practices

There are some quick wins in the best practices of agile e-learning development.

Create user stories: The development work is not described in technical details, but in a user story. It is a description from the perspective of the end-user. This is crucial for the communication between managers, customers and developers. We all understand what it means for the end-user.

Work in short sprints: Work in periods of one or two weeks (a sprint). Make sure that your user stories can be done in one sprint. Too big?: cut them up.  At the end of each sprint the development team does the demo.

Use a backlog and set priorities: You need to have a list of all user stories that need to be done. You can use specific software for that but any spreadsheet will do. In that sheet you will add the estimation (amount of work) and the priority for each story. At the beginning of the project and after each demo you review the list (with the customer), and the development team picks stories from the list with the highest priority. This way of working has some surprising effects. First you manage the project with your customer, and you can control it better. Let say you plan for a 6 weeks (6 sprints) project. You will find sometimes that your customer will tell you after 5 weeks, that the result is already good enough and that the project is done and accepted. Sometimes the customer wants to add user stories based on what he has seen so far in the demo’s. In this set up it will be clear that that is something new and unplanned. So the project needs extra time and extra funding.

4. Create an agile culture

All these things will have an effect on your culture, but the most important thing is how your view your team. In an agile approach the team is one, and everybody in the team is responsible for the result. This is a big game changer. No more: “We are late because he didn’t finish the designs on time”, or “We are late because the testers didn’t finish on time”. The team is responsible for the tasks (user stories) and if one of the members does not have enough time, the others will help out. In the ideal situation all embers have all necessary skills. This is never the case in the real world, but still it is surprising how much work and responsibility people can share if you encourage them.

5. Test your course

Before putting your course out to all learners make sure you do a beta test. Invite a group of users to go through your course before putting it live. Plan time to process their remarks and after implementing them go live. You will be surprised how much difference this will make.


Of course there is much more to SCRUM and agile than these 5 points. But each of them would make a good start and an instant improvement.

Old post on agile e-Learning development:

Agile eLearning development (6): Recap

Over the past weeks I have written a series of blog post on agile eLearning development. There is much more to tell, but I decided that it is enough for now. Here is a recap of the posts.


Leaving ADDIE for SAM
The book ‘Leaving Addie’ for Sam by Michael Allen and Richard Sites inspired me to write these series. A must read for anyone involved in eLearning development.

Business goals and road maps
Part of the growing up from eLearning is that it becomes part of the business and therefore must contribute to the business goals. In this post I describe the method of Impact mapping that will help you do that for software development, there is a clear link with the action mapping approach for elearning by Cathy More.

A successful implementation of an agile method requires a certain culture. It’s about teams and about responsibilities on the right place (less hierarchical). But most of all it is a different attitude of doing instead of ‘documenting’.

Demo’s, user stories and backlog
This post describes some techniques from an agile method that can be applied to eLearning one-on-one. For me the most important one are the demo’s. The development team showing results every week or two weeks. If you would just implements this it would be a major change.

Planning and execution
This post describes the agile way of planning and estimation through story points and the concept of done. I know that story points have some disadvantages as does the ‘traditional’ way of planning. I like it and if you would try it out it will definitely give you some new insights in your planning and development process.

Chatty Kidz
A contribution by Ken Taggert who is developing an educational app for kids. He describes his agile method, which contains a lot of interesting parts, also from the perspective of eLearning development.

That sort of wraps it up. I’m looking forward to the new book of Michael Allen, in which he will describe a lot of agile eLearning techniques. I will buy it and review it for you.

Agile eLearning development (5): Chatty Kidz

One of the people who responded to my posts on agile development is Ken Taggert, He is developing an Ipad app (Chatty Kidz) which combines video conferencing with educational activities for kids. He just launched a kickstarter project to find funding for the further development of the app. Nice project I can recommend it to you. He shared his experiences on agile development with me and I thought that that would add to my story, so here it is.

Reduces the amount of up front documentation (i.e. throw out the massive specification documents that nobody read anyway)
When starting a new project using a waterfall methodology you need to write your detailed specifications; a costly, laborious and boring job. The customer then reads through the details and signs off on the specification, approving the next step so development can begin. Yet in reality things do not really work to the plan! The customer does not read ALL the specification, they may read the bit they care about but the rest they skip through and approve the document. Problems crop up later in the project when a particular feature is tested and the client says ‘that’s not what I want’ only to discover it was detailed in the specification. In other scenarios the specification was maybe wrong or not detailed enough so the customer did not interpret the resulting feature exactly the same as the development team did; the difference is only identified when testing begins. To top all this off things change as progress is made in any project! Someone will have a better idea, a problem changes things downstream, etc, etc; especially in the larger projects.

Here at Chatty Kidz we use the Agile methodology where you can avoid the need to write huge, detailed specification documents – a massive plus for any Business Analyst!  But it is not as simple as doing nothing either, you have to still communicate the business needs for the software solution to be developed (developers cannot read minds – yet ..).


user stories are grouped into sprints as we plan to develop them.

We start with the high level wish list, simple statements such as ‘a new user can register on the website’; in Agile this is known as an EPIC. We prioritise all EPICS, i.e. what’s most important goes to the top of the list.

We pick the top EPIC and list all the relevant USER STORIES, these are still short and punchy but drill into the detail such as ‘a new user can click the REGISTER button on the homepage’ & ‘the new users email address must be validated before being accepted’. Each user story should not be more than 2 or 3 days development effort for a single developer allowing you to easily estimate the effort required using STORY POINTS (can drill into this but maybe link to these points online – there is loads of info).

We prioritise the User Stories and start development, we aim to deliver ‘something’ to the customer/user at the end of every sprint. So they can test & provide the valuable feedback, we listen and use this information for the next sprint. So we can change if need be when something more important comes to our attention.

Overtime we incrementally improve what we have built so far, adding new features & functions to the Chatty Kidz platform with each successive sprint. We save heaps of money by developing cheap working prototypes & getting them into the hands of real users. We listen to their feedback & begin work on the next release, deploy another incremental improvement at the end of the next sprint – rinse & repeat. NOTE: we use Jira to manage this process 

Manage your budget better (i.e you can be more flexible as the project progresses, the vast majority development projects change tact anyway as they progress which caused havoc with budget estimates fixed in stone before the project even started)

In a waterfall project you use the detailed specification to estimate the project costs, these are approved and the project manager must manage those developments within the approved budgets – things go wrong eventually as many details were estimated incorrectly 10 months earlier.

At Chatty Kidz we still estimate the allocated budget to be spent on specific features, but we know it is not detailed nor accurate.  Its simply how much we are prepared to spend at that point in time. As we have documented lots of user stories we keep prioritising them and developing them until we have exhausted the approved budget. Any user stories which are still left in the list remain there until some future point in time when we do have more budget.  For example the next module may have been a lot easier that we expected so we can include some user stories missed from the previous sprint.

Yet the opposite is also true & often difficult for the project customer to grasp, if something was more complex than expected & consumed more money or new high priority user stories have been added during the course of development.   The budget does not magically increase, the team must stop when the budget is consumed.   They can apply for more budget to finish off some important items, but they do not blindly continue spending money and blow the project budgets because the project controls are so much better and managed at a useful granular level.

Produce a better product (deliver something into the hands of real users earlier, get them involved in the testing process earlier and fix them long before the product launches)

In  a waterfall project the project first designs something on paper, then builds it over the life of the project. Towards the end the users get their hands on the resulting product when the testing phase begins; this is often where it hits the fan because it is only now the user/customer can see things look different to what they expected from endless 100 page specification documents and endless boring design meetings held at the start of the project. They have not been involved for the last 10 months as the build phase was completed by the project team!!


FIG: we deploy the app into the app store sooner than later, to get real user feedback from a real product sooner

At Chatty Kidz we use Agile and involve the users/customer from start to finish of the project life-cycle. We do not overload the user at the start of the project with loads of design meetings and thick specification documents, instead they attend meetings every 2 weeks (the length of our sprint) and they are asked to focus on a specific feature. It is a lot more manageable for the user because we are only asking for a limited amount of their time!  We do not ask them to review massive detailed specification documents because we created the user stories together. There is less worry & stress about budgets because each 2 week sprint has a very clear budget estimate that’s not that large compared to the entire project – its a manageable chunk for everyone.

We involve the users/customer throughout the entire life of the project as they have to test the real software resulting from each 2 week sprint, again it is not an onerous task.  Because there is not a massive amount to test, we are productive in each 2 week sprint but it is only going to take a user a few hours to test it & provide their feedback – easy.

There are no surprises waiting for anyone as they are involved in the incremental improvements made to the software sprint by sprint

NOTE: we use testflightapp to distribute the ALPHA versions of the app to the test teams, allowing us to get feedback even earlier.

This post is part of a series on agile eLearning development:

Agile eLearning development (4): Planning and execution

When using an agile approach there is a different way of making estimations, you don’t calculate hours but use story-points. Story points are a number indicating the difficulty of a user story (and thus indicating the amount of time/cost it will take to build it).

First estimation

When we start on a new version of easygenerator we will from a business perspective assign priorities to the user stories. Very large developments (epic) stories are divided into smaller stories that fit in one sprint. The development team will give rough estimations on the stories with the highest priorities (the ‘must haves’ and ‘need to haves’). Based on these estimations the priorities are reviewed by the product owner and me. Sometimes when you see that it will take a lot of time to complete a user story you will decide that it is not that important after all, and vise versa. This way the user stories are organized by priority in the backlog.


Grooming and estimates

User stories that are initially produced by the product owner sometimes need some refinement, this is done in so-called grooming sessions. The development team will discuss the story with the product owner, asking questions to get the story and the requirements clear. The user story are updated after this session with the outcome of the discussion. After grooming the team will make a final estimation in story points. For example 3 points for a simple story, 8 points for an average story and 13 points for a difficult one. When you have a groomed backlog with final estimations you know how many story points the work is you have in the backlog.

Each sprint the team commits to a number of stories and afterwards you will know which stories they have actually finished. The total number of story points done in a sprint  is called the burning rate and determines the development velocity. After a while you will know how many points your team can burn in a sprint and you can calculate the time needed to develop all stories. We work with certain release dates and often the total number of story points (and needed time) is higher then what you have available. In that case you have three options.

  • again go through your backlog and look at what is really a must have and skip some stories
  • increase the capacity of the team
  • move your deadline towards a later date.

Usually we choose the first option. And I like this. You have a triple filter before deciding to build something. First the original prioritization, then after the rough estimation and finally  the second prioritization after grooming. This is a good thing, it ensures that you will only build what is really needed and nothing more.

When the team starts developing you will see every week how many story points they are burning (we work with one week sprints). If this is lower then expected, you will know very soon and you can take measures (try to increase the velocity, or again review the priorities of the must haves). You can steer at very short notice and this is really great. An ideal way to time box development.


User stories will only be presented at demo when they are done. Done means that you could decide to put them in the production version of the product straight after the demo. So build, tested, documented, translated and meeting all the requirements. Requirements are the requirements that where in the user story, but also general requirements for performance and UI.


This method of planning and execution can be used for eLearning development without any changes and I promise you it will be a huge difference.

This post is part of a series on agile eLearning development:

Agile eLearning development (3): Best practices, Demo’s, user stories and backlog

In the previous post on agile eLearning development I wrote about culture. I have done some change management in the past, so I know a change in culture is one of the most difficult changes. But there is hope. Agile development offers a range of best practices that are relatively easy to implement. In the next posts I will describe a few.

Agile development works in short sprints (one or 2 weeks). After every sprint there is a demo where the development team shows the result of the work of the past sprint. At easygenerator we now work in one week sprints. Every Tuesday at 10 the team will show their results. The product owner will check during the demo if the solutions build match the requirements from the user stories and will accept them (or not). I am present (as CEO) and some more colleagues. But we also do invite partners and customers to join us in the demo, this way giving them the ability to get connected to our development and offering them the opportunity to give their input during development. A demo takes 1 hour.

This is an easy first step to implement and if you do it will change your professional life. You don’t have to implement an agile process to do this. When using Addie you can also do this. It is the ideal way of involving your client in the development process. Taking them along in the process, showing early results. But if you see something live you will experience it in a different way than when it is described on paper. How many times did you build an eLearning solution that met the requirements, but still the client wasn’t satisfied. This will solve that once and for all. The other thing is that you will sometimes find that good is good enough. This approach will give the client a chance to say “OK this will do, let’s put it live”; giving you a happy client and a project delivered early!

There are many ways to involve a client in the process but showing your intermediate results and make your whole process transparent to them is really great. If you are not ready to do so, at least consider showing your intermediate results to the client (by using for example the preview function that is available in tools like easygenerator). That would already make a big difference.

User stories

The heart of agile development is formed by the user stories. With an agile process you don’t create all kind of documents that describe the solution from several perspectives, you just create user stories. Of course they need to be connected to the goals (as I described in an earlier post).  A user story describes a change or new functionality from the perspective of a user. It will describe what the user is able to do. A user story can be initiated by an idea or a problem (bug). User stories form the connection between clients and technicians. Both of them understand functionality described in terms of what the user can do. A user story must be small enough to be realized within one sprint. This means that larger stories need to be divided into several stories, with the advantage that they remain manageable.


In an eLearning project they will describe what the learner needs to be able to do (which gives a great connection to learning goals and the Action mapping approach. (by the way do you see the resemblance between a TinCan statement and a user story?).

The backlog
All the user stories are put in a so called back log, a big collection of user stories that need to be done. There are software programs that help you manage a backlog (we use a program called Gemini). This application plays a crucial role in the whole process.

After a user story is created we assign a priority to it. At easygenerator this is done by the product owner with input from me. In an eLearning project this would be the project manager and the client. Based on the business goals and business impact we will assign a first priority. Based on the priorities and we present a part of the list to the developers. They will make rough estimations for these stories (a special process with story-points, that I will cover in my next post). After this is done we (the Product owner and me) will determine the final priorities. Sometimes you want something badly, but if it takes a lot of time (and money) you will at least reconsider the priority. Based on the estimation we also will have a good idea what we can do for the next version and what not.

This results in a list of user stories assigned to the next version in the backlog. When starting a new sprint, the developers pick any of the user stories with the highest priority and start developing.

This post is part of a series on agile eLearning development:

More post will follow over the next few weeks.

Agile eLearning development (2): Culture

I planned to write this second post on agile eLearning development about the backlog and estimations. But when I was preparing this post I realized that I had to cover something else first; Culture.

The difference between a classic waterfall approach and an agile one is way more than applying a different set of tools and techniques, it is a different state of mind. For starters it is a very different way of control and steering. The best way I can explain it is by looking at a management theory called output management.

In 1998/1999 I followed a course in Change Management. It did consist out of a series of three-day seminars. Each seminar we had a guest teacher  from the field of (change) management. One of the guest teachers was Filip vandenDriesche. He is the author of the book ‘Leading without commanding’,  it was originally published under the title ‘The input- output manager’. For me his theory describes the very essence of management but it also applies to an agile approach. The next image is the heart of his theory.

output management

Filip states that the main challenge of management is the conflict between  strategy and operation. There are two contradicting pyramids. The “management funnel”  and the “conflict pyramid’. Both cover three stages (strategic, tactical and operational). On the strategic level (problem and goal) the chances of conflict are small, but if you have a conflict it runs deep! On a tactical level (criteria) the chances of conflict are increasing but on a operational level the chances on a conflict are the biggest. Therefore Filip concludes the following: A manager should be authoritarian on the strategic and tactical level. But on an operational level manager should accept any solution that meets his criteria. In other words keep away from the ‘how’.

I have been working as a manager now for 15 years and I found out that it works. But more importantly I found out that it is about trust and not about control and therefore it is about the culture of your company. Not many companies are build on trust and the recognition of the skills and capabilities of all the participants. As a manager you have to set goals and requirements, but that is it. You need to trust your team that they will come up with a solution, and as long as the solution meets your requirements you should accept it.

How does this apply to eLearning? It works like this. The manager (or in case of a project, the client) has to define the problem and set the goals. (The goal is the positive flip side of a problem; ‘we don’t sell enough’ vs ‘We need to sell 10% more’). All the people who are part of the process must recognize the problem and accept the goal. This is buy-in number one.

The problem/goal is a business problem/goal of your company or client and if you or any of the team members don’t buy it, you have a big problem. The chances of this happening are small. After the problem/goal is defined the manager sets requirements for a solution. Requirements can be anything from time, costs to quality and everything in between, as long as they don’t dictate the solution. A requirement should not be: ‘the course must be in HTML5’, but ‘the course should run on all mobile devices and operating systems’. Filip says a manager/client has to be authoritarian on requirements, but I don’t completely agree. The whole process only works if the team that has to create the solution accepts the problem/goal and the requirements. By accepting both they become responsible for the solution within the given boundaries. I found that before acceptance some negotiations on the requirements can/will happen. For example with the goal ‘the course should run on all mobile devices’ the team could come back with the remark that given the time and financial restraints they can do it on IOS and Android only or they need more budget and time, or that they can do it if they have special software available. This second buy-in is all important, by accepting the problem/goal and requirements the team is now the proud owner of the problem, they need to come up with a solution within the given requirements. Thanks to this you empower them, you recognize their expertise and skills and basically you show as a manager/client that you trust them. On the other side the team has to deliver. They have committed to creating a solution and if they fail, it is their problem. They can’t say that they didn’t had enough resources or time, because they have accepted the requirements. In that case they made a mistake accepting it. On the other side the manager/client has to accept every solution that meets the requirements. If the manager/client is not happy with the solution obviously there was something wrong with the requirements.

But there is more to agile. It is also a very different attitude to planned development. As I will describe later in more detail, the customer demands are captured in ‘ user stories’ that are prioritized. The developers will commit to these user stories and build them in short sprints (periods of one or two weeks) and then they will demo them. In our case the demo is done to some colleagues (product owner, CEO, instructional designer), but very often partners or customers will also attend these demo’s. The goal of the demo is for the development team to show how they solved the user story within the requirements. The product owner is the person that can officially accept a user story. The cool thing is that seeing the implementation of the user story can trigger some things. Sometimes seeing the solution brings on new ideas (and will lead to different or adjusted user stories) and sometimes we decide that this solution is good enough (although there are more developments planned). An example we had at easygenerator is our version control, we had a whole bunch of  user stories ready, but after the implementation of the first two stories (create a new version every time a page is saved and be able to roll back to a previous version), we decided that this was ‘ good enough’ as a solution for our business need. We decided to leave it like that and bring out the new version with this functionality. And it is still there to this day, it does it’s job and it satisfies the users. So sometimes it will be so agile that you stop earlier than planned. This is just  an example what an agile state of mind is.

Working in an agile way requires a certain culture. You need to have responsibilities in the right levels (as I tried to explain using the output management approach. Teams should work as a whole accepting responsibility to realize user stories within the given requirements and a project can shift during the execution (maybe even will shift) and can even be ended earlier than planned when the goals are reached.

This post is part of a series on agile eLearning development:

More post will follow over the next few weeks.

Agile eLearning development: business goals and road map

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.

Agile software and elearning development

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.

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:

More post will follow over the next few weeks.

Book review: Leaving ADDIE for SAM: will agile eLearning development become mainstream?

I have read the book from Michael Allen ( and Richard Sites) with a lot of interest and it is a book that I can recommend to read, it does explain the why and the how of the approach and it contains a lot of practical stuff like examples and check list that will help you get started.

I believe that an agile approach will bring a lot of benefits to e-Learning development. I wrote a couple of post on this subject in the past few years so I am delighted that a heavy weight in our learning domain supports this trend, hopefully making it more mainstream. I’m interested in agile development because we develop the easygenerator software in an agile way. It gives huge advantages over the classic ‘waterfall’ models. I believe if you translate this to e-Learning development, it will change not only the way we create e-Learning courses, but also the courses itself. Michael and Richard present us an agile alternative for ADDIE: SAM (Successive Approximation Model).

The book starts with why we need a new approach. It lists the short comings of a lot of e-Learning courses in a clear way. It is followed by an analysis of ADDIE, looking at its original form and some new manifestations. It makes interesting reading because it is not a theoretical story but they have written it from the perspective of the learners needs. Their conclusion is: ADDIE falls short, we need something else (and I agree).

In the third chapter they have a look at what ‘good’ eLearning should be, I quote: “Concise, effective learning events, whether delivered through e-Learning or not, are meaningful, memorable, and motivational. And they achieve measurable results, too.” And they explain CCAF (Context, challenge, activity, feedback). With this they set the stage for the process and introduce SAM.

There is a simple version (SAM1), for small projects”


And a more extended version (SAM2) for larger projects”


I will not discuss all details (you should read the book) but what they do is take the iterative nature (short development sprints) of agile development and combine it with a prototyping approach. I like this; it will bring a lot of the advantages of agile software development to your e-Learning development. The book contains a huge amount of examples, checklists and even a complete project plan. It will help you to create learning goals and it gives examples of specific approaches (like the Savvy start and prototyping). The Savvy start is the second concept they introduce in this book. A concept that will help you to become more agile in your design process. It is clear that both authors have a few decades of combined experience in eLearning development. This enables them not only to develop an approach but explain it with very practical examples. And as you can expect from me I’m very happy with the chapter on instructional objectives, this is the way it should be done! The second part of this book is so rich, that even if you don’t want to switch to a more agile approach it is a must read. It is a goldmine of useful tips for every instructional designer.

Michael and Richard created a great foundation for a new agile approach. At the same time I think that they missed a lot of best practices and techniques that an agile approach can offer you. Daily stand ups, user stories, a back log, agile estimations, setting priorities, an agile team, demo’s to involve your clients. There is a lot more that can be used. I will write some future posts on this, trying to make the translation from best practices and techniques in agile software development to Agile e-Learning development. I will try to add another practical layer to the SAM foundation.

Ordering information Leaving ADDIE for SAM:

Books published by ASTD Press can be purchased by visiting ASTD’s website at store.astd.org or by calling 800.628.2783 or 703.683.8100:

  • Library of Congress Control Number (print edition only): 2009940017
  • PDF e-book edition ISBN: 978-1-60728-675-2
  • Print edition ISBN: 978-1-56286-711-9

And finally some links to earlier post I wrote on agile eLearning development:

  •  A post with links to other ‘agile’ eLearning posts
  • A post that I wrote for the ASTD’s big question blog on agile development
  • And my first post on agile development after I joined easygenerator

This post is part of a series I’m writing on agile eLearning development:

More post will follow over the next few weeks.

How to keep formal e-Learning relevant

We all know that e-learning is changing, we all know that our learners have changed. The rise of the internet, social media and mobile devices have changed our world. It turned out that it is much easier for a learner to adapt to these changes than for a e-Learning manager or developer. Over the past 16 months I have written all kind of post researching this change. I was recently asked to present on this subject in a webinar. In my preparation I went through all the posts and was for the first time able to merge them in a coherent way. I wanted to share this presentation with you.

Additional information on a lot of the subjects that are in the presentation I wrote about earlier. These post contain a lot of links to other resources on the internet on these subjects:

•Output management
•Agile development for Software, and for e-Learning
•Learning metaphors, learning maps
•Outcome learning (series of posts)

You can attend the webinar if you like (Wednesday February 15th 2012 10.00 am and 2.00 pm EST). See for details the site of Interactive Advantage.

Webinar: Didactics, Management theory, Agile and new learning metaphors equals Outcome learning

Last year I wrote a series of post on outcome learning. I have continued to work on this and now I have a new version. In the earlier version I combined didactic principles with a management theory. I order to make it more complete I now added principles from Agile (Scrum) software development and my ideas about a new learning metaphor.

I presented on this subject at the DevLearn conference in Las Vegas last November. The US partner of easygenerator (Interactive Advantage) organizes webinars on a regular basis and they have asked me to present on this approach. The webinar will be February 15 on 10.00 am EST and a second one at 02.00 pm EST. You are welcome to attend (see details here).

If you want to read some background info on me, you can best look at my LinkedIn profile. Although I will present new material you might want to read some relevant post from past year:

I will post my presentation after the webinar.


Get every new post delivered to your Inbox.

Join 1,096 other followers

%d bloggers like this: