Project Retrospective

Project Retrospective

This page reflects on the AccessMap (Neighborhood Accessibility Mapper) project from the beginning of the semester up to the MVP milestone. We wanted to take an honest look at what we did well as a team, where we stumbled, and what we want to change going forward.

Overview

At the start of the semester we had an idea and a roadmap; by the MVP milestone we had a working auth flow, a map screen, backend endpoints, and a solid amount of documentation behind all of it. Along the way, things naturally didn't always go smoothly — but looking at what ended up on the table, we're happy with the outcome as a team. The point of this retrospective is to put into words both the things that earned us that feeling and the things we need to fix before heading into the next milestone.

What Went Well

We Delivered the MVP on Time

This was the most concrete win for us. When we drafted the roadmap at the beginning of the semester, we thought the MVP scope was a bit ambitious, but we made the deadline in the end. Delivering without having to shrink the scope or cut features at the last minute was a real morale boost. The sub-team structure (Backend, Frontend, Mobile & DevOps) working in a coordinated way within itself played a big role here.

We Made Good Technical Decisions Early

We didn't waste too much time on the stack decision (Expo Router + TypeScript on the frontend, Django REST Framework + simplejwt on the backend). Once we agreed, we didn't keep second-guessing it. Decisions like doing a mock HTML prototype for the auth flow before moving to the 16-file Expo Router implementation, or setting up JWT persistence and the profile screen early, turned out to be very sound in hindsight. Because we laid the architecture down properly from the start, we never had a "where does this feature even go" moment later.

Git Discipline Took Hold

We talked through Conventional Commits, branch naming (feature/xxx-name style), and a squash merge policy at the beginning of the semester and wrote them down as actual rules. It took some of us a little while to adjust, but once it clicked, PRs started flowing much more cleanly. Even when branches got tangled (for example during the map redesign, when a routing conflict forced us to start from a fresh branch), this discipline made recovery a lot easier than it could have been.

Documentation and Wiki Organization

Part of this came from course requirements, but it wasn't just compliance — it genuinely helped us. Lab reports, wiki pages, UML artifacts (class diagram, sequence diagram, glossary), RAM, roadmap, test plan, communication plan — writing all of these properly from the start prevented a lot of "did we forget something" panic as milestones approached. We got into the habit of checking the wiki before starting something new, and we hope that habit carries over into the next semester.

What Went Badly / Unexpectedly

Communication and Meeting Structure

This was probably our biggest pain point. We planned weekly meetings at the start, but in practice some weeks they happened and some weeks they didn't; and when they did, sometimes what should have been a 30-minute check-in stretched to an hour and a half, while other times the meeting wrapped up quickly without covering the important stuff. In weeks without a meeting, everything moved to WhatsApp, and messages there kept getting buried in the chat flow. We especially felt the gap in cross-sub-team communication — there were a few moments where Frontend was waiting on one version of an endpoint while Backend was building a slightly different one, small desync issues that could have been avoided with better coordination.

The worse part was that even when we noticed these problems, we tended to say "we'll talk about it at the next meeting" and postpone. We never really managed to establish discipline around async communication on WhatsApp. Heading into the next milestone, we need something concrete here — a fixed meeting slot, a short standup-style format, or at least a weekly written sync.

Task Distribution and Workload Balance

This was our second big issue. We opened issues on GitHub and tracked them, but we never built a shared sense of who was doing what and how long it would take. As a result, some weeks some teammates were genuinely slammed while others had a lighter load. This wasn't really about unfairness — no one was slacking — it was about poor planning. We consistently misjudged how much work some tasks actually required.

Especially treating integration tasks (like Frontend wiring up a Backend endpoint) as "just part of the feature" rather than as work on their own cost us. We also kept running into bottlenecks where one person's task was blocking someone else — a PR needing to merge before another could open, for example, which slowed down overall progress.

Unexpected Things

The map redesign routing conflict that forced us to start from a fresh branch was the most frustrating technical setback. Could we have predicted it? Maybe — but we were learning some of Expo Router's behaviors only as we hit them.

One more thing worth mentioning: balancing the course deliverables (lab reports, wiki pages, UML artifacts) with actual development was harder than we expected. Some weeks we went all-in on documentation while code work stalled, and then the next week it flipped. We need a better strategy for running both tracks in parallel.

Lessons Learned

• Meeting format matters. Just having meetings isn't enough — how they're run matters just as much. Showing up without an agenda and talking for two hours doesn't give anyone anything; if anything, it drains motivation for the next meeting.
• Don't be optimistic when estimating tasks. Whether we use story points or hours, we should pad our estimates a bit going in. Integration and testing work deserves to be counted as separate tasks, not folded into the feature.
• "We'll deal with it later" usually means we won't. If we don't address communication or process issues right when they come up, we start normalizing them and living with them. We need to break this habit for the next milestone.
• Discipline set up early pays off. Our Git conventions, documentation habits, sub-team structure — these were all decisions that felt like overhead at the start of the semester but saved us a lot of pain later. We need to apply the same logic to communication and task management.

Going Into the Next Milestone

Here's what we want to try differently heading into the next phase:

• A fixed weekly meeting with a short agenda prepared in advance
• Opening issues with much more detail and scope this time around. This is probably the biggest change we want to make. Our issues this semester were often too generic — just a one-line description of a feature, sometimes without even clear acceptance criteria. Going forward, each issue should clearly specify what "done" looks like, break the work down into concrete sub-tasks, include an effort estimate, and list any dependencies on other issues. A lot of our workload imbalance and hidden bottlenecks traced back to vague issues; fixing this alone should solve half of our planning problems.
• Splitting integration and testing tasks into their own issues instead of lumping them with feature work
• A short weekly written sync between sub-teams on WhatsApp — "what we did this week, what we need from you next week" — so that async communication doesn't rely on messages getting noticed in a busy chat

Looking back at the road to MVP, we're glad we worked together on this. We have our weaknesses, but being aware of them is already half of the fix — we'll see the other half play out in the next milestone.