In our experience, many people leading training projects tend to have high skill levels and expertise in effective learning and development (L&D) approaches. In many projects, instructional/LX designers lead teams. Given the ends (learning outcomes), it is often appropriate that instructional/LX designers guide the means (design and development).

In our view, a growth opportunity exists for instructional/LX designers to keep up with the changing world. Rather than tending to focus all of your skills and knowledge in the workplace training domain, make room for monitoring ideas in other domains that can be applied to making instructional efforts better. For example, monitor the software development domain for practices we can use. Having interviewed, hired and worked closely with many instructional/LX designers, we have noticed that some seem more able and willing to visualize the processes for development of critical technology components of training solutions. These instructional/LX designers demonstrate more mindfulness to how the effectiveness in the design and development of technology components can impact their instructional purposes. Interestingly, the instructional/LX designers that demonstrate this also tend to request the more complicated challenges.

A Conceptual Framework for Categorizing Technology Components

Before we get deeper into how Lean-Agile can help us incorporate technology components, let’s take a moment to describe an analogy that can provide a conceptual framework for categorizing these technology components.

As you fly to your next course conduct or vacation destination, consider that the wings of the plane you’re in provide lift as they are propelled through the air (because the wing’s shape affects the speed of the airflow, which causes lower air pressure above the wing, or lift). Next, look out of your airplane window at that wing and note that the air flows over the wings, first passing the leading edge of the wing, traveling along the wing, and leaving at the trailing edge of the wing. Let’s use this idea to describe our relationship to technologies in training. If we look at training as the wing and technologies as the changing airflow, then we can say the following:

  • Leading Edge - A particular technology is leading edge if it is just now being experimented with and adopted by early-adopting training organizations or by projects with budgets sufficient to experiment with unproven technologies.

  • Mainstream - A technology midway over the wing is mainstream, and most are using it.

  • Trailing Edge - A technology at the trailing edge may still be used because its implementation methods have become so optimized and cost effective. Trailing-edge technology has been mastered and has an affordable ecosystem of tools that we use to apply it.

Within this framework, we can now state that Lean-Agile is leading edge for the training discipline, but is already mainstream for the software discipline.

L&D Professionals Applying Leading-Edge Technologies for Learning Experiences

Historically, our collective thinking about training contractors/suppliers/departments has been primarily as a service organization, where experienced people are brought in to analyze, design and develop instructional interventions using trailing-edge technology components of mostly language and images, and relying heavily on human-in-the-loop assistance of facilitators in all instructor-led or blended learning experiences. Sometimes, contractors/suppliers/departments even get to implementation by conducting blended instructor-led courses, and it is even rarer that they get an opportunity to evaluate the effectiveness of the intervention.

Now consider that as leading-edge training technologies get more complex and more coupled with software, the conceptualization and consequent labeling of training contractors/suppliers/departments will need to shift from mostly services to a combination of products and services. Technology-facilitated learning experiences, in particular, are quickly moving to more of a product than a service, particularly when an organization performs fewer human-facilitated course conducts for an increasingly global employee workforce. Gains in the market share of computer-facilitated learning experiences are more frequently found in the workplace and education. Rather than being merely a semantics exercise, a product-oriented viewpoint can lead to a more effective mental model about individual contributors and leaders in training organizations. Mental models are more valuable when they more closely align with the real challenges learning experience development teams face on a daily basis. Mental models make the merits of different methods of approaching project management for learning experience projects, methods such as Lean-Agile, more easily recognizable.

More often, we are seeing a convergence of training development and software development practices for complex workplace training products that include larger proportions of software-driven components. Therefore, the time has arrived to recognize that only using single-discipline project leadership by instructional/LX designers can increase project risk, and we need to take steps to mitigate that risk. For example, consider leading-edge technologies applied in our learning simulations (products), game-engine based training (products), courseware user interfaces (products), and mobile applications (products). Consequently if we continue to ask instructional/LX designers for buyers and producers to step up to the front of multi-disciplinary teams to ensure the integrated whole still achieves the intended learning objectives, then these instructional/LX designer leaders will need increasing familiarity with how to lead the work of technology specialists in support of the overarching learning outcomes. This is the growth opportunity for instructional/LX designers.

