Our journey began by listening to others trying to communicate about how Agile could help with courseware.

One influence was Michael Allen. At an industry conference we heard Michael Allen talking up his book, Leaving ADDIE for SAM which describes his Successive Approximation Method (SAM). We decided to look into SAM a bit more. We found his iterative SAM approach interesting and helpful, but his book did not really provide enough information for us to build our own processes from scratch internally.

Around the same time, at a different conference about Darwin Information Typing Architecture (DITA) eXtensible Markup Language (XML), we heard reports of a handful of organizations using Agile. They supported software development teams that were using Agile. So we started researching Agile and noticed that Lean applies to it as well.

We had already been applying Lean as a company, and we started seeing the connections between Agile and Lean. In addition, the various Agile method proponents argued for their Agile way to be followed. Yet we find training learning experience development to be different than software development in significant ways. We could see that some of the practices being pushed could help us quickly, but others would take more time.

We started trying to apply Agile Kanban first in a smaller office because it required so little organizational change to get started. It could be done locally without authorizing additional funding. We also had concerns about how Agile would be perceived since it began life in the software development domain, and not from training.

Kanban was easy to see how to set up a white board, but it was initially hard to visualize based on what is written about it because it is about tracking a dynamic process. We tried to apply it with a team that was already started on a project, and we learned lessons.

We work in an earned value and traditional project management environment with detailed process practices.

We experimented with what was really needed on Kanban cards in our circumstances and what we could leave out.

Your experiences will vary depending where your organization is on the spectrum of formal processes. Some organizations range from near anarchy of organizational processes to near tyranny of such processes that discourage innovation.

Then we noticed our software engineers were already using Scrum and so we spent time trying to apply it to learning experience development. We found that parts of Scrum worked best for learning experience development and parts of it did not help as much given our set of circumstances at the time. Then we found others who had found both and combined the two into Scrumban. In the details of Scrum and Kanban, we found the specifics we needed to experiment and build out our working processes after the seeing Michael Allen present some of his iterative ideas from his Successive Approximation Method.

Some projects required a single prototype, so iterations of prototypes seemed out for that circumstance. Our courseware design documentation (CDD) was still firmly an expectation with Government buyers and therefore a requirement, and yet the “iterations” for design tended to only be resolving customer comments from their review of the document without getting to courseware. We cover more on Lean-Agile Design later in this book.

Later on, we worked with some customers with a more iterative design approach too, but we only applied Lean-Agile to development initially. We did not have the option of only performing rapid prototyping, so parts of SAM would not work for us.

At an eLearning Guild conference, formerly called mLearnCon, we heard from a handful of other organizations that were applying Lean-Agile to their training development. We listened as they shared what they did. Most of these groups supported software product development groups where the organizational culture had already accepted Agile for software development and they were applying it in that context. Their circumstances made for an easier persuasion effort to get organizational leadership buy-in or customer buy-in.

One lesson was that you don’t learn it all in one giant effort, but learn a little here and a little there. Confidence in executing Lean-Agile has to be learned from doing it. The most successful ways of communicating it to influential team members, internal leadership, and buyer stakeholders has to be mastered in parallel. Technical expertise alone is not enough to facilitate a large organizational change management effort. Communication plays a big part. Listening to detractors and finding answers to their objections was important. Listening to team members struggling to learn it and apply it has led to insights about how to modify our training for team members and to some modifications of our current methods. We continue to learn and improve.

Another lesson is to measure the Lean-Agile approach from start to finish and compare metrics.


Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview