Some organizations will be so set on the traditional waterfall methods that it may seem like antibodies are out to kill off the Lean-Agile effort before it builds any strength.

Succeeding in this environment requires getting the organizational leadership on-board with the idea. Either build a skunk works, protected from normal processes, or ask for a waiver on the first attempt to see what it does as an organization-level experiment.

At the beginning, you may not be successful in getting all that you want. Other times a customer may balk at Lean-Agile even if you won your own leadership support.

So if squeezed into a waterfall method, it is still possible to use some of the Agile and Lean principles even if you cannot do it 100% off the starting blocks. You may have to make adjustments and phase in more Lean-Agile as you have success and increased credibility.

The Lean visual management principle improves team synchronization. We have witnessed that and validated it is an improvement.

If you choose a stealth approach, Kanban does not have to include the customer or even organizational leadership. You can implement it without any change to your existing processes. Then, get it working and show an achieved success.

If there are phases of your process that only involve a single person, Kanban may not add enough value to use it until later in your process where two or more people are coordinating their efforts.

Another area of difficulty is schedules. If you get the okay to attempt Lean-Agile, schedule down to the iterations and stop if possible. Your iterations may include at a minimum:

  • Iteration Planning Meeting

  • Delivery of iteration goal (list of scope to be done during the iteration)

  • Iteration Design/Development

  • Iteration Review/Demo with Customer stakeholders

  • Iteration Retrospective

If your organization expects the use of historical metrics to estimate the work durations for the schedule, then you may have to use a combination of historical metrics and team estimates, or all historical estimates and no team estimates. Do what you can and prove it is helpful in order to get the credibility to ask for the room to implement more of Lean-Agile on the next courseware project.

Often times customers still expect the traditional deliverables such as:

  • Course Design Document

  • Prototype

  • Storyboards and Scripts

  • Working courseware package or instructor support package

You may have to do some explaining about what changes in a Lean-Agile project.

Courseware Design Document (CDD) Adaptations for Lean-Agile

You may be able to successfully explain that a CDD is a so-called big requirements up front approach that is inherently waterfall, and you may be able to convince the customer or your leadership to skip this deliverable completely and instead perform the design effort in chunks distributed across the iterations.

Or you may have to create a CDD up front. In which case, you may have to skip fixed time box iterations until the CDD lists all the learning objectives, sequences them, shows the instructional strategies planned and describes the evaluation strategies planned. See the section on Lean-Agile Design for more detail.

Whether or not you can align the schedule into iterations and make the scope negotiable depends much on your current business processes like customer negotiations, contract processes, etc. if you make work for customers to buy. For internal projects, it depends on how well you persuaded the organizational leadership. If possible, get into the contract or the leadership expectations that scope will include the highest priority work items, so that each iteration you are working on their highest priorities.

If unsuccessful at this, you may be trying to hit both fixed schedule with iterations and fixed scope. The customer may expect that all of what they want in the courseware gets included. You can still use prioritization.

If the customer does not agree with the prioritization approach, or fears confusion among their stakeholders, or just wants it another way, they may ask that you deliver courseware increments in the traditional order such as Lesson 1, followed by Lesson 2, followed by Lesson 3, etc. If this happens, then your prioritization is set when you decide at design time which learning objectives go into which lessons. You will still need to help them understand that some work items may get shifted to adjust to changing circumstances like SME availability, for example. As long as they get their way in the rule, then they don’t seem to mind so much that there may be some exceptions.  

Some customers and training leadership are hesitant to give up their traditional up-front blueprint CDD, so you may have to adapt using less Lean-Agile for the CDD and more for other parts of the development process.

Another option is to adapt by including multiple cycles of two or three days each, rather than standard two-week fixed time box iterations, for building a CDD because CDDs typical expectations are often for CDDs to be done in a period of a few weeks. You may need to adjust how much time can be allocated to the CDD, depending on the length of the courseware. The following is an example of what could be included, not a prescription of what you have to do.

The following design descriptions are illustrative rather than exhaustive.

