Activity 01
Pecha Kucha Rehearsal: Project Highlights
Students prepare 20 slides, 20 seconds each, covering problem, solution, failures, and impact. Pairs time each other, noting jargon use and clarity. Groups share one slide for class feedback.
How do we effectively demonstrate the value of a technical solution to a user?
Facilitation TipDuring Pecha Kucha Rehearsal, set a timer for each slide transition to keep student presentations disciplined and focused on key highlights.
What to look forStudents present a 2-minute 'elevator pitch' of their project to a small group. Peers use a checklist to assess: clarity of the problem solved, explanation of the core feature, and identification of one societal impact. Peers provide one specific suggestion for improvement.
UnderstandApplyAnalyzeEvaluateSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 02
Audience Switch: Dual Presentations
Individuals present 3-minute pitches to small groups acting as executives, then developers. Switch roles after first round. Debrief on adaptations made for each audience.
What are the most important lessons learned from the failure of a specific feature?
Facilitation TipFor Audience Switch, assign one student to play the technical audience and another the non-technical audience so students must adapt responses in real time.
What to look forOn an index card, students write: 1) One technical concept they simplified for a non-technical audience. 2) One lesson learned from a feature that did not work as intended. 3) One specific piece of documentation they created for future maintainers.
UnderstandApplyAnalyzeEvaluateSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 03
Failure Story Circle: Lessons Shared
In a circle, each student shares one failed feature, its cause, and fix via documentation. Class votes on clearest story; winner explains to 'future maintainer' role.
How does documentation serve as a bridge between the developer and the future maintainer?
Facilitation TipIn Failure Story Circle, model vulnerability first by sharing your own project setback to normalize failure as part of the process.
What to look forTeacher poses a scenario: 'Imagine you are presenting to a potential investor who knows nothing about coding. How would you explain the primary benefit of your project's algorithm?' Students write a one-sentence response.
UnderstandApplyAnalyzeEvaluateSelf-ManagementRelationship Skills
Generate Complete Lesson→· · ·
Activity 04
Documentation Demo: Peer Review
Pairs review each other's project docs, simulating maintainer role. Identify gaps, suggest visuals. Revise and present updates to the class.
How do we effectively demonstrate the value of a technical solution to a user?
Facilitation TipFor Documentation Demo, provide a sample bug report or README file to anchor peer review conversations in concrete examples.
What to look forStudents present a 2-minute 'elevator pitch' of their project to a small group. Peers use a checklist to assess: clarity of the problem solved, explanation of the core feature, and identification of one societal impact. Peers provide one specific suggestion for improvement.
UnderstandApplyAnalyzeEvaluateSelf-ManagementRelationship Skills
Generate Complete Lesson→A few notes on teaching this unit
Experienced teachers approach this topic by coaching students to see communication as part of the development process, not an add-on. Research suggests that practice with mixed audiences builds both empathy and clarity. Avoid letting students rehearse only with peers who already understand the project. Instead, structure repeated opportunities to explain to strangers, whether through role plays or guest audiences.
Successful learning looks like students confidently translating technical details into plain language for mixed audiences. They should articulate both the problem solved and the lessons from setbacks, using artifacts like documentation to demonstrate professional habits of mind.
Watch Out for These Misconceptions
During Pecha Kucha Rehearsal, watch for students defaulting to technical jargon.
After the rehearsal, have peers flag any unclear terms on sticky notes and suggest plain-language alternatives using a shared word bank of student-generated definitions.
During Audience Switch, assume students will naturally adjust their language for different listeners.
During the activity, project a simple grid on the board with columns for 'Technical Audience' and 'Non-Technical Audience' and require students to write one phrase they used for each audience before switching.
During Documentation Demo, treat documentation as a static artifact separate from the project.
Have peers use the project's GitHub issues or bug tracker to simulate a real maintenance request, requiring students to locate and interpret existing docs to respond to a simulated user problem.
Methods used in this brief