What Others Have Done Where Lean-Agile is Mainstream

Next, let’s look at how lessons learned in the software domain since Agile took over their world more than a decade ago is relevant to buyers and producers of learning experiences. We may benefit from their lessons learned.

Traditional software development used a sequential/stage-based approach often called waterfall. This approach generally used what they call functional decomposition, where an application or a "system" was broken into sub-components (e.g. user interface component, database component, etc.) which were then implemented in parallel and integrated late in the project lifecycle for testing and delivery.[1] For this parallel approach to work, the up-front requirements specifications had to be locked down with change control practices [1] called configuration management. The requirements specification was supposed to perfectly match what the customer wanted, too. Then, reality happened, unanticipated changes occurred and late changes occurred anyway. Then, issues surfaced late in the project when all the decomposed components were integrated back into a single whole because the requirements had changed, creating much rework. This may sound familiar with training projects.

Today, many Agile software development projects decompose the system being developed into manageable sets of requirements, often called "features" or "user stories". The software product or system is segmented into increments of customer-valued functionality, and development work is organized around building these increments.

The software discipline has largely moved away from many components built separately in large batches and holding integration and testing until the end. Instead, they have moved towards building working feature-sets in smaller batches, integrating them and testing them earlier in the project lifecycle. Their discipline has now provided evidence of reducing uncertainty (management reads as risk), detecting defects earlier, resulting in less rework, and delivering early capabilities to customers (as opposed to waiting longer for a full-featured product).

Back to the Future - Increasing Technology in Training

Traditionally, much workplace courseware has been developed in serial, or lesson order, and depending on how far back we go, it was mostly text and two dimensional graphic art. Although not the main point of this book, also consider that most of our text has been authored, read encoded, into proprietary software application formats which adds risk and adds dependencies, tying us to the vendor’s decisions about commercial toolchain lifecycles and support. See [markup].

Historically for low-technology training with the work products being mostly text and two dimensional (2D) graphic art content, integration of such text and 2D art components was not really an issue, and the training profession did not then see the need to include the term integration in our training domain lexicon. See the glossary for what we mean by integration. Even as time went on, when the majority of training products were instructional support packages for trainers/facilitators to implement a course, we had no apparent need for other approaches. Sequential ADDIE waterfall worked fine.

Fast forward 40+ years with the accelerating pace of technology change and its impact on training. In addition to the typical content, technology often adds functionality that supports learning experiences. As buyers/customers want newer technologies blended into training, these technology components have tended to be built by specialists in parallel to the main instructional development effort. These technology components then need to be integrated into the overall learning experience with (a) traditional content checks and now (b) functionality testing to ensure the integrated components function together as expected and support the intended learner experience. Though training staff are not yet habitually using engineering terminology to describe their work, working in cross-functional teams means collaborating with people from other disciplines who use this terminology. Disciplines such as Systems Engineering, and Software Engineering already have many practitioners using Lean-Agile. This is one reason why L&D professionals should care about Lean-Agile.

In the training industry, before the recent apparent dominance of rapid development tools like Captivate, Lectora, Storyline, various software as a service (SaaS) authoring tools, et cetera, teams included specialists who built the "content player" if you will—​sort of like Apple built the iTunes player and the artists build the musical content. Before rapid development tools, instructional content was authored in various ways, but someone on the team had to "integrate" it all into a Sharable Content Object Reference Model (SCORM) bundle that included the content player and the content. When we want to go beyond the relatively few options offered by such rapid development tools for learning experiences, we will need to include other disciplines on our development teams. This is another reason why L&D professionals should care about Lean-Agile.

