Portfolio

Teaching Portfolio · Chapter 5

Adaptive Teaching and Inclusion

This chapter shows how I make challenging Computer Science learning accessible through modelling, scaffolding, vocabulary support, formative assessment and planned challenge, while maintaining high expectations for all students.

Chapter purpose

Making challenging learning accessible to all students

Adaptive teaching and inclusion are central to my work as a Computer Science teacher. I believe that students should have access to challenging learning, but that the route into this learning needs to be carefully designed. Inclusion does not mean lowering expectations; it means identifying possible barriers, providing appropriate support and helping students develop confidence and independence.

In a bilingual teaching context, programming can create several barriers at the same time: students need to understand the logic of the code, use precise syntax, apply technical vocabulary and explain why a program works. For this reason, I plan carefully for modelling, scaffolding, pair support, formative checks and challenge tasks.

Adaptive teaching thread

From modelled code to independent explanation

The evidence in this chapter comes from a Python multiple-choice quiz lesson. Students used variables, input, conditional statements, comparison operators and score tracking to build a small software product. The lesson was planned to move from recall, to guided modelling, to pair programming, to independent explanation.

The adaptive thread was deliberate. Students who needed more structure could rely on the modelled example, printed task instructions, peer support and scaffolded exit-ticket prompts. Students who were secure could attempt challenge features such as handling uppercase/lowercase answers with .lower(), adding bonus questions, functions, loops or replay options.

Evidence 5.1

Annotated Python Quiz Lesson Plan

A programming lesson plan showing adaptive teaching through modelling, scaffolding, pair programming and challenge.

Evidence extract

This lesson asked students to create a Python multiple-choice quiz game using input(), variables, if/else statements, comparison operators and score tracking. The learning sequence moved from recall, to guided modelling, to pair programming, and finally to independent explanation.

The adaptive planning focused on predictable barriers in programming. Students may confuse = and ==, forget to initialise score = 0, update the score in the wrong place or struggle with indentation inside an if/else block. These were addressed through recall, live modelling, deliberate mistake correction and targeted questioning.

The lesson also maintained challenge. Students who needed support could follow the modelled example and printed instructions, while confident students could attempt .lower(), bonus questions, final score messages, functions, loops or replay options.

View evidence document

Python quiz lesson plan

The original annotated lesson plan is shown below in a compact preview. The reader can scroll inside the PDF or open it in a new tab.

Adaptive planning Modelling Scaffolding Pair programming Challenge tasks Formative assessment

Evidence 5.2

Teaching Slides and Quiz Code

Lesson slides showing how students were supported from code recall to modelled practice, independent pair work and extension.

Evidence extract

The teaching slides made the route into the programming task visible. Students first revisited a password program to recall input(), ==, if/else and variable updates. This helped activate prior knowledge before introducing the quiz task.

The modelled example showed a complete first quiz question using a score variable, user input, a comparison and conditional feedback. This gave students a shared model before they moved into pair programming.

The slides also supported inclusion through clarity: the task requirements were listed explicitly, and early finishers had visible challenge options such as accepting uppercase/lowercase answers, adding more questions, bonus points, final messages, functions, loops or a replay option.

View evidence document

Teaching slides and code resource

The original slide/code resource is shown below in a compact preview. The reader can scroll inside the PDF or open it in a new tab.

Recall Worked example Code modelling Task clarity Extension Vocabulary

Evidence 5.3

Observation Feedback Extract

External observation feedback confirming engagement, adaptive support, challenge and opportunities for students to explain code.

Evidence extract

The observation feedback supports this chapter because it shows that adaptive planning was visible in the classroom. Students were engaged in the warm-up investigation, used sample code to activate prior knowledge, and answered questions about variables, conditional statements and variable updates.

The feedback highlighted that students were able to spot possible misconceptions in the code, worked through pair programming to develop a quiz, and were challenged in the coding task through extension opportunities. It also noted that differentiation and additional extension activities were prepared for students who finished early.

The development points are also useful for inclusion: students should be encouraged to ask more questions and use English more actively when explaining code. This reminds me that adaptive teaching includes both access to the programming task and support for academic communication.

View evidence document

Programming lesson observation

The original observation feedback is shown below in a compact preview. The reader can scroll inside the PDF or open it in a new tab.

Observation feedback Engagement Questioning Differentiation Appropriate challenge English use

Evidence 5.4

Adaptive Exit Ticket Answers

Anonymised student responses showing different levels of support and challenge in the same exit-ticket structure.

Evidence extract

The exit ticket was deliberately adaptive. Students completed a self-assessment and then selected one response pathway: Option A offered scaffolded fill-in-the-blanks for key vocabulary, Option B asked students to explain code, and Option C challenged students to improve the code.

The responses show different ways students accessed the same learning objective. Some consolidated terms such as variable, assignment operator, comparison operator and conditional branching; others explained why score = score + 1 changes the score or why an if statement checks the user's answer.

Challenge responses also showed students thinking about robustness, such as what happens if the user types paris instead of Paris, and how to accept both uppercase and lowercase answers. This gave me evidence of both support needs and extension readiness.

View evidence document

Adaptive exit-ticket responses

The original anonymised exit-ticket evidence is shown below in a compact preview. The reader can scroll inside the PDF or open it in a new tab.

Exit ticket Tiered support Student voice Vocabulary Code explanation Challenge