Agile teaching is a practice.
Not a philosophy, not a style.
Agile teaching is the practice of treating every lesson as a hypothesis — you plan it based on what you know about your students, you run it, you observe what actually happens (not what you planned to happen), and you use that observation to adjust the next lesson. The adjustment might be minor: a different example, a better question. Or substantial: a different explanation, a redesigned activity. What it is not is waiting until the end of term to discover what worked.
The word ‘agile’ comes from software development, where teams build in short cycles, test after each cycle, and improve based on evidence. In teaching, the cycle is a lesson or a week. The test is formative assessment. The improvement is a better-calibrated next lesson. The parallels are structural: both apply iteration as a method for improving something complex where initial plans never fully survive contact with reality.
Agile teaching is not a teaching style. It doesn't prescribe how a lesson should be structured, whether to use group work or direct instruction, or what the classroom should look like. Those choices belong to the teacher. Agile teaching is a relationship between planning and evidence: the plan responds to data rather than existing independently of it.
Plan. Teach. Observe.
Adapt. Repeat.
The agile teaching loop has four stages. They repeat every lesson or every week. The key is that each repetition starts from evidence rather than from the original plan.
The plan is your best prediction of what this class needs today, given what you observed yesterday. Which concepts are still unclear? Which misconceptions appeared on the exit ticket? Which students are ready to move faster? The plan answers these questions. It is a hypothesis, not a contract — if the lesson reveals that the hypothesis was wrong, the plan changes.
While teaching, an agile teacher maintains a layer of attention on what students are actually doing with the content — not just whether they are on-task, but what type of thinking is visible in their work. The observation might be casual (circulating and reading student notes) or deliberate (a planned scanning sequence targeting a specific error). Both produce the data that feeds the next stage.
Systematic data collection at the end of the lesson captures what the in-lesson observation could only partially see. An exit ticket takes 4 minutes to run and 3 minutes to scan. The output is a specific, named gap: not 'students didn't fully understand' but 'students can apply the procedure but can't explain the mechanism'. That specificity is what makes adaptation possible.
The adaptation is not a full lesson rewrite. It is the minimum change that addresses the specific gap identified in Stage 3. Most days this takes under 20 minutes. Most changes affect one element — an explanation, an activity, a transition. The rest of the lesson is unchanged. Tomorrow's lesson is a better version of yesterday's plan, not a new plan built from scratch.
What separates agile teaching
from conventional practice.
Conventional teaching treats the lesson plan as the primary deliverable. The lesson plan is researched, structured, and refined before students arrive. The lesson is then executed as designed, and any gaps in learning are addressed in the next unit or the next year's planning cycle.
Agile teaching treats the lesson plan as an input, not an output. The plan is the starting point; the lesson is the data collection; the adaptation is the real work. This inversion changes where teachers invest their planning time — from pre-lesson preparation to post-lesson analysis.
The classroom looks the same.
The teacher's work is different.
From the outside, an agile classroom looks like any other well-run classroom. The visible elements — the activities, the explanations, the discussions — may be structurally identical to a conventional classroom's. What is different is invisible: the relationship between what happens in a lesson and what the teacher does the night before.
The agile teacher spends less time perfecting lesson plans before delivery and more time reading data after it. They have a consistent end-of-lesson routine (3–4 minutes to scan exit ticket responses) and a consistent adaptation routine (15–20 minutes to make one targeted change to the next lesson). The cumulative effect is that lessons improve continuously across a term, rather than being fixed until the next planning cycle.
The practical implication for a school implementing agile teaching is that the infrastructure needs to support this workflow. Shared lesson resources reduce the individual planning burden. AI tools compress the time cost of adaptation. Regular team retrospectives make individual iterations visible across the department. These structures are covered in C4 (iteration workflow), C6 (school-wide culture), and C8 (AI tools). This article is the foundation. Everything else in P6 builds on the four-stage loop defined here.
The research case for doing this
at all.
The definition is clear. But why should a teacher invest in this workflow when conventional teaching also produces learning? A2 covers the research: what Hattie's meta-analysis of 800 studies shows about instructional responsiveness, what Dylan Wiliam's classroom research found about the specific impact of formative data on outcomes, and why the mechanism behind agile teaching's effectiveness is well understood even when the practice itself is not widely named.