Repository

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/frontend_testing_release2026?ref_type=heads

What Worked Well

The biggest thing that worked well during this sprint was teamwork. If someone needed help understanding something, another group member was always willing to help explain it. This created a collaborative environment where people felt comfortable asking questions and getting support when needed. Another thing that helped the team was sharing work through Discord. Team members regularly shared screenshots, code, updates, and examples of completed work so the rest of the group could use them as references, making it easier for everyone to stay updated and understand how different parts of the project were being completed. It also helped reduce confusion because people could directly see examples instead of only hearing explanations. Overall, the team communicated well and supported each other throughout the sprint. Even when some team members worked on different tasks such as documentation and dependencies while others worked on tests, there was still a strong sense of collaboration.

What Didn’t Work Well

One thing that did not go as well as it could have was the amount of testing we completed. While progress was made, we did not create as many tests as we originally hoped to finish by the end of the sprint. Part of the issue was that work was not always evenly distributed across all areas of the project. Because of that, some tasks moved forward faster than others. This slowed overall progress and made it harder to complete the amount of testing we originally planned.

Changes That Could Improve the Team

One improvement that could help the team is following through with a more structured deadline system. Having regular checkpoints where each team member shows what they worked on during the past week would improve accountability and help everyone stay updated on progress. This would also make it easier to identify areas where people may need help before problems build up. Even short progress updates could help the team stay organized and move more efficiently.

Changes I Could Make as an Individual

As an individual, I think I could improve by becoming more comfortable contributing to every aspect of the project. There were certain areas where I felt more confident contributing than others, and I want to continue improving my understanding of the overall development process so I can help more consistently wherever needed. Communication and sharing information with teammates has been vital to progress of this project. Helping others understand things not only benefits the team, but also strengthens my own understanding of the material.

Share What You Learn

The apprenticeship pattern I selected is Share What You Learn. This pattern focuses on openly sharing knowledge, experiences, and discoveries with others instead of keeping information to yourself. The idea is that sharing knowledge helps both the individual and the team grow stronger together. I selected this pattern because it closely relates to my experience during the sprint. Throughout the sprint, I often shared my work with teammates through Discord so they could use it as a reference. I also answered questions and helped explain things when teammates needed clarification. Doing this helped improve communication within the group and made collaboration easier. This pattern is relevant because software development is very team-oriented. When people share what they know, the entire group benefits. It also creates a better learning environment because team members can build off each other’s ideas and experiences instead of struggling individually. If I had fully thought about this pattern earlier in the sprint, I probably would have shared even more updates and explanations with the team. I also would have been more intentional about documenting useful information or explaining my thought process while working. That could have made collaboration even smoother and helped the team learn from each other more effectively.

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

During Sprint 3, our team continued working on the project, but this sprint was more challenging due to dependencies on other teams. A lot of our progress relied on updates from teams like the pipeline and Keycloak teams, which caused delays. Compared to Sprint 2, this sprint felt less productive at times because we had to wait, but I still tried to stay engaged and learn as much as possible. This retrospective reflects on what went well, what could be improved, and how I can grow both as a team member and as an individual.

What Worked Well

What worked well during this sprint is that our team continued communicating and supporting each other even when we were blocked. Everyone stayed responsible and kept working on what they could. I also made an effort to stay involved by asking teammates about what they were working on, which helped me understand different parts of the project such as pipeline issues and authentication. This allowed me to still learn even when I was not actively working on my job.

What Didn’t Work Well

One of the main challenges during this sprint was the amount of waiting required due to dependencies on other teams. Since we were relying on updates from other parts of the system, there were times when there was not much work I could do directly. Personally, I felt bad that I was not able to contribute as much as I wanted during those moments. Communication could also feel delayed because we were waiting on responses or progress from others, which slowed down the overall workflow.

Improvements as a Team

To improve as a team, we could focus on identifying blockers earlier and planning alternative tasks when we know we might have to wait. This could include working on documentation, testing, or smaller independent tasks while waiting on dependencies. Improving communication with other teams and following up more consistently could also help reduce delays and keep progress moving forward.

Improvements as an Individual

As an individual, I can improve by being more proactive when I am blocked. During this sprint, even though I had to wait at times, I tried to ask questions and understand what others were doing so I could learn from their issues. Moving forward, I want to continue doing that while also looking for additional ways to contribute, even if it is through smaller tasks or supporting teammates. I also want to be more confident in stepping in and helping wherever possible.

Apprenticeship Pattern: “Be the Worst”

