I received a notice in my in-box the other day about a new self-published book that discussed the idea of something called Lean-Agile Courseware by Raytheon. It turns out the book is nonfiction business book about applying Lean and Agile principles to the development of learning-related projects. I was intrigued by the idea since I explored a similar concept in my Gamification book in a section called “ADDIE vs. SCRUM” so I wanted to talk to Raytheon and explore there take on the subject a little more. So I chatted with a representative from Raytheon about the concept.
If you are interested in a copy of the ebook (and it’s worth reading) you can download a copy of Agile Courseware here it is available in ePub format and it has the following number ISBN 978-0-692-66522-0.
Kapp: You’ve just released an eBook called Lean-Agile Courseware, what is the book about?
Raytheon: The book is our effort to illustrate how the Learning & Development community can use the principles from Lean and Agile and apply them to learning projects as a project management approach. The book is a direct translation of Lean-Agile principles into the training domain.
Though these principles aren’t new, coming from the disciplines of software development and manufacturing, we have found they also help us get gains similar to what Lean and Agile have provided for software and manufacturing for the last 10-25 years. We think that both buyers and producers of training can gain from this way of managing the development of these increasingly software-driven components.
We also address what we have learned about how Lean-Agile impacts traditional ADDIE (Analysis, Design, Development and Evaluation).
Kapp: Is this Lean-Agile approach appropriate for all instructional design from mobile to MOOCs?
Raytheon: We emphasize Lean-Agile as a project management approach rather than as a singular instructional approach. So rather than attempting to triggering arguments about Lean-Agile versus ADDIE, we propose that the family get the new Lean-Agile sports utility vehicle in addition to the reliable ADDIE car. Having both in the driveway helps us do more. We don’t think it necessarily has to be a one-or-the-other discussion.
Having said that, we find that the Lean-Agile approach works any project, and especially well with high complexity projects. Mobile involves the newer technologies of the HTML5 family of technologies, and Lean-Agile works well. Lean-Agile can work for 3D immersive game-engine based learning experiences. It can work for game components in blended instructor-led training. We know Lean-Agile works for eLearning, what the US Government calls interactive multimedia instruction. We also think it will apply to innovative uses of xAPI data to measure job site performance and learning transfer.
Many technology components of learning experiences have design and development process pipelines that are much more similar with software process 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.
We have not done MOOCs yet, but we have tried to follow the work of EdX and their MOOC successes. So speculating, I’d say Lean-Agile could also work for MOOC development too. Our experience mirrors that of the co-creator of Scrum, Jeff Sutherland, who wrote Scrum: The Art of Doing Twice the Work in Half the Time. He proposes that Agile Scrum is so groundbreaking that it can apply to any complex project. Based on what we’ve learned, we’d have to agree.
Agile emphasizes prioritizing as we go, rather than trying to predict everything up front in detail, allowing flexibility and lower risk on projects with more challenging content and functionality for interactivity.
Where it may yield less benefits is with a single learning professional. But for teams, it has helped us a lot.
Kapp: Can you give a quick example of how Lean-Agile has been successful in a course design project?
Raytheon: Before answering this question, I would distinguish a bit between design and development because we have found Lean-Agile very successful in development, and we’re still learning how to do it well in design. The book includes an entire chapter on the challenges of course design using Lean-Agile.
Design includes various constraints. For example, total length of the course. Another example may be a customer, whether internal or external, who is new to Lean-Agile and still approach their design involvement from a traditional define-everything-in-detail-up-front mindset rather than minimum viable design up-front. We have found we have to adjust to a hybrid approach on design for now that spans some Lean-Agile and some traditional thinking.
For course development, a good example of success was an eLearning project where the team built a course that included learning objectives aimed at behaviors the learner had to perform at their job. The team developed the activities and text and still graphic content. This project also included complex branching scenarios that behaved depending on the learner’s decision choices. The team’s Lean-Agile board showed the team’s progress, the daily standup meetings highlighted any issues that came up immediately rather than a few weeks or a month later as has happened in the past. The focus on a small courseware “increment” rather than the entire course or a whole lesson was an adjustment initially. The team self-organized their work by pulling the next highest priority work item from the iteration backlog. The instructional designer still applied their expertise to create appropriate learning experiences, but they did so with a single learning objective at a time, and only for those LOs included in that two-week iteration, rather than designing an entire lesson or course at once.
So the ID pulled the LO work item card, designed the activities and minimal content to support the new behavior the customer wanted. The media person pulled the work item for added supporting media. The training developer built out the branching interactivity for the LO. After a two week iteration, the team conducted a synchronous review with the customer stakeholders of nine LOs as working courseware. The feedback from the customer review and our demo of working chunks of the course changed the team’s approach for the next courseware increment in the following two weeks. The entire team was excited to hear the customer stakeholder’s reactions to their hard work. The customer stakeholders were happy to see during the next iteration we had already adjusted to incorporate their feedback into the next courseware increment. The team learned to optimize the work flow for the team’s performance rather than sub-optimizing for a single person.
Kapp: The learning and development field has traditionally been slow to change, do you have any ideas for accelerating the adoption of the Lean-Agile Courseware concept?
Raytheon: The adoption of a new approach can sometimes take a while to spread. Neither Lean nor Agile were invented by the L&D community. However we’re seeing Lean-Agile spreading in Marketing, Technical Writing, as well as more L&D groups. Agile has already impacted most IT and software organizations, and is still growing in use in that discipline. Lean is already used in most manufacturing organizations.
To accelerate the adoption of Lean-Agile, we hope that our book sparks discussions among practitioners and, more importantly, experiments by L&D practitioners (both producers and buyers).
Organizations that buy training can identify small projects with which to experiment. We propose that even small L&D teams can run small, low-risk local experiments with Agile Kanban that require nothing more than some office supplies like sticky notes. As they learn, they can move to other experiments with Agile Scrum. Don’t wait for the entire company to adopt Lean-Agile. Make a plan, try an experiment, check the results data, adapt your approach, and try again. Use your data to help convince as you need wider support for wider implementation. Adapt and adjust as necessary
We tried to provide enough detail so that others can apply the principles to develop practices that are fit to their own purposes. There are large numbers of Youtube tutorials on how to apply Agile methods. So far, I’ve counted over 980 books about Lean and Agile, though most apply it in a software or manufacturing context.
As a word of warning, be cautious simply copying (as producers), or requiring (as buyers) someone else’s Lean-Agile practices without understanding the principles involved well enough to tailor what you do for your own unique context. Mimicking without understanding can actually increase your risk. Set expectations that the Learning & Development translation of the principles of Agile and Lean into the L&D domain may not always match one-for-one with the application of these principles in software, manufacturing or systems engineering. Similar to effective communications between two human languages, there may not always be a literal, one-for-one translation. This expectation management is especially important if the training group supports a software organization. Also be cautious of those claiming that their way is the only “right” way to do it.
Based on our own experiences, we’d recommend that organizations that want to test Lean-Agile be sure those people involved translate Agile principles into a training-perspective and adapting them to what works for training professionals. Be prepared to explain to stakeholders and SMEs any changes to their expectations and the rationale.
And lastly, we recommend making sure your customer on board with the Lean-Agile approach. Expectation mismatches can be a big obstacle to successful Lean-Agile projects.
Kapp: What advice could you give my students as they enter into the field of e-learning and instructional design?
Raytheon: In our view, a growth opportunity exists for instructional/Learning Experience (LX) designers to keep up with the fast changing world. Monitor other domains beyond training for ideas that can help make our instructional efforts better.
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.
Historically, our collective thinking about training 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.
Now consider that as training technologies get more complex and more coupled with software, the conceptualization and consequent labeling of training may 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.
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 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. We think this is a growth opportunity for instructional/LX designers.
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 applying Lean-Agile well can help you succeed.
If some have no initial interest in the “technology stuff,” then network with those who do and borrow them on your Lean-Agile project. Over time, just by watching the team board as work item cards move across it during a project, you will gradually gain a working knowledge of the development process for various technology components, increasing your value as instructional/LX designers.
Kapp: Thanks! Really interesting information. I appreciate your taking the time to share.