Lean-Agile principles apply well to development, and we have experienced much success using it in development efforts. Yet for designers, applying Lean-Agile principles is still a work in process.
In the software domain, sometimes many of the important design decisions have been pre-determined by choices of operating system servers, programming language, database, etc. In the learning and development domain, instructional/LX design happens on every single project.
We have found it more challenging to apply Lean-Agile to the design portion of ADDIE. Historically, training projects started with a course design document (CDD). Depending on the organization and their process orientation, we can build the CDD with revision one and two, or draft and final, but our experiments with Lean-Agile have not yet yielded a great solution for design that has helped us convince buyer/customers to abandon big up-front designs of the entire course. We have tried to persuade customers that desire a CDD to allow it to be course-level only design—meaning mostly scope and sequencing of LOs, and assessment strategies with generalized instructional/LX design strategies—at this point in the process and leaving all the lesson-level design—meaning specific instructional/LX design strategies to implement the enabling learning objectives—to be distributed across the iterations, with each iteration having some design effort and some development effort. However, we have not convinced all customers to adopt a more Lean-Agile design approach. Some want an up-front big picture or blueprint of the course. Some want so much detail in their up-front CDD that it is almost a storyboard, just shy of screen-level/page-level details.
Recently, we have also noticed an emergent and promising possibility for making learning experience design more visual (Lean), flexible and easier to communicate with stakeholders for earlier feedback loops (Agile). It is called the Learning Environment Modeling Language (LEML). LEML also seems to offer a usable path to a minimmum viable design. For us, applying Lean-Agile principles to design efforts and getting customers to agree is still a work in process.
Traditionally, design is messy and hard to describe already.
For some, the greatest diagram of the design process was made by Damien Newman and is shown below. His diagram helps other people get immediately the initial messiness and nonlinearity of design.
Eric Ries talks in detail in his book Lean Startup about how early on we should iterate experiments to learn what the customer will pay for. Designing learning experiences can use that approach too.
We think Damien Newman’s design diagram captures well the degree of effort trying to test our set of customer value predictions in the research and concept sections of his design process diagram. Often, the discovery of what the customer really values for learning is the largest constraint initially. Sometimes this discovery constraint creates a traffic jam in the project execution until both we and the customer collaboratively reach clarity on their value demand—what they most want and will pay for. Iterations and feedback help. We will talk more about constraints and their impact in the section about the Theory of Constraints. The asserting, experimenting and learning process applies to designing learning experiences both in mature companies and in startups.
Our experiments with Lean-Agile for design indicate a need to change your relationship with buyers/customers. Moving to Lean-Agile means a big mental change and different process steps for both customers and your development team. Rather than thinking of only delivering perfect, detailed, high quality designs built over longer design calendar time durations, work out a shorter design cycle with customers at the beginning of the project.
Unlike the functionality of eLearning, learning simulations or mobile learning, the design effort is not as easily decomposed into small similarly sized chunks. The design process characterized by Newman’s figure shows that the work breaks down to research/discovery with much initial uncertainty and then insights and concept/strategy gain clarity, which is followed by focus for the design.
The instructional/LX design work breakdown may include analysis discoveries first, then learning experience discussions. Then if creating a CDD, perhaps, go to scope priorities and sequencing consensus on proposed learning objectives (LOs) and your proposed assessment strategies. Next, conduct instructional strategy collaboration meetings with your stakeholders and subject matter experts. Then, write it all up in a CDD to preserve what emerged from all the back and forth.
Trial and error indicates one alternative that does not work well is surprising the stakeholders and SMEs by disappearing for long periods of design time and then delivering an entire design with little or no customer input. Customers often want to feel a part of the design effort, and leaving them out of design does not play to their desire to help shape the outcome of the training intervention.
A too frequent reality is that customers may not be completely sure of what they want from the start due to changing conditions and stakeholders. Customers gain a clearer understanding as we propose solution ideas and rough sketches and verbally paint pictures. Or better, demonstrate low-fidelity prototypes. Emerging customer desires are why the Lean-Agile adaptive-versus-predictive approach has succeeded in the customer’s transition to clarity. The customer’s environment not static and external demands on your buyer/customer stakeholders may change during the project causing their needs to change and what they want from the learning experiences to change too. So theoretically, if there are more small cycles of collaborative design exchanges of ideas, then changes are easier to accommodate. Customer availability impacts more frequent cycles in real projects. Set expectations that the Lean-Agile Courseware approach requires the customer’s engagement beyond just the kickoff meeting and the final review.
When customers are not paying for learning experiences, they often want courseware yesterday. When customers are paying for learning experiences, they often want a fixed scope up front before they start releasing more money. Try describing Lean-Agile as the children’s game red-light, green-light. The customer gets to say red-light and stop and see an increment and inspect it before saying green-light to release more money to begin another iteration. Although a new approach, they actually have and feel more control and less risk because they too get more feedback earlier in the project lifecycle.
Customers also expect a coherent courseware vision for effective learning experiences. A coherent vision benefits from some up-front identification of scope boundaries, design constraints, assumptions and desired outcomes of the intervention.
As a side note, working for a smaller training group as a cost center inside an organization making training interventions for organizational members may not require as formalized of a design approach as business-to-business and government contracting. In some circumstances CDDs can be seen as the Lean waste of overproduction, also called gold plating.
Agile software domain practitioners call their equivalent to CDDs a Big Design Up Front or what in the ADDIE domain we often call the Design Phase. Traditional recipes for design typically call for the ingredients of research, ideation and time to craft a carefully synthesized long-term vision for the courseware product. In contrast, Lean-Agile development iterations tend to focus on the next two weeks.
The design effort is typically a scheduled time period where designers can take the project requirements and ideate, often at length, over how the solution will align with and solve the customer’s problems from the training needs analysis. Instructional/LX designers will explore optimal ways of writing LOs, strategies for assessing LOs, and then various instructional strategies to achieve each LO.
Designers new to Lean-Agile may initially protest that the fast-as-possible principle does not give them enough time to think about the solution, and some may say it is not possible to turn around a design in shorter periods. If you’ve set the conditions with the Customer and internal management to expect multiple smaller design cycles rather than one giant step for design-kind, then it becomes key to focus hesitant designers on only one design cycle’s scope of design work.
|If you can get the customer to agree that working courseware increments replace document artifacts as the primary evidence of progress, in the contract if necessary, it can go a long way to helping manage expectations. If you have to use a CDD, an important distinction is the level of design detail. Our experiments indicate that it helps if you set expectations contrasting the high-level design (CDD) being minimally detailed—or dropping design up-front and distributing it throughout the iterations—against the detailed designs, called storyboards.|
Customers that are familiar with ADDIE and traditional approaches to training and learning interventions may have expectations of comprehensive, large-batch CDDs up front, rather than a more Lean-Agile skeletal design framework to be fleshed out in detail during the smaller-batch design cycles that are distributed throughout the project in iterations.
The key mindset obstacle is historically large batch designing and storyboarding of the entire course before development ever starts. Teach customers that small batch courseware increments let them see a completed, ready-for-learners increment earlier, which helps them decide how closely your idea of a learning intervention solution matches their sense of the training need, which may be changing as they gain clarity on what is wanted. Help the customer understand that large batch storyboards (the entire course) are still subject to misunderstandings as humans encode one person’s mental model to words and another person decodes the words and attempts to form their own mental model. Like the children’s game of passing a message down a line of multiple children, what comes out the end is frequently not what went in. Seeing a small chunk "done" makes it harder to mismatch the mental models because the "done" increment is in its final form for learners. Small batches mitigate the risk that occurs when customers are waiting on a large-batch storyboard. Small-batch increments improve clarity between customers/buyers and developers earlier in the process.
Here we often explain that a model is a representation of our current understanding. It can help to make use of low-fidelity visual models—any visual representation of our current understanding—to provide focal points for discussion and to help build shared understanding.
Storyboard design, if required, can be addressed a little in this iteration and a little more in the next iteration. CDDs are typically frozen upon approval (also called configuration managed) and are more difficult to change, often with contractual requirements in play. Instructional/LX designers who are used to design-once-and-cast-into-concrete may relax somewhat when they realize they don’t have to design the entire storyboard at one time, perfectly. Lean calls this just-in-time design.
|If designers get too far ahead of the development team in storyboarding (detailed design), they may introduce Lean waste of context switching after they’ve moved on from that LO, as well as if the customer priorities shift or other changes occur. In Lean-Agile, we’re optimizing the entire team, not the individual designer’s process. Also with the Theory of Constraints, the instructional/LX designer, and game designer if that applies, become(s) the drum beat to which all the other process steps should march in concert because instructional/LX designers and game designers tend to be the primary constraint.|
Perhaps you can convince your customer at the start to go as light as possible (skeletal) on the detail of the high-level design/CDD or convince them to push the up-front design effort into the iterations. But in some cases, ADDIE-aware customer leadership experienced in waterfall may not agree, so be as Lean-Agile as you can given your context. One way to propose this for fixed price work is, "You get X amount of work effort (size points, hours, etc.) and any change is okay as long as you swap out an equal amount of lower priority work to replace it with the newer change."
|Fixed-price contracts generally do not support changes inherent in Lean-Agile as well as Time and Materials contracts.|
Another way to operate in Agile is to use what the software domain calls the Minimum Viable Product. This minimum idea is anathema to many designers. They have designed robust learning experiences that demonstrate their years of training and experience. The idea of releasing an experience that is streamlined or "good enough" feels like low-quality. You can coach your customers and designers into an experimenter mindset. Each iteration is an experiment to test our hypothesis that our design increment will meet their training need or problem, also called value demand in Lean, and is fit to purpose. Most of designer’s professional training is to do the "big picture" design in one large batch up front rather than a Lean-Agile series of lighter weight, smaller batch, cycles of design where the customer gets to inspect and adapt, and everyone involved gets earlier feedback that validates the potential of that design chunk.
Another approach is to build on the familiar. Instructional/LX designers and many customers are already familiar with the idea of pilot testing courseware, so iterative design can be described as a series of mini-pilots for the same purpose: to gather feedback about the degree to which that chunk is fit to purpose. This is the PDCA or Deming Cycle.
Use a new minimum viable design question, “What is the least amount of courseware product we can design to determine whether or not this approach is valid?”
This question uses the Minimum Viable Product as a form of customer research. Who decides what is minimally viable varies (Instructional/LX Designer? Customer? Lean-Agile Product Owner? Contract provisions?). Collaboration is key. By including the instructional/LX designer in this decision, you can increase their comfort level with releasing what they may feel is an incomplete courseware product.
Another challenge in applying Lean-Agile to design is that Lean-Agile encourages a steady cadence and flow.
Agile iterations are planned to create a steady development velocity, but designers don’t always benefit from the same uniformity of workload.
A steady cadence can be difficult for designers because their design effort is so often not initially a smooth linear flow. Damien Newman’s process of design drawing is superb for helping communicate this unevenness of research, concept and design. It is challenging to account for the initial research and the associated design uncertainty with Lean-Agile. Iteration zero may help. Michael Allen’s SAM method advocates design iterations with multiple prototypes—which can work well when the customer agrees to multiple prototypes. Interactive paper prototyping is quick and inexpensive—to the degree you’re able to keep it constrained to low fidelity—and it facilitates Lean-Agile more easily than static CDD documents and static storyboards.
Fortunately, we can learn from other fields. Filmmakers operate in a similarly agile fashion, filming scenes in an order dictated purely by logistics. To ensure vision, coherence, and narrative continuity they employ specialists: directors and script supervisors.
Learning simulations and serious games also chain together player experiences into entire player journeys, often called missions and campaigns to achieve learning outcomes. CDDs and static storyboards don’t reflect well the dynamic experience of technology components for learning. In courseware, the CDD behaves like a movie script, attempting to chain together work items (or user stories for simulations and games due to the software developers on those projects already being familiar with terms for work items from the software domain) into whole journeys that can be tested for cohesiveness. This approach can reveal much about a learner’s overall experience and can expose gaps missed with the heads-down iteration focus.
Another factor that recently impacts instructional/LX design is the multiplicity of screen sizes. Historically, the page was the atomic unit of courseware, but no more. HTML5 responsive design for mobile-first designs automatically reflows page blocks into wide-screen multi-column formats for PC screens and large tablets and into a thin-screen single-column formats for mobile devices. Web and mobile app users now expect this behavior. When these users become learners, they expect it in learning apps and courseware too. So instructional/LX designers should move beyond the page construct as the organizing principle and move to learning experiences instead.
One of the L&D industry thought leaders, Cathy Moore, developed an alternative instructional/LX design model called Action Mapping  for designing learning experiences may better fit Lean-Agile than CDDs. Using Cathy’s Action Mapping for design iterations means we can cycle through the goal, to the actions, to the activities and the content. Action Mapping is better suited establishing the courseware vision and iterative design than a Big Design Up Front approach with CDDs. Cathy’s approach supports minimally detailed planning up front and still provides a coherent big picture skeleton upon which to flesh out the details during the courseware development iterations. Her approach also supports minimum viable product courseware by filtering out unnecessary content. In our experience, CDDs tend to encourage extensive documentation as the primary measure of progress rather than working courseware increments.
Interactive working prototypes are also better than static document-centric design increments. Game and simulation prototypes have to be play tested to see the dynamics at work, creating the overall effect and player/learner experience, and to validate it against player experience goals and learning objectives.
More and more learning experiences are enabled by software, which is why we borrow relevant ideas and patterns from the software domain for courseware product development. So we can learn from user experience (UX) designers in the software domain too. UX designers use low-fidelity sketches and paper prototypes as ideal fast and cheap experiments for sharing design ideas and exploring discussion points. Fail-fast-and-learn patterns still seem infrequent in instructional/LX design practice in corporate and government training. Some instructional/LX designers primarily see the world from the left-brain, text-oriented design depictions and models. We can reduce misunderstanding waste by tapping more into the right-brain, drawing/visual-oriented design depictions and models. The encoding of the designer’s mental model into the low-fidelity format of text has to be manually decoded by the readers/stakeholders/customers, and the mental model that they form is often mismatched from the designer’s mental model, while both parties may think we’re all aligned. This increases risk and delays its discovery and resolution until further into the product development lifecycle, costing more for the customer (if variable priced) or for your organization (if fixed priced). Drawing/visual-oriented design depictions and models encode the designer’s concepts in a way that takes less effort by the viewer to review and often can lead to a better grasp of gaps or differences in mental models and provides an improved focal point for discussions.
A picture is worth a thousand words.
User experience designers also have to iterate their design work.
By sketching quickly and often, UX designers rapidly iterate on their work while building up a paper library of components, buttons, navigation elements, drop downs and so on.
Instructional/LX designers and game/simulation designer teams can also apply this successful pattern building up their own paper library of UX design components needed for courseware, games and simulations.
Showing solution components early and often can feel uncomfortable initially and it helps become Lean-Agile.
In summary, how far you get with Lean-Agile design has more to do with persuasion and negotiation skills than with Lean-Agile techniques. Adjust for your negotiated context, applying as much Lean-Agile as possible within your constraints.