There are many factors that influence which technologies make it into our learning experiences. One constraint that will likely continue is that business leaders tend to look for evidence that training interventions are having an impact on individual performance and organizational objectives before deciding how many resources to allocate to training procurement and production. Pausing to look for proof of effectiveness is similar to playing the children’s game red-light, green-light with training budgets. This implies that we have to know the following:

  • How to manage projects that incorporate technology components in learning experiences

  • How to work with those experts that help create our desired technology components

  • How to run projects quickly enough so that learning interventions are timely to the current business needs

This need to increase our probability of success when using technology components in learning experiences is another reason why L&D professionals should care about Lean-Agile.

As learning and development continues to grow beyond low-effectiveness "telling is training" to learning by doing, technical requirements will continue to push us beyond our traditional comfort zones for managing these design and development projects. We say that Lean-Agile can help you succeed.

Buyers of training may ask producers to go beyond basic, trailing-edge technologies for blended components, eLearning, mobile learning and game-engine based training. They may desire additional leading-edge technology components that often have their own detailed design and development pipelines. This means that producers will need enough familiarity with the production processes to be sure the leading-edge technology components that support learning experiences are on track as well as the learning content.

Lean-Agile can help successfully manage these new technology components to successful completion, so we can build a timely, cohesive, whole learning experience that achieves the intended worksite performance goals.

Consider another external influence. The public schools in the United Kingdom are now requiring all students to be literate in software coding. Should this idea spread, then this changes both the training industry’s future contributors and all of our future customers, and their expectations. Some exposure to Lean-Agile may come at high-school level going forward, making it easier for training organizations to have the talent to deal with all the new functionality requirements (players, interactivity, simulation, etc.) that are desired in addition to the more traditional focus on content. This is another reason that L&D professionals should care about Lean-Agile.

Earlier training technologies have been full of production surprises late in their lifecycle and testing was sometimes fraught with late-night panic that the deadlines would be missed, not because of the solid instructional components, but due to the new, and often more fragile, or at least less well understood, leading-edge technology components. The team lead with an instructional/LX design background may not be sure what the problems and issues are and why the specialists supporting their project can’t solve the issues without delaying the learning experiences from working as expected by the deadline. Some technology specialists also have challenges articulating their process steps, progress and the significance of challenges to instructional/LX design leads as people that don’t have a hands-on level of understanding in all the details needed to implement this particular new technology component.

Perhaps that last comment sounds familiar to L&D professionals working with technology specialists. It may also work the other direction and sound familiar to L&D professionals struggling occasionally with customers or leadership that understands the big picture, but who are not as deeply fluent at the hands-on level with all the details that are involved with complicated blended learning experience development. We want to reinforce that they are knowledgeable, and the technical staff is expected to have fluency at the finer-grain level to be able to implement learning solutions that integrate technology.

How has expecting simple answers to the complex problems of our supporting specialists worked out so far? Lean-Agile helps address the complexities involved in technology-enabled learning experiences because Lean-Agile deals well with complex systems.

Examples of Technology in Learning

The following is a partial list of technologies demonstrated at recent tradeshows and by projects we have performed that require teams that include people with specialties that go beyond instructional/LX design. The effort of leading these projects successfully and reducing the uncertainty that comes with some of these components is enhanced with Lean-Agile.

  • Interactive video segments

  • Branching video stories

  • Deterministic branching decision scenarios to five or more levels

  • Non-linear editing of branching scripts for non-player characters (both development and review)

  • Complex animation

  • Complex interactions that are beyond the small library of widgets in current rapid authoring tools

  • Virtual classroom breakout session materials

  • eLearning, interactive multimedia instruction, web-based training or other names for computer-facilitated learning

  • Mobile learning native apps, web apps and hybrid apps

  • 3D avatar mentor characters that help facilitate the learning experience

  • Conformance to the eXperience API, xAPI (formerly Tin Cup API)

  • Innovative uses of xAPI data to measure job site performance and learning transfer

  • Accessibility regulations that insist on equivalent facilitation for disabled learners

  • Game engine user interfaces

  • 3D models of people, equipment and facilities

  • Process simulations with user interfaces

  • Soft-skills simulations with user interfaces

  • Probabilistic (stochastic) discrete event simulations in support of learning

  • Systems dynamics simulations (see The Thinking Effect, by Michael Vaughan for more details.)

  • Software models for realistic system simulator behaviors for operations and maintenance training

  • Immersive environments used for virtual skill assessment based on doing rather than knowing

  • User interfaces with user controls so the learner/player is in control of the experience

  • Blended designs that require the instructor/facilitator interface to let the facilitator stop or pause the technology component briefly to address observed learner confusion

  • Embedded training for simulator operation and maintenance that is built into the simulator as tutorial levels rather than as traditional stand alone training

  • Networked simulators

  • Adaptive learning systems based on an adaptive engine that compares learner performance against predictions and automatically adjusts what comes next based on performance

  • Holographic visuals in simulators