The pattern I selected is “Be the Worst” from the Apprenticeship Patterns book. This pattern encourages putting yourself in environments where you are not the most experienced person so that you can learn from others and grow.

This pattern is relevant to my experience during Sprint 3 because there were times when I felt like I was not contributing as much due to waiting. Instead of disengaging, I tried to use that time to observe, ask questions, and learn from my teammates. By doing this, I was able to gain a better understanding of areas like pipeline debugging and authentication, even though I was not directly responsible for them.

Having read this pattern earlier, I would have been even more intentional about learning during those moments. Instead of focusing on the lack of tasks, I would have fully embraced the opportunity to grow by learning from others. This mindset can help me become a stronger developer over time.

Final Thoughts

Overall, Sprint 3 was more challenging than Sprint 2 due to external dependencies and delays. Even though there were moments where progress felt slow, the sprint still provided valuable learning opportunities. I made an effort to stay engaged, learn from my teammates, and contribute where possible. Moving forward, I want to be more proactive and continue improving both my technical skills and my role within the team.

There is no Gitlab link because the job I worked on had to do with cross communication with other teams which I did in person or in our discord chat.

From the blog CS@Worcester – Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

The biggest thing I worked on was setting up and organizing the local Keycloak server files so that our project could run Keycloak locally for testing. It involved understanding how Keycloak runs, how the frontend might eventually communicate with it, and how authentication fits into the larger IAM system. I am definitely not a Keycloak expert, but I understand it much better now than I did at the beginning of the sprint. Now I understand how it all connects much better. My most recent merge request: Keycloaktesting, starts to add a portion of the local server. It is currently missing an import file to configure the Keycloak realm on another device, but I am currently working on a second merge request that will add this.

One thing that went well this sprint was the progress made in understanding Keycloak, especially in authentication. Authentication can get confusing quickly because users, roles, clients, realms, tokens, and permissions all sound similar at first. During this sprint, I started to see how those pieces connect a little more clearly. The local setup gave us something more concrete to work with instead of just talking about Keycloak in theory.

What did not go well was the combined workflow of all teams. When working on a project like this with six teams it is inevitable that portions of the project will be touched by multiple teams. This can cause bottlenecks where one team is waiting for another to continue working. When one part of the system is not ready yet, it can slow down the teams that are waiting to build on top of it. That is a normal part of software development, but it still created some challenges for us near the end of the sprint.

Something I could improve on personally is taking more initiative when our work depends on another team’s progress. I could have checked in earlier, asked clearer questions, and identified blockers sooner. I did start to communicate towards the end, but it was too little too late and I should’ve taken a much earlier initiative. Even if I am not the person responsible for another team’s work, I can still ask for updates, clarify what our team needs, and help keep things moving in a respectful way. I am still responsible for making sure I do all that I can to create an efficient environment.

For my apprenticeship pattern, I think The Long Road fits this sprint perfectly, especially since this is the end of the course. This pattern is about understanding that becoming a better developer is a long process, not something that happens all at once. At the start, a lot of the authentication work felt overwhelming. There were many times where I did not fully understand what was happening, but each sprint helped me build a little more knowledge. Sprint 3 reminded me that progress in software development is not always fast or clean.

Looking back at the course, I can see that I have improved not only in technical skills, but also in how I approach unfamiliar problems. I became more comfortable reading documentation, asking questions, using GitLab, working through merge requests, working with other teams, and dealing with issues that do not have an obvious answer right away. I did not leave the course knowing everything, but I did leave with a better understanding of how much there still is to learn and how to keep moving forward.

Overall, Sprint 3 was not perfect, but it was a useful final sprint. We made real progress with Keycloak, developed a deeper understanding of authentication, and saw firsthand how coordination matters in a larger software project. The Long Road feels like the right pattern to end on because this project made it clear that software development is not about mastering everything immediately. It is about continuing to learn, building skills over time, and staying patient enough to keep improving. I am beyond grateful for everything this course has taught me.

From the blog DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

Wow, this sprint felt like it started yesterday, and here I am writing my last Sprint  Retrospective. Even though it went by really quick, we did a lot and finished everything that we had planned out. During our last sprint we worked on the InventorySystem Weight-Based system and unlike other sprints, this time we did a bit differently. Our goal was to tackle another system and complete it before the semester ended. In order to do that, we decided to give each system to each member a member of our team. Now we have gained the experience and knowledge on what we should do. This involves tasks and issues that go beyond just updating dependencies. This includes tasks such as fixing any errors and bugs, fixing any security issues that might come when moving up major updates, updating mongoDB, rabbitMQ, node and docker images.

