Agile Development and Version Control

Active learning works for Agile and version control because both concepts involve hands-on practice with real tools and team dynamics. Students must experience the tension of merging code conflicts or the pressure of a sprint deadline to truly grasp why these practices exist, making abstract workflows concrete and memorable.

• 12th Grade
• Computer Science
• 4 activities
• 25 min–90 min

Learning Objectives

1. Analyze the impact of iterative development cycles on software quality by comparing initial prototypes to final products.
2. Evaluate the effectiveness of different branching strategies in Git for managing concurrent code development from multiple team members.
3. Design a project backlog and sprint plan that assigns team roles based on individual strengths within an agile framework.
4. Demonstrate the process of resolving merge conflicts in Git, explaining the steps taken to integrate disparate code changes.
5. Critique the outcomes of a sprint retrospective, identifying specific areas for improvement in team collaboration and process.

Simulation Game

⏱ 90 min·Small Groups

Simulation Game: One-Week Sprint Cycle

Divide students into teams of four with a predefined backlog of small coding tasks. Teams hold a sprint planning meeting to assign tasks, run daily 5-minute standups for three class periods, and close with a sprint review and retrospective. The retrospective uses the Start/Stop/Continue format to surface what the team would change in the next sprint.

Prepare & details

How do iterative development cycles improve the quality of the final product?

Facilitation Tip: During the One-Week Sprint Cycle, set a visible timer for daily stand-ups to reinforce the time-boxed nature of Agile rituals.

Setup: Flexible space for group stations

Materials: Role cards with goals/resources, Game currency or tokens, Round tracker

• Apply
• Analyze
• Evaluate
• Create
• Social Awareness
• Decision-Making

Collaborative Problem-Solving

⏱ 50 min·Pairs

Collaborative Problem-Solving: Git Branching and Merge Conflict Resolution

Pairs each clone a shared repository and independently make changes to the same file, then attempt to merge their branches. The resulting conflict is intentional , students must read the conflict markers, understand what each side changed, and resolve it manually before the merge can complete. Debrief covers strategies for minimizing future conflicts through communication and branch conventions.

Prepare & details

What are the challenges of merging code from multiple developers simultaneously?

Facilitation Tip: For Git Branching and Merge Conflict Resolution, provide a shared repository with intentionally conflicting changes so students confront real merge scenarios on day one.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Project-Based Learning

⏱ 60 min·Small Groups

Role Rotation: Scrum Team Roles

Over two class periods, each team member takes a different Scrum role: Product Owner (maintains and prioritizes the backlog), Scrum Master (facilitates standups and removes blockers), and Developer. After each rotation, students write a two-sentence reflection on how the role's perspective differs from the others, building empathy across team functions.

Prepare & details

Explain how team roles can be assigned to maximize the strengths of each member in an agile environment.

Facilitation Tip: In Role Rotation, assign students to Scrum roles in a sequence that builds on prior experience, such as starting with Scrum Master before moving to Product Owner.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Think-Pair-Share

⏱ 25 min·Pairs

Think-Pair-Share: Commit Message Analysis

Share a real open-source project's Git commit history (appropriately selected for content). Students individually identify three commits with poor messages and three with excellent ones, noting what information the good ones preserve. Pairs discuss what a commit message policy for their team should include, then share recommendations with the class.

Prepare & details

How do iterative development cycles improve the quality of the final product?

Facilitation Tip: Use the Think-Pair-Share for Commit Message Analysis to model professional standards: share an ambiguous commit message first, then guide students to rewrite it together using the lab’s repository as a reference.

Setup: Standard classroom seating; students turn to a neighbor

Materials: Discussion prompt (projected or printed), Optional: recording sheet for pairs

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Teaching This Topic

