Computer Science · 12th Grade · Social Impacts and Professional Ethics · Weeks 37-45

Agile Development and Version Control

Students implement scrum and sprint methodologies to manage a project, learning to use version control systems like Git.

• Common Core State Standards
• CSTA: 3B-AP-18
• CSTA: 3B-AP-20

About This Topic

Agile development and version control are the two organizational pillars of modern professional software work, and this topic gives 12th-grade students hands-on experience with both. Under CSTA 3B-AP-18 and 3B-AP-20, students are expected to use systematic processes to manage software projects and collaborate effectively , this unit makes those standards concrete by having students actually run a sprint.

Scrum introduces students to structured iteration: a backlog of prioritized tasks, time-boxed sprints (typically one to two weeks), daily standups, sprint reviews, and retrospectives. These practices exist because software development is inherently uncertain, and short feedback loops catch problems before they compound. Git and platforms like GitHub add a technical dimension: branching strategies, pull requests, merge conflict resolution, and commit history as a record of decision-making.

Active learning is natural for this topic because Agile itself is a collaborative practice. Students who run actual standups, assign story points, manage a real backlog, and resolve genuine merge conflicts learn that version control and sprint management are not bureaucratic overhead but tools that make collaboration tractable at scale.

Key Questions

1. How do iterative development cycles improve the quality of the final product?
2. What are the challenges of merging code from multiple developers simultaneously?
3. Explain how team roles can be assigned to maximize the strengths of each member in an agile environment.

Learning Objectives

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

Before You Start

Introduction to Software Development Lifecycles

Why: Students need a foundational understanding of the general phases of software creation before learning specific agile methodologies.

Basic Programming Concepts and Syntax

Why: Students must be able to write and understand code to effectively manage and collaborate on projects using version control.

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.

Watch Out for These Misconceptions

Common Misconception

Agile means no planning , you just build and figure it out as you go.

What to Teach Instead

Agile reduces upfront planning in favor of continuous planning, but it requires more discipline than Waterfall in many respects: every sprint needs a clear goal, every task needs to be estimated and committed to, and every retrospective needs honest assessment. The structure is lighter but still rigorous.

Common Misconception

Git automatically handles merging code from multiple developers , you just push and it works.

What to Teach Instead

Git can auto-merge changes to different parts of the same file, but when two developers edit the same lines, a merge conflict requires manual resolution. Hands-on conflict resolution exercises make this concrete: students who have resolved a real conflict understand why branch conventions and frequent integration matter.

Common Misconception

Version control is only necessary for large teams. Small teams or solo developers can just save their files.

What to Teach Instead

Version control is valuable even for individual developers: it provides a complete history of changes, makes it easy to revert mistakes, and enables branching to experiment safely. The habit of committing with meaningful messages is a professional skill that saves significant time when debugging or onboarding collaborators later.

Active Learning Ideas

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.

90 min·Small Groups

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.

50 min·Pairs

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.

60 min·Small Groups

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.

25 min·Pairs

Real-World Connections

• Software development teams at companies like Google and Microsoft use Scrum and Git daily to build and update complex applications such as operating systems and productivity suites.
• Game development studios, from large corporations like Nintendo to independent studios, employ agile methodologies and version control to manage the iterative creation of video games, coordinating hundreds of artists, designers, and programmers.
• Open-source projects, such as the Linux kernel or the Python programming language, rely heavily on Git and collaborative development workflows to allow contributions from a global community of developers.

Assessment Ideas

Quick Check

Present students with a scenario where two developers have made conflicting changes to the same file in Git. Ask them to identify the type of conflict and outline the first three steps they would take to resolve it.

Discussion Prompt

Facilitate a class discussion using the prompt: 'Imagine your team just completed a sprint. What are the key questions you should ask during the sprint retrospective to ensure continuous improvement, and why are these questions important for team health?'

Peer Assessment

After students have submitted their Git commits for a sprint task, have them 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? Provide one specific suggestion for improvement.

Frequently Asked Questions

What is Scrum and how does it work in a software team

Scrum is an Agile framework that organizes development into time-boxed iterations called sprints, typically one to four weeks long. Each sprint begins with planning (selecting tasks from the backlog), includes daily standups (brief status syncs), and ends with a review (demonstrating completed work) and retrospective (examining the team's process). A Scrum Master facilitates the process; a Product Owner maintains the backlog.

What is a merge conflict in Git and how do you fix it

A merge conflict occurs when two branches contain changes to the same lines of a file and Git cannot automatically decide which version to keep. Git marks the conflict in the file with special markers showing both versions. The developer must manually edit the file to choose one version or combine them, then stage the resolved file and complete the merge with a commit.

What is the difference between Git and GitHub

Git is the distributed version control system itself , the software that tracks file history, manages branches, and enables merging. GitHub is a cloud-based platform that hosts Git repositories and adds collaboration features: pull requests, code review tools, issue tracking, and CI/CD integrations. Other platforms like GitLab and Bitbucket offer similar features on top of Git.

How does learning Agile through active classroom exercises prepare students for real software teams

Professional Agile teams learn Scrum by doing it , the practices only become intuitive through repetition. Running actual sprint ceremonies in class (standups, reviews, retrospectives) builds the collaboration and communication habits that make Agile work. Students who have lived a sprint cycle understand why the ceremonies exist, not just what they are called.