Now that we have gained a lot of experience and knowledge about the work that we need to do, everyone went to work individually and do everything by themselves. This is also a great way to test ourselves and see if we can apply our skills to a new system. These are the commits that I made during this sprint.

Here, I updated all of the dependencies in the main file: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weightbased/checkoutguestfrontend/-/commit/31763a8b742e10ea5e4f2eaaf42c3ed36796bb67

Node image was upgraded to node 34: https://gitlab.com/LibreFoodPantry/clientsolutions/theaspantry/inventorysystemweightbased/checkoutguestfrontend/-/commit/dff569a2aa4f5014b651b152c7b1ccd3effd4363

In this commit, I updated the MongoDB to image 8, and node to 4.0.8-24-bookworm: https://gitlab.com/LibreFoodPantry/clientsolutions/theaspantry/inventorysystemweightbased/checkoutguestfrontend/-/commit/98754c13d25f63885a5e3770d88eede8fdae0935

Here I updated the RabbitMQ image to 4.2.4, and MongoDB image to 8: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weightbased/checkoutguestfrontend/-/commit/27fe225bddbbadc65a80ab10e70f7fffd2868141

Finally, I updated all of the dependencies to their latest version in the src file: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weightbased/checkoutguestfrontend/-/commit/38db567fae1d9df34918b238cbf0c5cee075e815

I also merged our branch into the main branch, and it passed on successfully: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weightbased/checkoutguestfrontend/-/commit/c97a3df8141b3ddcbff442d7658e2613a2ecd42a

I think the way we approached our sprints, where each goal was a bit more ambitious than the previous one worked pretty well. This way we prevented ourselves from getting too comfortable to the points our new skills started to get dulled. We did an amazing job of documenting everything, from keeping notes and sharing to the team even for the smallest things, to helping each other out when debugging a pesky error. Our communication outside of class was excellent as well, and honestly, I wouldn’t change a thing about how we did things for the semester. We are also going to give some notes and advice for the future teams. Simple stuff that they can do at the start of their sprints. This can help them dramatically and make them more efficient. 

One pattern from the textbook that really resonated with me during this sprint was “Share What You Learn ”. This pattern specifically was really important to all of us as each member was working on a specific system and being able to to quickly update our team members or from another team is really crucial. For example I noticed the the http calls were not working and how the uuid was in the old format. This is not something within my duties but I still had to let the team that was working with the InventorySystem Weight-Based know about this situation. Other scenories when this pattern become really useful was if a team member asked me for some help and he had to explain to me what problem that he was facing. In order to do he should have the skills to effectively communicate with me and bring me up to date without taking forever. This skills can be overlooked at times but they are so useful especially when working in a large scale project with a lot of different people and teams collaborating together.

From the blog CS@Worcester – Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Naturally, it would have been nice to finish all of our goals. We fell a bit short like we did during the last sprint, however this time around it wasn’t due to the sprint being cut short but more so due to being a bit too ‘ambitious’ with our goals. The frontend test drafts took up the majority of the sprint, bleeding into the first and last week of it. While we worked on some of the goals in tandem (namely the documentation), this hardly left us enough time to even get started on the subsequent goals. I think there was a lot of room for improvement in regards to time management, but I was pretty familiar with the pace at which our team worked at that point and simply put too much on our plate. Individually I was also pretty bad with explicitly blocking out time to work on this class, I was a bit overwhelmed with all of my finals and other projects and didn’t was consistently unable to work as much as I would have wanted (I don’t intend to use this as an excuse, this IS another class after all). Google calendars has become a good friend of mine recently, maybe he could have helped with this class as well. I wouldn’t say our sprint was a failure, however, or even anything remotely close. We were still able to get a considerable amount of work done, and our group over the last half of the capstone has been working very well together. There has been virtually no friction between group members, everyone is communicative and no one really fell behind in regards to how much they pitched in. 