Design Cycle 1

  • Review the formal training project statement (states the training needed to meet the requirements—What, Why and When).

  • Review any products of the Training Needs Analysis (TNA) or other information-gathering results from customer meetings.

  • Identify achievable LOs and their grouping and sequencing.

  • Identify enabling objectives and key learning points, if applicable.

  • Identify any instructional/LX design factors and constraints.

  • Collaborate with SMEs.

  • Document the design consensus in the CDD (to avoid surprises).

  • Conduct synchronous customer review of CDD increment #1 (Purpose, LO scope and sequencing).

Design Cycle 2

  • Incorporate customer feedback into CDD increment #1.

  • Identify the assessment strategy to constrain what is assessed and how (formative diagnostic progress assessment, type of test, summative assessment of each TO/CTO, associated checklist for reliability and objectivity, pass/fail grading, remedial training strategy, and record keeping).

  • Determine the appropriate blend (technology-enhanced learning [mobile, eLearning, immersive virtual simulations, adaptive learning intelligent tutors, etc.], devices[desktop, part-task, full-task, simulators], social, human-facilitated [classroom, virtual classroom).

  • Identify delivery options and the design selection rationale.

  • Select methods and media (including any constraints that may limit options) for implementing LOs.

  • Associate lessons to related groups of LOs.

  • Specify the course (course and lesson/event titles, related LOs and dependent key learning points), administrative notes (duration, location and essential references), support expectations (handouts, exercises, equipment) and risk management (assessment and mitigation).

  • Estimate delivery duration.

  • Collaborate with SMEs.

  • Document the design consensus in the CDD (there shouldn’t be surprises)

  • Conduct synchronous customer review of CDD increment #2 (assessment strategy and LO instructional strategies).

Design Cycle 3

  • Incorporate customer feedback into CDD increment #2.

  • Conduct synchronous customer review of the design/CDD.

  • Negotiate course scope and implementation features if the contract allows Lean-Agile adaptation instead of waterfall prediction of schedule.

  • Incorporate customer feedback (if still required).

  • Obtain customer acceptance of CDD (if required).

The point is to use an iterative approach to the courseware high-level design, if you got customer buy-in before starting.

The preceding is still hybrid Lean-Agile. To the degree you can convince customers to go 100% Lean-Agile, you may not need the entire design done up front.

Prototype Adaptations for Lean-Agile

Much of how you do the prototype depends on how much Lean-Agile you got accepted. If you were able to successfully negotiate iterative 2–3 prototypes then the first prototype will be a rough quality of finish, getting refined each iteration, as suggested by Michael Allen in his book, Leaving ADDIE for SAM.

However, if the customer insisted on a single prototype that is of high quality finish, then you may not have the option of more than a single iteration on a prototype.

Customers are less likely to misunderstand your intent with a working prototype than with the text-based CDD because they do not have to read your words and form their own mental image. Instead, they get to see your implemented examples of functionality. This idea of reduction of risk of misinterpreting design intent can help you in up-front negotiating.

Make functional prototypes your goal rather than using example content or lesson 1 content. This constraint helps to keep all the stakeholders focused on the delivery package rather than the contents during review at this point in the development life cycle.

If this particular courseware breaks no new ground, so-called "green field," then the prototype effort may go quickly. If however, you are exploring how to leverage a new technology or some other unproven method, then the prototype may take longer than prototypes for more established methods. If doing exploratory work, prioritize the hardest things first.

Storyboards and Scripts

If you were successful at negotiating a small-batch Lean-Agile approach over a large-batch traditional approach, then you may need to reinforce customer and leadership expectations at the storyboard/scripts deliverable. Historically, storyboards have been for large batches like lessons or entire courses.

The key for a more complete implementation of Lean-Agile on this deliverable is to persuade that rather than the traditional method, which is a large batch, of storyboarding the entire course, or even rather than the not similarly-sized (Lean principle) medium batches of storyboarding entire lessons at a time, that Lean-Agile is better served by smaller batches of courseware being storyboarded and scripted.

You may want to explain that the fastest cycle times will occur by working on a single learning objective small batch at a time. That the development team will address LO 1.1, and then LO 1.2, and then LO 1.3. That when the text for LO 1.1 is in the courseware authoring tool then that LO is storyboarded. Then the team will proceed past the storyboarding deliverable and build out the interactions and media for that LO. Be sure the customer understands at the iteration review/demo that we will deliver what we think is a 100% complete LO 1.1 ready for delivery to students/learners (use your customer’s preferred term).

We have found it helpful with many customer stakeholders to use a simple mental image that is easy to create. We use this image of Lean-Agile that shows the work items as miniature cubes in a block of cubes that resembles a Rubik’s Cube toy. But it is a great illustration to help people follow the piece-by-piece approach. We are building the final Rubik’s Cube with each iteration being a layer of the Rubik’s Cube a mini block at a time, and at each iteration the customer reviews the courseware increment or the layer of the Rubik’s Cube.

Figure 1. Rubik’s Cube Image of Agile during Development

Some customers insist that storyboards be text only in the authoring tool, for mobile learning and PC-based eLearning, and for instructor-led training the text-only instructor packages that include the presentation materials, instructor guides and student guides.


In our experience some customer stakeholders have not mentally adjusted to the speed increase in cycle time that happens by addressing a single LO at a time.

Early on in our Lean-Agile implementations, we expected the customer to look at the storyboards for each LO. If your scope is, say, 11 LOs in a single a two-week iteration, this means that the customer would have to look at 11 smaller storyboards. In real life, many do not. Instead they wait until the iteration demo because that is on their schedule. Even if invited to your Kanban board, they may not take the time to look daily because they typically have other jobs they have to do for their employer. This led to asking various customer stakeholders to consider their storyboard deliverable as met when the current 'state' of the authoring tool had all the text included.

For those that required a storyboard deliverable, this could meet their process requirements. Even if no review is conducted on a work item, the iteration demo may catch it. Although this kind of mistake could have been disastrous in a 'large batch' approach, the iteration courseware increment was a smaller batch of up to 11 LOs, so the degree of rework if any was minimized. Other work arounds are that the instructional/LX designer is collaborating with the customer’s SMEs daily while developing the ideas for how to implement each LO, so the iteration review was normally not a surprise to the SMEs at least.

The customer leadership needs to understand up front that the entire deliverable for storyboards/scripts will not be complete until all the increments are delivered. This adaptation can allow your team to still apply Lean-Agile and to still interface with others who are still mostly in the traditional training approach of large batches.

Another technology consideration is to use plain text files for storyboards. The developers can easily convert plain text to markdown or asciidoc, which is easily converted to markup. Plain text keeps the content developers focused on the content goodness and not on the layout and formatting. The ease of conversion from markdown text to markup in HTML5 or XML is exceptionally cost effective. For teams using rapid development tools, you’ll be stuck slowly entering content into form-like entry fields and markdown will not help you until the suppliers of those tools add a markdown text import method. There are very few products on the market that include semantic encoding of training product content.

Completed Lessons Deliverable Adaptations

For customers that require a specific deliverable that is some reasonable variation of completed, and working lessons, this may include fixing any feedback provided during the iteration demo.

By tracking change requests (CRs) or defects as Kanban work item cards, the entire team can literally see the scope of the technical debt incurred during iteration 1, so when iteration 2 is planned, they can adjust their scope to include finishing incorporating these changes into increment 1, and then working on iteration increment 2. As soon as we deliver increment 1 with all changes incorporated, then that meets the completed lessons deliverable for that increment.

This is where we’ve had the most push back from teams, so you may need to find a better solution here. Some people get frustrated adding a Kanban card for every customer change request, thinking it "wastes time." You may need to explain the value or find another way to make this change demand visible to apply the Lean principle. The customer leadership needs to understand up front that the entire deliverable for completed lessons will not be complete until all the increments are delivered. This adaptation can allow your team to still apply Lean-Agile and to still interface with others who are still mostly using the traditional training approach of large batches.

Takeaway: Do as much Lean-Agile as you can by degrees and avoid purist, all or nothing, binary approaches. Make your motto, "Data over dogma" as you experiment with what works for you.


Line By Line

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

Back to Overview