5.1 Agile Development

Agile development is an iterative, collaborative approach to building software and, by extension, learning solutions — one that prioritizes responsiveness to evidence over adherence to a fixed upfront plan. Originating in software engineering, agile methods were adapted for learning contexts because their core commitments — short cycles, cross-functional teams, working prototypes over exhaustive documentation, and continuous feedback — map directly onto learning engineering's requirement to test and revise designs against real learner data. The Learning Engineering Toolkit frames learning engineering explicitly as an iterative process structured around challenge identification, solution creation, implementation, data investigation, and continuous revision, a sequence that mirrors agile's plan-build-test-reflect cadence. [LE-LS-GL-007]

Agile Principles Applied to Learning Engineering

The central agile principle most consequential for learning engineering is the commitment to working solutions over comprehensive documentation. In practice this means that a functional learning module tested with real learners in week two of a sprint provides more actionable design information than a complete storyboard reviewed only by subject matter experts. This empirical orientation aligns with the design-based research standard established by Ann Brown, which held that complex educational interventions must be tested and refined in authentic settings to yield valid conclusions about what works. [LE-LS-AP-003] Where traditional instructional design processes often front-load analysis and defer learner testing until late in the project, agile-inflected learning engineering embeds testing and revision within every short iteration.

Cross-disciplinary sprint teams are equally central. Learning engineering problems require expertise from learning science, instructional design, data science, software development, and subject matter — and agile's explicit norm of daily coordination within small, self-organizing teams provides structural scaffolding for that integration. The Learning Engineering Adoption Maturity Model developed by IEEE ICICLE identifies cross-disciplinary collaboration as one of the key capability dimensions along which organizations mature in their LE practice. [LE-LS-AP-013] Bror Saxberg's articulation of the practitioner learning engineer — someone who applies cognitive science at massive and affordable scale — similarly assumes a professional capable of orchestrating contributions from multiple disciplines within rapid development cycles. [LE-LS-PP-009]

Lean-Agile Variants and Learning Contexts

Several agile variants have found particular traction in learning contexts. Scrum provides a structured sprint cadence with defined roles (product owner, scrum master, development team) that translate reasonably well to learning solution teams with client stakeholders, project managers, and mixed design-development staff. Kanban offers a lighter-touch, flow-based approach useful when content update frequency is high and sprint-length commitments are impractical — for example, in a corporate learning team continuously revising compliance modules based on regulatory change and learner performance data. The Learning Engineering for Online Education volume documents case studies in which agile processes enabled rapid integration of telemetry data from online platforms into design decisions that would otherwise have required months of committee review. [LE-LS-GL-008]

Lean-agile principles also have direct relevance for managing cognitive demand during development. Research on metacognitive scaffolding in intelligent tutoring systems demonstrated that even small, iterative changes to hint sequences — tested and revised across multiple brief cycles — produced significant improvements in help-seeking behavior among students. [LE-LS-AP-007] This finding illustrates a general principle: agile's short cycles are not merely a project management convenience but an epistemological mechanism for surfacing the gap between a designer's assumptions about learner behavior and what learners actually do. Jim Goodell and colleagues at IEEE ICICLE have argued that this gap-closing function is what most distinguishes iterative learning engineering from conventional instructional design. [LE-LS-PP-012]

Limitations and Adaptations

Agile methods do not transfer to learning contexts without modification. The definition of "done" for a learning solution is inherently more complex than for a software feature: a module may be technically complete while failing to produce target learning outcomes. Learning engineers must therefore extend agile's acceptance criteria to include empirical evidence of learning, not merely functional delivery. The Learning Engineering Toolkit addresses this directly by insisting that each iteration produce not only a deliverable but a measurable hypothesis test about learner outcomes. [LE-LS-GL-007] IEEE ICICLE's professional standards infrastructure supports this adaptation by providing the competency frameworks and organizational maturity assessments that help teams build the capacity for rigorous iterative practice. [LE-LS-CO-001]

¶ Subsections:

• 5.1.1 Agile Principles and Values

From the Learning Engineering Toolkit

The Learning Engineering Toolkit traces agile to the Agile Manifesto, whose authors described arriving at a preference for people and their interactions over fixed processes and tools, for software that works over exhaustive documentation, for collaborating with customers over negotiating contracts, and for adapting to change over adhering to a plan — while granting that the lesser-weighted items retain some value. [LET-11] Its first principle is to keep the customer satisfied through early and ongoing delivery. [LET-11] When practitioners beyond software engineering recognized that agile habits sharpened their ability to respond to change, the approach carried over into other domains, learning engineering among them. [LET-11]

The Toolkit highlights Scrum and Kanban as the two agile methods of greatest use to learning engineering teams. [LET-11] Scrum is a framework built on values such as honesty, openness, transparency, empowerment, and collaboration, and organized around designated roles (product owner, scrum master, development team), recurring activities (stand-ups, sprints, sprint planning and review, grooming, retrospectives), and artifacts like a priority-ordered product backlog of user stories. [LET-11] A sprint is a bounded stretch of time — commonly two weeks — in which the team finishes the work it agreed to at planning. [LET-11] Kanban is a more lightweight Lean approach in which teams map the flow of work across a board, optionally cap how much is in progress at once, and draw in new work only as capacity opens up, so that bottlenecks surface and the process can be refined. [LET-11]

The chapter depicts a learning engineering kanban board whose columns track the main stages of the LE process — backlog, challenge, creation, implementation, investigation, review, and done. [LET-11] Its authors suggest that if a team adopts just one thing from the Lean-Agile toolkit, pairing Kanban with the retrospective is the choice to make, because visualizing the work and routinely reviewing the board for improvements pays off substantially. [LET-11]