In a Prezi I did a few years back (https://prezi.com/c75ncmsqv8m9/3-transformative-agile-ideas-for-education/ — Dramamine recommended), I pushed for assessment-first experiences focused on small but standalone useful skills, e.g., “can build a web page to do simple calculations” not “can write a FOR loop.” (Before would have come a module on “can build a web page” etc.)

A lean startup approach to developing such things would begin with building assessments for the skills we’d like to teach, and testing their viability. Can experts pass our assessments? Do they accept them as valid? Do target learners fail these assessments in the way we expect? Do they also accept them as valid? Can we generate instance of these assessments ad infinitum? If the answer to any of these questions is no, already we have a problem. We have failed fast, as they say. Otherwise, these assessments are in themselves a viable useful deliverable.

The second release would be developing the simplest activities that could possibly work to help students learn how to pass the test. Drill and practice, challenge and defend, construct and measure, etc. The test of course is how well students do on the assessments from the first release.

Rinse and repeat.

Now, that said, in learning, one of the things you want to do is check your knowledge, or check your proficiency, early and often. So taking in information is like the “sprint” phase, then you try applying that knowledge, then you revise your models or you seek new information, and so forth. So the principle that makes most sense is to take small steps when learning — small ingestion of knowledge, small practice, small application, small corrective steps, and cycle frequently.

Ah, the other thing is you talk about “increasing fidelity” — this presupposes there is a correct way, or a correct model of a real situation. That idee fixe view of the world doesn’t work as well as it used to. Most of the time when we’re learning in real life, business, science (etc.) we are trying to understand systems that are constantly evolving, so there may not be as much of this “increasing fidelity” as there was 20 or 30 years ago. That’s certainly a core reason that -agile- works when it comes to software development — we don’t have a good idea what we want, and the prototyping and development helps us understand that.