For this sprint, the apprenticeship pattern from the book I mentioned in my previous retrospectives, I think ‘Reflect as You Work’ is a good choice. Now, I am not choosing this one because it was something I actively did during the sprint, but because it is something I believe would have been very helpful to keep in mind. It says to ‘constantly think about how you are working’, which I think applies to things like pace and efficiency as well. That little bit of extra optimization in that regard, I think, would have given us more time to work on a few of the other sprint goals as well.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Naturally, it would have been nice to finish all of our goals. We fell a bit short like we did during the last sprint, however this time around it wasn’t due to the sprint being cut short but more so due to being a bit too ‘ambitious’ with our goals. The frontend test drafts took up the majority of the sprint, bleeding into the first and last week of it. While we worked on some of the goals in tandem (namely the documentation), this hardly left us enough time to even get started on the subsequent goals. I think there was a lot of room for improvement in regards to time management, but I was pretty familiar with the pace at which our team worked at that point and simply put too much on our plate. Individually I was also pretty bad with explicitly blocking out time to work on this class, I was a bit overwhelmed with all of my finals and other projects and didn’t was consistently unable to work as much as I would have wanted (I don’t intend to use this as an excuse, this IS another class after all). Google calendars has become a good friend of mine recently, maybe he could have helped with this class as well. I wouldn’t say our sprint was a failure, however, or even anything remotely close. We were still able to get a considerable amount of work done, and our group over the last half of the capstone has been working very well together. There has been virtually no friction between group members, everyone is communicative and no one really fell behind in regards to how much they pitched in. 

For this sprint, the apprenticeship pattern from the book I mentioned in my previous retrospectives, I think ‘Reflect as You Work’ is a good choice. Now, I am not choosing this one because it was something I actively did during the sprint, but because it is something I believe would have been very helpful to keep in mind. It says to ‘constantly think about how you are working’, which I think applies to things like pace and efficiency as well. That little bit of extra optimization in that regard, I think, would have given us more time to work on a few of the other sprint goals as well.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Naturally, it would have been nice to finish all of our goals. We fell a bit short like we did during the last sprint, however this time around it wasn’t due to the sprint being cut short but more so due to being a bit too ‘ambitious’ with our goals. The frontend test drafts took up the majority of the sprint, bleeding into the first and last week of it. While we worked on some of the goals in tandem (namely the documentation), this hardly left us enough time to even get started on the subsequent goals. I think there was a lot of room for improvement in regards to time management, but I was pretty familiar with the pace at which our team worked at that point and simply put too much on our plate. Individually I was also pretty bad with explicitly blocking out time to work on this class, I was a bit overwhelmed with all of my finals and other projects and didn’t was consistently unable to work as much as I would have wanted (I don’t intend to use this as an excuse, this IS another class after all). Google calendars has become a good friend of mine recently, maybe he could have helped with this class as well. I wouldn’t say our sprint was a failure, however, or even anything remotely close. We were still able to get a considerable amount of work done, and our group over the last half of the capstone has been working very well together. There has been virtually no friction between group members, everyone is communicative and no one really fell behind in regards to how much they pitched in. 

For this sprint, the apprenticeship pattern from the book I mentioned in my previous retrospectives, I think ‘Reflect as You Work’ is a good choice. Now, I am not choosing this one because it was something I actively did during the sprint, but because it is something I believe would have been very helpful to keep in mind. It says to ‘constantly think about how you are working’, which I think applies to things like pace and efficiency as well. That little bit of extra optimization in that regard, I think, would have given us more time to work on a few of the other sprint goals as well.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Naturally, it would have been nice to finish all of our goals. We fell a bit short like we did during the last sprint, however this time around it wasn’t due to the sprint being cut short but more so due to being a bit too ‘ambitious’ with our goals. The frontend test drafts took up the majority of the sprint, bleeding into the first and last week of it. While we worked on some of the goals in tandem (namely the documentation), this hardly left us enough time to even get started on the subsequent goals. I think there was a lot of room for improvement in regards to time management, but I was pretty familiar with the pace at which our team worked at that point and simply put too much on our plate. Individually I was also pretty bad with explicitly blocking out time to work on this class, I was a bit overwhelmed with all of my finals and other projects and didn’t was consistently unable to work as much as I would have wanted (I don’t intend to use this as an excuse, this IS another class after all). Google calendars has become a good friend of mine recently, maybe he could have helped with this class as well. I wouldn’t say our sprint was a failure, however, or even anything remotely close. We were still able to get a considerable amount of work done, and our group over the last half of the capstone has been working very well together. There has been virtually no friction between group members, everyone is communicative and no one really fell behind in regards to how much they pitched in. 

