5.1.1 Agile Principles and Values

The agile values and principles that learning engineers operationalize derive from a set of commitments originally articulated in software development but aligned with deep patterns in evidence-based educational practice. At their core, agile principles assert that iterative and incremental development — building in small, testable chunks rather than completing all design work before any learner testing occurs — produces better outcomes than waterfall-style sequential processes. For learning engineering, this iterative commitment is not merely procedural: it reflects a fundamental acknowledgment that learner behavior is difficult to predict from first principles and must be observed empirically in order to be understood. [LE-LS-GL-007]

Iterative and Incremental Development

The principle of iterative and incremental development holds that each sprint or design cycle should produce a functional, testable artifact — not merely an intermediate planning document. In learning engineering terms, this means that a first-pass version of a formative assessment, a worked-example sequence, or an adaptive branching pathway should be deployed with real or representative learners as early as possible so that actual performance data can inform the next iteration. This approach directly parallels the design-based research methodology established by Ann Brown, who argued that educational interventions must be tested in authentic classroom settings to generate valid design knowledge. [LE-LS-AP-003] The doer effect research — showing across seven online courses that active practice causally improves learning relative to passive reading — was itself made possible by the iterative, data-rich instrumentation that agile-style development of online platforms enables. [LE-LS-AP-012]

Cognitive Load Theory provides a scientific rationale for the granularity of agile increments in learning solution development. John Sweller's foundational work established that working memory has strict capacity limits, and that instructional sequences which overload those limits produce high extraneous cognitive load without corresponding learning gains. [LE-LS-AP-008] Designing in small increments and testing each one allows learning engineers to detect and correct cognitive load problems early, before they propagate through an entire curriculum — a correction that is far more expensive to make at the end of a long design cycle. Bror Saxberg's formulation of learning engineering as applied learning science at scale assumes precisely this kind of tight coupling between cognitive science principles and iterative design practice. [LE-LS-PP-009]

Collaboration, Adaptability, and Cross-Disciplinary Values

Collaboration in agile learning engineering means more than periodic stakeholder review. It means genuine, continuous integration of perspectives from learning scientists, instructional designers, developers, data analysts, and learner representatives within a shared sprint cadence. John Sweller's differentiation between intrinsic load (inherent to content complexity) and extraneous load (imposed by poor design) illustrates why this matters: a developer optimizing for clean code and a learning scientist optimizing for reduced extraneous load may make conflicting design choices that can only be reconciled through ongoing collaborative dialogue. [LE-LS-PP-004]

Adaptability to user feedback is the agile value that most directly operationalizes evidence-based design. In intelligent tutoring system development, for instance, iterative revision of hint sequences based on student help-seeking data produced measurable improvements in both help-seeking behavior and learning outcomes — a result that would not have been achievable had the hint content been finalized before deployment. [LE-LS-AP-007] The Learning Engineering Toolkit codifies adaptability as a non-negotiable feature of mature LE practice: design decisions must be documented, justified with evidence, and revisable when data contradicts initial assumptions. [LE-LS-GL-007] Jim Goodell, a primary architect of IEEE ICICLE's professional standards for learning engineering, has argued that this documentation-and-revision discipline — tracking why decisions were made and what evidence prompted changes — is what separates learning engineering from less rigorous approaches to instructional design. [LE-LS-PP-012]

Sprint-Based Development and Lean-Agile Content Creation

Sprint-based development applies agile time-boxing to learning solution work: a two-week sprint might produce a single learning module, associated formative assessments, and an initial data instrumentation plan, all of which are tested, reviewed, and revised before the next sprint begins. This cadence forces prioritization — learning engineers must decide which design hypotheses are most important to test in each sprint — and creates a natural rhythm for stakeholder communication about progress and evidence. The lean-agile variant extends this logic to content creation specifically, treating learning content as subject to the same rapid prototype-test-revise cycle as software features, and explicitly discouraging investment in elaborate production quality before basic learning effectiveness has been validated. [LE-LS-GL-007]

From the Learning Engineering Toolkit

Agile's values trace back to the Agile Manifesto. As the Learning Engineering Toolkit recounts, the Manifesto's authors placed greater weight on people and the ways they work together than on rigid processes or tooling, on delivering functioning software rather than exhaustive documentation, on partnering with the customer rather than negotiating contract terms, and on adjusting to change rather than holding to a predetermined plan — while acknowledging that the lower-priority items still carry worth. [LET-11] Its leading principle is to keep the customer satisfied by delivering usable software early and on a continuing basis. [LET-11] The Toolkit notes that practitioners in fields well outside software took up these habits once they found the approach sharpened their capacity to adapt and to serve customer needs. [LET-11]

Lean contributes a complementary set of commitments organized around ongoing improvement: stripping out delay and waste — anything that fails to add customer value, whether defects, producing more than needed, idle waiting, or unnecessary handling — by persistently seeking better ways of working and reframing problems as chances to learn. [LET-11] Lean-Agile fuses Lean's improvement orientation with Agile's steady delivery, and the Toolkit points out that Lean's improvement thinking suits the iterative nature of learning engineering while Agile's outlook matches its human-centered design character. [LET-11]

These values take shape in concrete practices. Tasks are captured as user stories phrased from the user's standpoint, stating what needs doing and the problem to be solved instead of prescribing the method, and then ranked by priority. [LET-11] The retrospective puts continuous improvement into action: when a cycle closes, the team reviews what succeeded, what fell short, and what it will change together going forward — a gathering the Toolkit regards as arguably the single most valuable one the team holds. [LET-11] Taken together, these principles keep iterative learning engineering centered on delivering value to learners and stakeholders while steadily refining how the team operates. [LET-11]