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.

ELearning
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.

Conclusion:
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.

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:

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”

SAM 1

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

Sam2

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.

Agile E-Learning development


In this demanding world we usually don’t get a few months to create an e-Learning course. And our clients (either internal or external) are rapidly getting more knowledgeable on e-learning and they are demanding an increasing role in the process of developing a course. Therefore we need to work faster, more efficient and we need to involve our clients more in the development process. I do believe that all waterfall methods will fail in this and that we need to turn to other methodologies. I believe in the AGILE approach. At easygenerator we develop our software in an Agile way and it works wonders for us (I wrote about this in an earlier post). I also wrote earlier about Agile e-Learning development in a post for the LCBQ.

Recently I noticed that more and more people are writing about agile e-Learning development. I picked out some interesting post to give you an overview of what is going on. And with my post on curation and moderation in mind, I will give you a short description of the post so you can decide if it is of interest to you.

The agile e-Learning process
Don Bolen presented this at DevLearn (I regret I was not able to attend that session). It gives a very complete overview on how to apply the agile approach for e-Learning. Very informative and practical. A great introduction into the agile e-Learning development process.

Agile and action mapping
Nice post from The Learning generalist on the disadvantages of ADDIE, how to apply an agile method combined action mapping. A very powerful combination. He has more interesting posts on agile e-Learning development. You should also read his series of post: the design manual.

Managing blended learning scenarios by using agile e-Learning development.
An article by Michael Tesar and Stefany Sieber on using agile development for blended learning. Includes an interesting reading list. It is an 5 pages pdf you can download.

Designing for agile learning
A good post on agile with the emphasis om design and again a combimation with action mapping.

Agility and autonomy
Great post by Horald Jarche why agility is the better way. Of course he includes social learning and ‘learning smarter’. He is a member of the Internet Time Alliance after all.

Agile lego and training common factors
A post that explains what agile can do for your planning and comparing it to lego. Interesting post and interesting reading list at the end of the post.

Agile learning – 27 great articles
If you want to read more, see Tony Karrers blog with links to 27 posts about agile e-Learning development.

Learning (and development) strategies how far do they reach?


The Masie center brought out an eBook on Learning Strategies. This book was coined by an article by Gadi Amit in Fast Company. His point was that you can’t plan and create strategies beyond a 18 month window, there are just too many things you don’t know. In the Masie eBook 8 learning strategist talk about their strategy. The organizations these eight strategist work for is very different (from CIA, CNN, Waste management Inc, Shell, DIA, Eaton corporation, Farmers insurance and Lloyds banking), but the trend is that they support the view of Amit.

For easygenerator this is also true. Due to the shorter outlook of our customers we have to respond faster to new developments. But we still need time to design and develop great quality software and guard our own direction and development lines.

In order to do that, we work with have several windows, the future (one year and more), the next versions ( 4 – 12 months) the next milestone (2 months), the next sprint (2 weeks). For product development we don’t plan anything beyond a 12 month window.

The future (more than 12 months)
For us the future is anything that is further away then 12 months. We have our Vision and Mission in place that give us direction both in product development and in marketing and sales. Lines coming from this are our SaaS approach, the wish to work with local partners, our conviction that we need to facilitate both e-Learning experts and non e-learning experts, our goal to bring e-Learning to the workplace and markets we want to target. These are all things that give directions to our 12 months plans.

The next versions (4 – 12 months)
We do know for the next 12 months which versions we want to develop and what they will be about. We internally give names to our versions, these names show the main goal of a new version. We called the April version the ‘workflow’ version, because it focused on collaboration. The ‘SME’ was the July release because it was centered around involving the SME more into the authoring process. And we call our October version ‘Las Vegas’ because it targets for our US launch at the DevLearn conference in Las Vegas in November.

We have a road map document that outlines the red lines for our product development and we ‘collect’ wishes, ideas and new functionality in a back log; an overview of all possible development issues with a short functional description. We assign these issues to one of the future versions.

Before we start working on a version we go through all assigned issues, we describe them in more detail or we decide to move them to a later version. Based on the description our developers make a global design and give us a an estimation of the work it will take to build the functionality. Based on this information we give each issue a priority. Than we divide all the work for a version into two milestones. We will put the issues with the highest priority and issues that are very complex in the first milestone).

The next milestone (2 months) and the next sprint
We use an agile software development method (see older blog for more detail), this means that our developers work on new functionality for two weeks and deliver working software after each sprint. This means that we (if we want) can add, change and alter issues and priorities for the milestone. The only fixed thing is the sprint planning, once we set that we will not change it, other wise we would disturb the development process. At the beginning of each sprint the developers will pick issues they will work on from the back log, starting with the ones with the highest priority.

This process allows us to respond to new developments within weeks and that is something we really need in this ever faster changing environment, but at the same time it makes sure that we will not lose sight of our own goals and development lines.

On demand: agile e-Learning development #LCBQ


Learning Cirquit Big Question blogThe Learning Circuits Big Question this month is: How do you address the “I want it now!” demand from stakeholders? We had a lot of discussion on this question but I would like to approach this months question from the perspective of the e-learning author. The on demand question has a big effect on them. Usually we use a waterfall method when developing e-Learning. The most used one is the ADDIE model, where development has five phases:Analysis, Design, Development, Implementation and Evaluation. It worked for years but it takes a long time to go through all the phases, not really suited for on demand responses. We need to get faster and more iterative.

