A reflection on a 6-week team sprint: covering architectural challenges, the nuances of collaboration, and technical growth through senior feedback.
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
January 1st Priority: Writing My Sprint Retrospective!
Following the 10-week learning sprint, the 6-week group sprint passed in the blink of an eye. As it was my first team project in a long time, I was nervous at first, but meeting like-minded and talented teammates made it an incredibly valuable experience.
Entering the group sprint, I felt a significant amount of pressure. Throughout the previous challenges and learning sprints, I had never fully completed a task, and I worried whether I could keep up with the backend work at my teammates' pace.
Fortunately, I met teammates who agreed to focus on the collaboration process itself rather than just the output. We were able to experience a sprint centered on learning together and understanding each other's code.
We had extensive discussions, sometimes from morning until dawn, repeatedly designing and reviewing a single topic. While opinions on the efficiency of this method may vary, it was a meaningful experience in that every member shared the same context and practiced explaining technical conflicts firsthand.
Although our team consisted of four frontend aspirants, the project had a substantial backend component. Since the frontend's role was primarily UI presentation while core logic was handled on the backend, we faced many difficulties during the design phase. As a non-CS major, my lack of design experience led to frequent trial and error.
Looking back, I believe we could have reduced unnecessary detours if we had defined requirements more clearly and implemented strict modularization from the start. Nevertheless, experiencing firsthand which architectural choices caused issues and how to improve them was a major takeaway.
In the next project, I want to invest more time in the initial design phase to prevent structural issues, such as circular dependencies between modules.
This topic required more CS foundational knowledge than previous assignments. Since I lacked both architectural experience and CS understanding, I felt regretful that I couldn't contribute more actively to the team's design discussions.
Since our team was composed of frontend developers, we prioritized not only the UI but also general conventions like Lint, Prettier, GitHub Projects, and PR rules. I had always hoped for these standards to be well-maintained in a team project, and I was satisfied that we established them effectively this time.
Seeing other teams use Husky or GitHub Actions to automate commits, linting, and testing made me want to adopt these tools in the next project to reduce the overhead for team members.
I was grateful that the organizers left positive comments on our CS learning channel. During the group sprint, the CS quiz format changed from weekly to a three-week cycle. Our team discussed how to utilize this and proceeded as follows:
By looking at the same questions from different perspectives each week, we were able to expand our thinking and naturally reflect on the intent behind the quizzes.
While I regret not conducting the CS learning before the design phase, it was overall a very positive experience, as we might not have explored the topics as deeply without a clear goal.
In previous sprints, I focused so much on implementation that I neglected documentation. However, in a team project, I realized how crucial it is for everyone to understand the progress and be able to reference it later.
We documented scrum notes, meeting minutes, conventions, and PR details. Initially, we organized everything in Notion.
Later, inspired by other teams, we introduced Notion AI summaries and ADR (Architecture Decision Records). ADRs were particularly impressive because they revealed the context behind decisions, and I want to use them actively from the start of my next project.
During the refactoring period, I was responsible for integrating AI features into the project and shared the process 링크 정보를 불러오는 중...
Since the implementation was complex, the documentation took a long time, and I received feedback that I should explain the "Why" more clearly than the "How."
🤔 Reflection
I am still contemplating how to create documentation that is concise yet effectively conveys the necessary context.
Since my college days, I have preferred solving problems through long, collaborative discussions. However, I worried that this might be burdensome if my teammates were introverted.
Fortunately, our team didn't find long meetings uncomfortable, but I began thinking about more efficient ways to communicate for future collaborations with different personality types.
From teammate feedback, I learned that when I haven't reached a conclusion in my head, it's better to voice it (e.g., "I'm still thinking" or "I don't have a strong preference") rather than remaining silent. Despite being someone who often worries about others' silence, I realized I had overlooked this myself a few times.
I've learned that clear expression of intent is essential for a smooth and flexible team project.
Thanks to my presentation experience in college, preparing for the demo was relatively smooth. My teammates participated actively, and the material creation went well.
However, looking back at the report written during the refactoring period, I regret not including more quantitative metrics. Other teams produced reports similar to professional corporate summaries. While our team received feedback that we had a 'good report' during the Master Class, I believe reports with quantitative data are more persuasive in the development field. Practicing this format will surely help in the job-seeking process.
As the weeks passed, work that other teams weren't aware of began to pile up, leading to concerns about how to communicate this effectively during demos. I found myself constantly debating whether to share everything or curate specific parts. Although we prepared specific feedback requests beforehand, we often didn't receive as much as expected. This made me realize we might not have shared the problem context clearly enough, and I need to think about how to elicit better feedback.
I used to view refactoring mainly as code cleanup, removing duplication, separating components based on the Single Responsibility Principle, and improving accessibility. However, seeing other teams' demos, I noticed their refactoring often focused on performance optimization.
During the 2-week refactoring period, I repeatedly asked, "What does our team want to gain from this process?" Since our team already had strong code reviews and conventions, we had few structural or stylistic issues. In contrast, when we looked at other teams' projects, there was more room for improvement in terms of style consistency and reusability.
While such work is meaningful for long-term projects, I felt it had limits in producing quantifiable results within a short 2-week window. Consequently, after an initial focus on structural cleanup, we shifted toward tasks that would provide more practical learning and tangible results for the team.
While the basic rule of refactoring was to improve code without changing logic, our team chose to supplement the unfinished design from the previous phase and added some features. It was an experience of prioritizing the overall project completeness within a limited time.
At the end of the refactoring period, we had the opportunity to receive senior feedback. I prepared a document summarizing our challenges and concerns and approached the session with a nervous heart.
The review made me clearly realize that while I identify problem situations well, I lack the ability to explain them accurately using technical terminology. I received feedback that my explanations of problem-solving processes tended to be abstract and needed more specificity and professionalism.
Since I felt most deficient in architecture and CS fundamentals, having a senior point this out was startling but provided a clear direction for my future studies. I felt a desperate need for more experience in explaining my decisions and processes logically, based on common industry terminology.
The session focused more on team project concerns and personal learning directions rather than deep technical discussions. Seeing other campers engage in deep technical Q&A made me realize I need to work even harder. While I might have struggled to answer those questions at my current level, I've set a goal to become a developer who can confidently explain not only frontend technologies but various technical domains by studying them accurately.
Based on the gaps identified during the group sprint and senior feedback, I plan to proactively build my design capabilities by selecting relevant books. Previously, it was difficult to find time for personal study alongside university classes, but now I can focus entirely on the Boostcamp curriculum. I intend to fill these gaps systematically by focusing on the questions and areas that need improvement each week.
During the group project, I often worked late into the night to avoid being a burden to my team. However, I realized that this actually lowered my concentration during the day and hindered overall efficiency. While I could endure lack of sleep during the 'Challenge' phase, I felt that overexertion during the 'Membership' phase directly impacted my learning and collaboration the next day. Moving forward, I want to find a sustainable way to contribute to the team while maintaining my personal health and life balance.
The 6 weeks spent with my teammates felt both long and incredibly fast. During this time, I experienced firsthand what I lack and how I can improve to become a teammate people want to work with. I will not forget the concerns and lessons organized in this retrospective and will continue to reflect them in my growth. My heartfelt thanks to the F4 Team 7 members who grew and led with me despite my shortcomings.