Many of these technology components have design and development process pipelines that are much more similar with software pipelines than with traditional training pipelines. This is one of the reasons for this book, because Lean-Agile works very well for these training pipelines.

Due to their complexity, many of these technology components take longer than a single two-week iteration to complete. This means we need to know where reasonable break points exist to divide the work into smaller work items that can be completed within a single iteration to show progress.

Occasionally, technology components require discovering how to implement, especially those technologies closest to the leading edge.

Sometimes, we put our head in the sand and treat component creation as black box components that go to specialists with vague storyboard descriptions or requirements specs. With this approach, there is almost no interaction until the specialist creators are done. This approach means we can be surprised at the end of their estimated allotment of hours with the binary situation of problems (0) or success (1). Some will prefer to accept this increased project risk, while others will use Lean-Agile to mitigate the risk.

We propose that you consider managing the entire design and development of technology components visually on a Lean-Agile Kanban board, so you have insight on their progress earlier in their life cycle. Schedule internal iteration reviews/demos of working chunks with you as the customer to help you reduce the uncertainty to the rest of the learning experience.

For a more detailed view of where the future of training may be going, see Learning by Doing, by Clark Aldrich, and the realistic training simulation approaches described by Michael Vaughan in his book The Thinking Effect: Rethinking Thinking to Create Great Leaders and the New Value Worker.

Lean-Agile as a Means to the Ends

Lean-Agile visual Kanban boards can help buyers and producers see their workflow process steps and see the progress of work items in process. It can also help L&D professionals gain more awareness of what is involved in making X or Y leading-edge technology components in support of learning experiences. This can increase their capacity to realistically assess feasibility, report progress to leadership and see when issues are occurring, which offers opportunities to bring in additional resources earlier.

Lean-Agile provides benefits to modern buyers and producers of training products:

  • A way to improve our own cycle times

  • A means of gaining visibility into complex technology components that are in process

  • Visual signals for when "get well" interventions are needed

  • An environment that provides more information without micromanagement

  • Improved chances of leading successful projects

  • Smaller chunks of working learning experiences are produced earlier in the project

  • Reduced uncertainty from the technologies injected into the learning experiences

Most software developers already know Agile, and some may know Lean too. As we all use Lean-Agile to develop both the instructional activities and the supporting technologies for interactivity levels and engagement, we can get to the delivery date with less panic and more trust that our instructional/LX design will accomplish its goals.

None of this reduces the hard work of instructional/LX designers. Developing effective learning will continue to be challenging.

So, this book attempts to show how we can use Lean-Agile in learning experience development to reduce risk and uncertainty, to build learning experiences, even with new and complex technology components, in small working increments as we go rather than waiting until later in the process to see large batches of scope and discover whether or not they work.

1. Reproduced with permission from Firas Glaiel, Allen Moulton and Stuart Madnick from their paper, Agile Project Dynamics: A System Dynamics Investigation of Agile Software Development Methods, by Firas S. Glaiel, Allen Moulton and Stuart E. Madnick, 2013.

Line By Line

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

Back to Overview