In software development we have the same problem. We did e-Learning development through waterfall models for years, but now we have the agile approach. We do our software development at easygenerator through an agile method and I love it! I wrote a blog about it a short time ago. What you do is that you work in short sprints (two weeks) having a delivery at the end of a sprint. It will be a working product. This allows you to interact with your end users a lot more, get their input and take it with you in the next sprint. It really works. We build the new easygenerator version in 3 months. And not only it is on time, it has more (and some different things) than we planned for, it works and it is stable. So I thought this methodology could work for e-Learning content creation as well.

But as always it is hard to be original. Last week at the Learning solution conference there was a presentation on this subject and a I found a lot of interesting information on the subject. Therefore instead of enlightening you with my original work, I decided to give you a short overview of my most interesting findings.

Overview agile process (Image from the learning generalist)

Sumeet Moghe wrote a post in his blog ‘The Learning Generalist‘ on agile content development. He gives an overview on how it works and even ties it to action mapping. An excellent overview and he comments on it from is own experience. Great starting point.

Catherine Lang, and Jay Thayer of Salesforce.com gave a presentation at the Learning Solutions conference in Orlando titled: Exploring the Agile Approach to e-Learning Development. They describe why they turned to an agile approach, how it works, lessons learned, tools to use and why it works for them. Interesting reading material.

An other interesting post can be found on the Integrated Learning Services blog, the author Jay Lambert is a strong defender of ADDIE. He wrote a blog on how to make ADDIE more agile by making it circular. It could be a starting point if you decide to explore this direction. In my experience with agile development it is very hard to be a bit agile, but it is a step in the right direction.

Antonio Guadagno & Matthew Tang recently presented in an online forum where they apply agile techniques they picked up from game development to e-learning. It also presents a very practical approach with lots of tips.

From my experience in software development and from reading I did I got convinced that this is an interesting approach to explore. Especially if you combine this with output learning to connect it to the workplace, learning nuggets to make it more adept and dynamic publishing principles. It will bring us closer to our goal: Bringing learning to the workplace.  We will hear much more of the agile approach in the future.

I lost my agile virginity



In the past two weeks we started working on the newest version of easygenerator. We do software development through an agile approach. I knew a bit about agile software development, but  I was never really a part of the process. I don’t want to elaborate about software development methodologies, but for those of you who don’t know anything about it I will try to explain in a few words (as I see it as a non-specialist). Software was often developed through a waterfall model. You write the requirements, design it, build it, test it, and deliver it. It is a sequential linear process where you finish one phase before you start on the next (hence the name waterfall).

Image from wikipedia

For me as a non expert the essence of the waterfall model is that as a principal you are involved in the very first phase, then it takes a long time and the you will see the end result. As a principal you are not involved in the development process, therefore the end result doesn’t always match your expectations. In 2001 a new method emerged. The project is split up in short phases (called sprints) and at the end of each phase you have a complete working (part of) the product.

Image from wikipedia

And how did it work for me? We started by making lists of functional wishes and made very short descriptions for them (e.g. “I want to be able as a user to go back to an old version of a page”). Based on this input the product owner created user stories that describe in more detail what the functionality should be. In some cases one requirement led to a few user stories. Because the user stories are functional descriptions you can (as a non technical person) still  fully understand them. Then we had a session with the product owner where we set the priorities. The development team awarded points to each user story. The points give an estimation on how hard it is to create the desired function. These points will help you measure the process  during development. If the total amount of points awarded are 200 and you estimate an average of 40 points per sprint, you know that you will probably need 5 sprints (10 weeks). If you do just 60 points in the first two sprints, you know that you are in trouble. Easy as that.

Based on this input the development team makes a selection of the use cases that they can build in the first sprint. A sprint takes 2 weeks. Every day the development team has a stand-up meting. That is literary a (very short) meeting where everybody stands and tells what he is working on at what problems they encounter. We were present at some stand-ups and where able to attend a few live when we visited  the development team. It works very efficient.

To cut a long story short today we had the presentation of the results of the first sprint. The team demonstrated the new functionality to us and we where able to comment. In two weeks time they have created: the first version of workflow, the ability to create comments on courses and pages and they build undo/redo functionality. They also realized some smaller items. We accepted everything during the demo, we only missed one small detail that they accidentally didn’t build. The shown functionality sparked some discussions that led to some new ideas. We will work them out in user stories and if we want we might include them in one of the next sprints. I find it quit incredible, after two weeks we this new version available on our demo server and we can actually use it.

This afternoon we had a second meeting where we discussed the planning of the next sprint, that will start tomorrow.

I find this a great way to work. You are as a principal much more involved in the process, you can steer better. A two week planning is easier to manage and is much more realistic than a planning that spans months or even years. Based on what we have seen we can (if necessary) adjust priorities and user stories for the next sprints. And if you get it completely wrong you lose two weeks at most!

Ergo: Agile works for me.

Follow

Get every new post delivered to your Inbox.

Join 1,083 other followers