SAT Team Reflection (2025-2026)

Project Management Evolution

Semester 1: Structured Agile

In the first semester, we used a standard Agile approach. We had a Scrum Master to manage tasks and the GitHub board, and a Project Owner to talk to Oz. We had weekly meetings to plan and group tasks into “Must-have,” “Should-have,” and “Ideally.” Later, we added the +1/+2 review system based on advice from Nik Dewally. Even with these roles, everyone had the freedom to manage their own work.

Semester 2: Flexible Autonomy

In the second semester, we stopped using formal Agile roles. Instead, people picked their own tasks and worked on them. We replaced regular meetings with updates in Teams to keep everyone informed and had meetings on demand. We kept using the +1/+2 system to keep the code consistent. We also got rid of “Must-have,” “Should-have,” and “Ideally.”

The +1/+2 Review Technique

The +1/+2 system meant we didn’t send pull requests to senior reviewers until the whole team agreed. Everyone had to review and approve the PR on GitHub. If one person hadn’t approved it, it wasn’t ready. This helped keep the team aligned.

What Worked

The +1/+2 system worked well to keep us on track. It prevented Oz from wasting time on simple fixes like syntax errors or hygiene issues, and because the entire team reviewed every PR, almost everyone stayed up to date with the codebase and current development.

Communication also improved when we changed how we used the GitHub board. In the first semester, we there was an unspoken assumption that everyone was following the board, but that didn’t work for everyone. After some discussion within the team, we agreed to primarily using Teams instead, which worked much better. Although some people found it useful to still have their task on the board.

Breaking work into small tasks was especially successful in the second semester for two reasons:

• Since we already had the direct/order base implemented, adding to that structure was easy. It allowed for clear separation between tasks. Keeping elements decoupled was very useful for our team’s progress. If your team can do that, then please do it since it saves hours of time that you would’ve spent trying to administrate these tasks.
• After a series of discussion we agreed to only pick up one task at a time, and actually followed through. That prevented people from taking on more than they could handle.

Challenges and Lessons Learned

• Using only the GitHub board was hard because it was often out of date, and as mentioned before, we had an implicit assumption that everyone is keeping track of it which slowed us down.

Also, our “Must/Should/Ideally” labels didn’t always work. Tasks that looked easy often turned out to be hard, which meant some people took on too much work.

Reflections on Meeting Cadence

We aren’t sure how often we should meet. Weekly meetings in the first semester were good for syncing but took time away from coding, and it was sometimes difficult to find the time where everyone is free. In the second semester, “meeting only when needed” helped us code faster, but we sometimes did the same work twice. For example, we missed chances to share code between similar rules because we weren’t talking enough, even with the +1/+2 system.