The following table depicts a brief comparison between Lean-Agile and ADDIE.

Think of the following table like a continuum with each column at each end of the continuum. Sometimes a hybrid solution is necessary that combines elements of both.

Table 1. Comparison of traditional ADDIE and Lean-Agile
Aspect Traditional ADDIE Lean-Agile Approach

Fixed

Scope (Requirements)

Cost and Time

Estimated / Negotiated

Cost and Time

Scope (content and functionality)

Emphasis

The entire course processed at once (large batch)

Small chunks of the course processed at once (small batch) as completed and working "courseware increments"

Drivers

Schedule driven, i.e. Plan-driven; often deterministic instead of stochastic (i.e. Monte Carlo methods)

Business value driven: Prioritization of scope by highest training value every iteration; scope juggling

Specifications

Up-front, detailed original requirements documentation

Requirements as the current courseware backlog item cards in current priority order

Desired functionality: Interactivity

Each interaction type described in documents

Each interaction type described in user stories and prototyped in early iterations

Design Constraints

Learning Objectives constrain content and functionality

Same, Learning Objectives constrain content and functionality

User Experience (UX)

Yes, for courseware interface

Same

Design changes

Minimized as risk mitigation

Emergent design okay if lower priority scope is swapped out to mitigate impact

Approach

Phased and sequential

Iterative and incremental

Up-front detailed plans

Entire project planned in detail

Short term work (first iteration or rolling wave) planned in detail

Up-front minimal plans

Not applicable, all planned up front

Longer term work (future rolling waves)

Proof of progress

  • Extensive documentation of desired courseware and process steps

  • Infrequent in process reviews of content and functionality

Working courseware increments every iteration (content & functionality)

Completed deliveries

At the project end (unless in-process reviews used)

End of each iteration

Size of work in process inventory

Large batch

Small batch

Size of work items

Large (course or lessons)

Small (lessons or learning objectives)

Amount of customer involvement

Distributed at the start and at the end of the project in large batches of time

Same amount, but distributed throughout the project in smaller batches of time

(same amount just distributed differently)

Frequency of customer feedback

Less

More

Schedule orientation

Stages or phases (design, development, etc.)

Iterations

Need for SMEs

During design and development

Same, during design and development

Risk impact if SMEs unavailable when needed

Higher costs, Delivery delays

That work item moved/swapped to another iteration to minimize impact

Response to change

Purposely slow and difficult process for scope additions

Purposely fast and easy process for scope swaps

Continual Improvement

Lessons learned from previous project/program implemented on next project/program

Lessons learned from previous iteration implemented on next iteration

Budget

Yes

Yes

Stakeholder identification

Yes

Yes

Role clarification

Yes

Yes

Approvals as risk mitigation

Formal hierarchical review and approval before starting the next phase

Priority of work aligned with customer’s highest priority functionality and content (work items):

  • Product Owner prioritizes all work items in the courseware backlog to match customer’s priorities

  • Development Team chooses the highest priority backlog items to implement during each iteration

Quality Assurance Inspections and Testing

Quality efforts are tacked on at the end of the project

Quality efforts are built-in, distributed across each iteration using the "definition of done" for every process step

Sequencing of what Reviewers inspect and evaluate

Courseware sequence order (the order in which the learner sees it)

By priority (the most technically challenging and highest priority work items implemented first as a risk mitigation method).

Evaluation (Formative)

Progress check items are traceable to Learning Objectives

Same

Evaluation (Summative)

Assessment test items are traceable to Learning Objectives

Same

Evaluation (Content & Functionality)

Customer gives feedback at final delivery

Customer gives feedback at each iteration, earlier in the courseware life cycle

Evaluation (Acceptance)

Customer evaluates reviewer comment incorporation and accepts entire course at final delivery

Customer evaluates reviewer comment incorporation and accepts each iteration, which when all are accepted the course is accepted as the aggregation of the approved increments

Risk impact if new scope added

Higher costs, delivery delay

Scope swap: New scope replaces an equal amount of lower priority work items. Highest priority work items delivered.

Risk impact of requirements changes

Higher costs, delivery delay

Reprioritize work items. Highest priority scope gets delivered. Some lower priority work items dropped to meet cost/time goals. Smaller batch size reduces WIP inventory minimizing change impact.

Risk impact if effort is harder than planned

Higher costs, delivery delay

Highest priority work items delivered, lowest priority work items dropped to meet cost/time

Image

Line By Line

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

Back to Overview