Sprint Phase

Starting in week 5, once the teams are chartered and the Sprints begin, this course shifts gears. We move from an instructional model to a production model.

To mirror the environment of a high-performance Research Software Engineering (RSE) team, our synchronous sessions will no longer function as lectures with guided activities. Instead, we treat every class meeting as a live engineering sprint.

We follow a strict Standard Operating Procedure (SOP) to maximize development time and ensure technical blockers are resolved immediately.

Cadence

Triage (0:00 – 0:15)

Class begins with a Stand-Up. We will project the course Kanban board (GitHub Projects) on the main screen. We do not waste time on status updates like “I wrote some code.” We focus entirely on friction.

We identify which teams are Blocked. If your team is stuck on a technical hurdle that has stalled progress for more than 24 hours, you are flagged. If another team has solved a similar problem previously, we will assign a cross-team consultation. This ensures that the collective intelligence of the room is used to solve problems, rather than relying solely on the instructor.

Micro-Clinic (0:15 – 0:35)

There are no hour-long lectures in this phase. Instead, we use “Just-in-Time” teaching. Based on the code you pushed and the Async assignments, the instructor will identify a common pain point across the class. For 20 minutes, we will focus on that single specific issue. This is usually a live-coding demonstration where we solve a real bug together.

Deep Work (0:35 – 1:30)

This is the core of the course. For 55 minutes, the teams work on their current Sprint deliverables. During this time, the instructor acts as the Chief Technology Officer (CTO). I will not be lecturing; I will be circulating. My role is to unblock you, review your architecture, and help you debug complex errors. However, to access this help, you must follow the Help Ticket Protocol (see below).

Code Review (1:30 – 1:50)

We stop coding 20 minutes before the end of class to conduct a retrospective. One group will volunteer to have their day’s work code reviewed by the instructor and the class, during which we will highlight what was done well (e.g., “Look at this clean error handling”) and what needs improvement (e.g., “Why is this file path hard-coded?”). This creates a feedback loop where you learn from your peers’ code, not just your own.

Volunteering once during the semester is worth five points, but it is technically optional. If no one volunteers during that session, we will continue working until the end of class.

Rules of Engagement

To simulate a professional environment, we enforce specific behaviors during the “Deep Work” sessions.

The “Help Ticket” System

In a professional remote team, you cannot simply raise your hand and wait for a senior engineer to walk over. You must articulate your problem in writing. We practice that here.

Do not raise your hand if you are stuck.

If your group encounters an error:

  1. Attempt to solve it using the error message and documentation.
  2. If you are still blocked, go to your team’s GitHub Repository.
  3. Open an Issue.
    • Tag: help-wanted
    • Assignee: @DRI
    • Content: You must paste the specific error code, the file path, and a bulleted list of the attempts you have already made to fix it.

I will monitor the GitHub notification feed and visit teams based on the priority and clarity of their tickets. If the problem is not in an Issue, the problem does not exist.

Mob Programming

Teams are not permitted to “divide and conquer” silently during class (e.g., “You do the CSS, I’ll do the Python”). This leads to siloed knowledge and integration nightmares. During Sync sessions, we use Mob Programming:

  • One Monitor: The team gathers around a single screen.
  • The Driver: Has their hands on the keyboard. They focus on syntax and typing.
  • The Navigators: Review the code in real-time, spot typos, and guide the high-level logic.

You must rotate the “Driver” role every 20 minutes.

Special Events

While most weeks follow the standard protocol, we occasionally break the routine to test specific engineering resilience skills:

The Architecture Review (Week 6): Laptops are closed. We use whiteboards only to map out data flows before writing a single line of code.

The Chaos Monkey (Week 8): You will clone a neighboring team’s repository. You have 45 minutes to “break” their code—finding inputs that cause crashes or unhandled exceptions. You earn points for breaking their code; they earn points for handling the errors gracefully.

The Usability Test (Week 12): A naive user from another team will attempt to install and run your tool using only your README.md. You must watch them struggle in silence. You are not allowed to help them. This is the ultimate test of your documentation.

Last updated on