Teach Agile as a discipline of constraints, not chaos. Start with the Scrum Guide’s roles and events but anchor them in the sprint simulation so students feel the weight of missed deadlines or poor estimates. For Git, treat version control as a time machine: every commit is a save point, and conflicts are puzzles to solve, not errors to avoid. Research shows that students retain workflows better when they debug real conflicts rather than watch a demo, so build time for trial and error into every lab. Avoid lecturing about Agile values; instead, let the sprint reveal why transparency and adaptation matter when the team’s velocity stalls.

What to Expect

Students will demonstrate understanding by completing a full sprint cycle, resolving Git conflicts manually, rotating through Scrum roles with intentional contributions, and evaluating commit messages for clarity and team alignment. Evidence of learning includes a functional Git history, reflective retrospective notes, and a team-approved definition of done.

Watch Out for These Misconceptions

Common Misconception

During the One-Week Sprint Cycle, watch for students who treat the sprint as an open-ended free-for-all without clear goals or time-boxed tasks.

What to Teach Instead

Use the sprint’s definition of done as a non-negotiable anchor. Before coding begins, require each team to write their sprint goal on the whiteboard and refer back to it daily. If students drift, pause the sprint and ask, 'Does this task serve the sprint goal? If not, it waits for the next sprint.'

Common Misconception

During Git Branching and Merge Conflict Resolution, watch for students who assume Git will always auto-resolve conflicts without manual input.

What to Teach Instead

Seed the repository with a conflict—perhaps two developers editing the same function—and let students experience the red error message firsthand. Guide them to use git diff to see the divergence, then manually edit the conflict markers to resolve it. Emphasize that resolving conflicts is a core part of the workflow, not a rare edge case.

Common Misconception

During Role Rotation, watch for students who dismiss version control as unnecessary for individual or small-team work.

What to Teach Instead

After teams rotate roles, have each student commit their changes with a clear message. Then, simulate a lost file by reverting to a previous commit. Ask students to recover their work using git log and git checkout. The time saved (or lost) will make the value of version control tangible.

Assessment Ideas

Quick Check

During Git Branching and Merge Conflict Resolution, present students with a scenario where two developers edited the same function in different branches. Ask them to identify the conflict type and outline the first three steps to resolve it, using the terminal or Git GUI they practiced with.

Discussion Prompt

After the One-Week Sprint Cycle, facilitate a class discussion using the prompt: 'What are the key questions your team asked during the sprint retrospective to improve? How did these questions address specific pain points from the sprint?' Collect responses on the board to identify patterns in team health.

Peer Assessment

After students submit their Git commits for the sprint task, pair them to review a classmate’s commit history. Ask them to assess: Is the commit message clear and descriptive? Are there too many changes in one commit? Each reviewer must provide one specific suggestion for improvement, citing the commit hash and line number.

Extensions & Scaffolding

• Challenge: Introduce a spike task during the sprint where teams must research and prototype a new feature, requiring them to update the sprint backlog mid-sprint and justify their choices in the retrospective.
• Scaffolding: Provide a pre-branched Git repository with clear instructions and a checklist for resolving conflicts, then gradually remove scaffolding in subsequent labs.
• Deeper exploration: Assign a code review task where students must use GitHub’s pull request template to critique a teammate’s code, focusing on SOLID principles and Agile design patterns.

Key Vocabulary

Scrum	An agile framework for managing complex projects, emphasizing teamwork, accountability, and iterative progress through sprints.
Sprint	A fixed, short period (typically 1-4 weeks) during which a specific set of work is completed and made ready for review in an agile project.
Backlog	A prioritized list of features, requirements, and tasks for a project, which is refined and updated throughout the development lifecycle.
Git	A distributed version control system used for tracking changes in source code during software development, enabling collaboration and history management.
Pull Request	A mechanism in Git platforms like GitHub or GitLab for proposing changes to a codebase, allowing for review and discussion before merging.
Merge Conflict	A situation that occurs when Git cannot automatically combine changes from different branches, requiring manual intervention to resolve discrepancies.