Project Retrospective

Project Retrospective

This page reflects on the progress of the Campus-Neighborhood Mentorship Network project from the beginning of the semester through the MVP milestone (6th milestone). It covers what went well, what went badly or was unexpected, and lessons learned for the final milestone.

---

What Went Well

Team structure and skill utilization: Splitting the team into backend, frontend, and mobile sub-teams worked effectively. Each sub-team had members with relevant skills, which allowed parallel development and clear ownership of components. Internal collaboration within sub-teams was smooth and productive.

Core features delivered: The MVP was delivered with a functional authentication system (registration, login, email verification, password reset), profile management for both mentors and mentees, a recommendation algorithm with keyword search and availability scoring, mentorship request and acceptance workflows, mentor availability scheduling, and an in-app notification system. These cover the foundational user journey from registration to active mentorship.

Importance of realistic testing: During the MVP phase, we realized the value of testing with realistic mock data and scenarios rather than minimal test cases. Working through actual user flows — a mentee searching for a mentor, sending a request, a mentor accepting — gave us stronger intuition about the product's goals and revealed edge cases we would have missed otherwise. This shifted our mindset from "does the code work?" to "does the feature serve its purpose?"

Tooling and infrastructure: We established a solid development foundation early: CI/CD pipeline, database migrations with Flyway, Swagger/OpenAPI documentation, production deployment on DigitalOcean, and a structured GitHub project board for tracking work. These investments paid off throughout the semester by reducing friction and keeping the team aligned.

---

What Went Badly or Was Unexpected

Feature velocity was slow: While the features we delivered were solid, the pace of delivery was slower than it needed to be. Dependencies between backend and frontend meant that frontend work sometimes stalled while waiting for API endpoints, and vice versa. This created bottlenecks and last-minute rushes before milestones.

Lack of iterative development: We tended to build features end-to-end before getting feedback, rather than working in short iterations with early feedback loops. This meant that when issues or misunderstandings surfaced, they were more expensive to fix. For example, the frontend and mobile teams sometimes built against assumptions about API behavior that turned out to be wrong, requiring rework.

Insufficient communication with TA and instructor: We did not engage enough with the TA and instructor to clarify ideas early. The MVP review session revealed new directions (blog system, recommendation with explanations, location-based matching) that could have been anticipated with earlier conversations. We should have sought clarification on scope and expectations before building, not after.

Manual testing through the UI was underutilized: Most of our testing was through unit tests and Swagger/Postman calls. We did not do enough end-to-end manual testing through the actual UI with realistic scenarios. This meant bugs like the mentor profile showing "Request Sent" instead of "Active" status (#258) went unnoticed until late.

---

Evaluation of Activities and Decisions

Architecture decisions: Choosing Spring Boot (backend), React (web), and React Native (mobile) with a shared REST API was the right call. The three-client architecture aligned well with our team structure and allowed independent development. OpenAPI documentation kept all teams in sync on the API contract.

GitHub Projects for tracking: Using GitHub Projects with issues, labels (backend/frontend/mobile/feature/bug), and milestones provided good visibility into work status. However, we could have been more disciplined about keeping issues updated and using start/target dates consistently.

Requirements process: Our initial requirements were thorough but somewhat static. After the MVP review, we learned that requirements need to evolve — the instructor's feedback added new sections (blog, recommendation system, milestones) and restructured existing ones (matching → recommendation). Going forward, we treat requirements as a living document.

---

Lessons Learned and Plan for the Final Milestone

Work iteratively, not sequentially: For the final milestone, we will work in shorter iterations. Backend will deliver API stubs early so frontend and mobile can develop in parallel. We will demo intermediate progress within the team before completing full features, catching misalignments early.

Prototype on paper and through the UI first: Before implementing a feature, we will sketch it out — on paper, in mockups, or as a minimal UI prototype. This helps mature the idea and ensures every feature serves its intended purpose (e.g., progress tracking should clearly show mentorship growth, not just raw data).

Be more product-focused: The MVP review taught us that each feature should serve a clear purpose in the mentorship journey. We will evaluate new features by asking "what problem does this solve for a mentor or mentee?" rather than just checking off requirements.

Communicate earlier and more often with TA and instructor: We will seek feedback on ideas and designs before committing to implementation. A quick conversation with the instructor can save days of building the wrong thing.

More manual testing through the UI: Alongside unit and integration tests, we will do regular manual testing through the actual web and mobile interfaces with realistic data. This catches UX issues and state bugs that automated tests miss.

Minimize dependencies and reduce chaos: By delivering features in vertical slices (backend + frontend + mobile for one feature at a time) rather than horizontal layers (all backend first, then all frontend), we reduce cross-team blocking and deliver working features faster.