For this sprint, the apprenticeship pattern from the book I mentioned in my previous retrospectives, I think ‘Reflect as You Work’ is a good choice. Now, I am not choosing this one because it was something I actively did during the sprint, but because it is something I believe would have been very helpful to keep in mind. It says to ‘constantly think about how you are working’, which I think applies to things like pace and efficiency as well. That little bit of extra optimization in that regard, I think, would have given us more time to work on a few of the other sprint goals as well.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Naturally, it would have been nice to finish all of our goals. We fell a bit short like we did during the last sprint, however this time around it wasn’t due to the sprint being cut short but more so due to being a bit too ‘ambitious’ with our goals. The frontend test drafts took up the majority of the sprint, bleeding into the first and last week of it. While we worked on some of the goals in tandem (namely the documentation), this hardly left us enough time to even get started on the subsequent goals. I think there was a lot of room for improvement in regards to time management, but I was pretty familiar with the pace at which our team worked at that point and simply put too much on our plate. Individually I was also pretty bad with explicitly blocking out time to work on this class, I was a bit overwhelmed with all of my finals and other projects and didn’t was consistently unable to work as much as I would have wanted (I don’t intend to use this as an excuse, this IS another class after all). Google calendars has become a good friend of mine recently, maybe he could have helped with this class as well. I wouldn’t say our sprint was a failure, however, or even anything remotely close. We were still able to get a considerable amount of work done, and our group over the last half of the capstone has been working very well together. There has been virtually no friction between group members, everyone is communicative and no one really fell behind in regards to how much they pitched in. 

For this sprint, the apprenticeship pattern from the book I mentioned in my previous retrospectives, I think ‘Reflect as You Work’ is a good choice. Now, I am not choosing this one because it was something I actively did during the sprint, but because it is something I believe would have been very helpful to keep in mind. It says to ‘constantly think about how you are working’, which I think applies to things like pace and efficiency as well. That little bit of extra optimization in that regard, I think, would have given us more time to work on a few of the other sprint goals as well.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A lot of time was spent doing so, as there was nothing else to add to our project. So to say, we did a very good job with this project. I spent this sprint finally completing the developer documentation for the frontend webpage. I applaud myself for deciding to go ahead and complete this entirely without structure, as I was having great difficulty finding a documentation template for this. I have the Google Docs link listed below; however, upon successfully pushing my changes to GitLab, I will update the link so it shows the GitLab link.

Frontend Webpage(s) Developer Documentation: https://docs.google.com/document/d/1D5IjaHZviKvQbYYMsmIteg4MTlqbwAZxMq0-R82oMbU/edit?usp=sharing

Team Dynamics:
Our team dynamic continued to be a major strength throughout this final sprint. Despite trying to find anything to work on, we still maintained excellent communication. What worked well for us was continuing to check in to see if there was anything to be completed. I had shared an issue with a member in hopes of getting through our issue board quickly, as I was still working on the developer documentation; this teammate was happy to help.

In terms of improvement, I do not believe there is anything to improve during this sprint. Everything went according to plan, everyone was still communicating with one another and working on their issues, or trying to find an issue to complete to maintain progress on the project.

Reflection:
On an individual level, the decision to simply start working on the developer documentation despite not knowing the “perfect” way to structure it, really helped me break through the barrier of getting started. Instead of staying stuck in silence, waiting for the “perfect template,” or waiting for something to give me what I believe I was looking for; I took the initiative to format the document myself. I copied the code into a structured format and explained each block in detail. 

I want to continue improving my ability to create structure in ambiguous situations. I have learned that in software development, the “right” way to do something is not always handed to you in a pretty formatted template. Sometimes, you have to look at the existing system, like I initially did with the LibreFoodPantry docs, and create your own solutions. Especially if you found navigating those resources, to be not what you were looking for. 

Apprenticeship Pattern:
For the pattern that speaks most to me during this sprint, I choose the “Record What You Learn” pattern.

This pattern emphasizes the importance of documenting your journey, specifically the solutions you find to problems and the “know-how” you acquire it. It suggests that by keeping a record of your learning and the structures you build, you prevent knowledge from being lost and create a resource that helps both you and (potentially) your teammates. 

I chose this pattern because it directly aligns with my taking initiative to complete the developer documentation. With how long I decided to wait, and ask, and search for the “right” way to create this documentation; I found it more helpful to create my own template/structure and move forward with that. Not only because it worked for me, but because it is a document that can be changed by future students who work on this project. It is not fixed, but it absolutely helps anyone understand our code– which was the entire point. Taking the initiative helped me break out of this cycle of feeling like documentation needed to be completed in a certain way, and helped me understand that there is more freedom to this art than I thought.

Had I embraced this pattern earlier, I would have spent MUCH less time worrying about finding a “correct” template and more time realizing, truly realizing, that I was the one creating the template. I would have approached the issue with more confidence, knowing that any record I created was better than leaving the next team with no guidance at all (and again, it can always be edited for future use). 

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.