Upon completing our first sprint and gathering for our retrospective meeting, it’s essential to reflect on what went well and identify areas where we can improve moving forward. Here’s a breakdown of our observations:

Reflection on what worked well:

• We successfully completed most of the small issues, achieving a completion rate of around 75%, which demonstrates our ability to tackle tasks effectively.
• Our meetings, though limited in frequency, were productive and provided valuable opportunities for discussion and collaboration.
• The quality of communication within the team was commendable, fostering a supportive and transparent environment for sharing progress and addressing challenges.

Reflection on what didn’t work well:

• We encountered challenges with Docker-compose issues and documentation, which impacted our ability to complete tasks efficiently.
• Despite aiming for a total weight of 20, we only managed to achieve 15, indicating a discrepancy between the assigned weights and the actual difficulty of the tasks.
• Details for issues were not easily accessible, as they were only located within the epics, leading to confusion and inefficiency.
• Issue distribution was uneven, with some team members shouldering heavier workloads than others.
• All GitLab logistics were handled by one person, potentially causing bottlenecks and hindering collaboration.
• Individuals tended to work on issues independently, lacking assistance or support from other group members.

What changes could be made to improve as a team:

Better teamwork should be our top priority if we want to grow as a group. To do this, we should encourage teammates to help one another out when necessary and promote cooperation and knowledge exchange. Furthermore, by more precisely allocating weights in light of the lessons we learned from the previous sprint, we can guarantee that activities are appropriately scoped and assigned, averting disparities in workload allocation. Cooperation and efficiency will be enhanced by improving our knowledge of using GitLab and proactively supporting team members when necessary. Furthermore, it can facilitate communication and task execution to make issue details directly accessible from the issue itself, as opposed to only from the epic. Lastly, delegating tasks to one another instead of having one person do them all helps spread responsibilities fairly and encourage a sense of ownership among team members.

Works that I was assigned for and what changes could be made to improve as an individual:
During the previous sprint, I tackled two tasks within the ReportingBackend and ReportingIntegration projects for our LibreFoodPantry endeavor. For the first task, I was assigned with renaming the “commands” folder to “bin” (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/19) for both Reporting Backend and Reporting Integration. This involved not only simply renaming the folder but also ensuring that any references to “commands” within the codebase were updated to “bin” to maintain consistency. Although I successfully made the necessary changes to the scripts paths and ensured the projects ran smoothly, I overlooked updating all related documentation, which remained referencing the old paths.

For the second issue, I took on the challenge of integrating the AlexJS linter into the ReportingIntegration project’s pipelines (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/16). While initially encountering difficulties due to missing scripts, I leveraged external resources provided by our professor to overcome these obstacles. However, my decision to ignore certain files in the AlexJS test led to later feedback about refining this approach.

Moving forward, I recognize the importance of meticulous attention to detail and thoroughness in my work to avoid similar oversights and prioritize spending ample time on each task.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

What Worked Well And What Didn’t:
After completing our first sprint and conducting our retrospective meeting, I would say that sprint #1 went really well. As a group, we were given three weeks to complete a total of thirteen different tasks for a total weight of 25, and only fell short of one for a total weight of 20 out of 25. What worked well with the team was that we all knew each other, allowing us to be comfortable with asking different questions or for assistance. Additionally, we were able to schedule weekly meetings whether virtually through Discord or in person. These meetings allowed everyone to be informed about project progress, issues, and next steps. Communication was a major successor for this sprint, further accelerating our knowledge within the project. For what didn’t work well, our timing of working on the project was slightly off. We gradually contributed but didn’t get the ball moving until the end of our sprint. I could understand this as some of us were unfamiliar with the functionality of GitLab and GitPod, and what was completed in the project. For the next sprint, working on the project little by little right when we start and understanding what we are dealing with, will provide us time to discover issues, figure out how to handle them, and complete our tasks in a timely fashion. Additionally, we should consider having a better review process to ensure everyone gets to review work.

Improvements As A Team:
To improve as a team, it would be great to further improve our communication. On days that we don’t have scheduled meetings, possibly posting an update on what everyone is currently completing, any problems they have, if someone needs something reviewed, and if they need help from another person on the team that may have knowledge on what they are working on could be beneficial. Also I believe we should begin working on our issues from the start rather than stressing and cramming everything all at once at the end of the sprint. We should also implement a better reviewing process.

Improvements As An Individual:
As someone who had just stepped into the project, I was unfamiliar with navigating through GitLab to find different things, what was completed within the project, and what needs to be worked on. After researching different things and searching through various repositories, I was able to figure this out. I was able to complete three issues individually and one issue as a group particularly working within the InventorySystem of the Theas Pantry project. My first issue was GitPod Dev Environment in InventorySystem/General. This involved having the Theas Pantry project work with VSCode in GitPod, rather than devcontainers. The second issue I completed was also GitPod Dev Environment in InventorySystem/InventoryAPI. I completed the same work to have VSCode work in GitPod rather than in devcontainers. My third issue was Move From ‘commands’ to ‘bin’ in InventorySystem/InventoryBackend. This issue involved changing the file name from commands to bin, updating all script paths to use bin, and ensuring pipeline stages like build, test, and release all functioned properly. I ran into an issue with the test pipeline for this specific task as files were missing. To correct this, I had to disable the test pipeline and plan on fixing this in the next sprint. The last issue I worked on was with my group, GitPod Dev Environment in InventorySystem/Documentation. We completed the same work to have VSCode work in GitPod rather than in devcontainers. To improve as an individual in future sprints, I would like to complete a little bit of work each day, rather than trying to just complete as much as I possibly can all at once. I spent a lot of time working on my issues and when something didn’t work, I’d burn myself out trying to figure out what the problem was. In future sprints, completing issues piece by piece can allow me to have a fresh mindset each time I work on the project and complete tasks in a faster, more efficient manner. Additionally, by completing a little bit each day, it can take away stress from time constraints and allow me to ask questions, get reviews, make changes, and improve the quality of my work.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Merge branch ‘jlee1999/vscode-issue’ into ‘main’ (4ca23d2d) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

One of the problems I ran into came when combining issues within the same branch. For instance, within this one merge request to ReportingSystem General, there were three issues that were worked on which ruined the commit messages when squashing the branch. The commit messages would only reflect one of the issues being fixed rather than three separate commit messages that are associated with a particular issue.

Merge branch ‘jlee1999/gitpod-setup’ into ‘main’ (c2ec7bc6) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

This issue was in ReportingSystem Documentation and the task was to change the folder “commands” to “bin” to avoid any syntax errors within the code. This also required the refactoring of the code/files wherever “commands” was located so that it was changed to “bin”.

Merge branch ‘alexjs_linter_add’ into ‘main’ (6f9c803f) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / ReportingBackend · GitLab

This issue was in ReportingBackend and asked to add AlexJS linters to the pipelines. This required enabling the AlexJS test in gitlab-ci.yaml file so that the test would run through the pipelines when committing any changes.

Merge branch ‘jlee1999/alexjs-linter’ into ‘main’ (443debe1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

This issue was also related to adding AlexJS linters to the pipeline of GenerateWCFBReportFrontend to check the indicated files for any problems.

Merge branch ‘jlee1999/gitpod_setup_branch’ into ‘main’ (636896d3) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryIntegration · GitLab

This issue revolved around adapting InventoryIntegration to allow VSCode to work in Gitpod. There were some complications with this issue since this was the first issue I worked on and not all the pipeline tests passed when committing the changes.

For the first Sprint I think that there were a few things that went well during the process. I made sure that I would not get stuck on one issue for a long period of time so that way it did not hinder our overall progress through the other issues we needed to work on. A lot of the issues we were assigned revolved around the same thing, which made it easier to fix once solving the first issue in a repository. For example, setting up AlexJS linters to pipelines was required for us in multiple repositories in Thea’s Pantry, so once we figured out how to solve the first issue it was easy to carry over the same solutions to the other required repositories. The more I started working in GitLab and Gitpod/VSCode, the more comfortable I got with the layouts. This will continue to help through later issues and sprints as there is still more I can learn which will make it easier to fix different issues.

While there were positives to take away from my first experience in a Sprint setting, there were some things that did not work as well that hindered the overall progression of the project. At first, I forgot to create a separate branch when working on my first issue but then realized after committing the changes to the main branch. Luckily it was nothing too major that I was changing so it did not affect the entire repository. I personally would get caught up in too many issues at once and bounce around through multiple at a time.

I think the main thing that the team can improve on for the next sprint is more communication amongst everyone. The more communication there is, the easier it will be to identify what each team member is working on at the time. Letting each other know when there is a merge request to be reviewed will make it quicker to get through each issue and identify any mistakes that might arise in merge requests. As an individual, I can improve my focus on one issue at a time rather than working on multiple issues at once.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Overall I think sprint 1 went well. I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. We had times when life got in the way and work didn’t get done and we made sure to let each other know. We were also open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. All of us displayed aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part. 

I worked on 4 issues in total. I worked on one with the group and 3 on my own. The issue I worked on with the group was “Gitpod Dev Environments -InventorySystem/Documentation”. In this issue, we set up the files needed to configure the Gitpod Dev Environment for Inventory System Documentation and asked any questions we had to make sure the rest of the similar issues would go smoothly. The issues that I completed on my own throughout the sprint were “Move from `commands` to `bin` – InventoryAPI”,” Add AlexJS linter to pipelines – InventoryAPI”, and “Add AlexJS linter to pipelines – InventoryBackend”. The “Move from `commands` to `bin` – InventoryAPI” issue was a bit difficult because there was no build or test file. I figured out that I had to disable those two jobs for the pipeline to run. For both of the issues the lint.sh files weren’t created during the “move from commands to build” issues for the respective projects so I copied the file from a project that already had one. Because I knew that all of the linters that were included in the file also applied to each of the projects I worked on, I left those linter commands along with the command for AlexJS. However, I only enabled AlexJS in the pipelines for since the issue was only created to add AlexJS and we planned on adding the rest of the linters to the pipelines of the projects during sprint 2.

As a team, I think we did fairly well but we needed to adjust how we work to ensure there is evidence of everyone’s contribution on GitLab. Most of the communication was through discord which resulted in a good amount of the team receiving a poor individual grade for sprint planning. We realized this and decided to split up adding issues and weight for the sprint planning and backlog refinement for future sprints. We also did not rotate reviewing issues as we originally planned when creating our working agreement. In future sprints, we plan to set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. We aren’t sure if we would like to set time aside during our weekly meeting on Discord or set a system where one would just review the last issue in the “needs review” column. As an individual, I need to make sure I’m on top of my work throughout the sprint. Although life can get a bit hectic, I need to make sure I am pulling my weight for the team. I want to plan specific days where I work on issues to stay on track.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

This sprint, I handled the Gitpod Dev Environment implementation for the Reporting System, specifically for the Reporting Integration, Reporting Backend and Reporting API repositories. I also acted as the scrum master for the team, handling most of the logistics and communication with the product manager.

Gitpod Dev Environments: Import extensions via the .gitpod.yml file, set workspace settings via the .vscode settings.json file.

In terms of what went well, we did complete most of the issue weight (75% of the weight assigned for the sprint was dealt with). Speaking with my team members, we agreed that the meetings were productive and efficient, and we didn’t waste time on any of the meetings we had. I made it a point to not have meetings that could have been done over a short text conversation, and it seems to have paid off. We also agreed that the communication that did occur was quality communication.

While we completed most of the work for this sprint, there was still 25% of the weight left. This was entirely comprised of the Reporting System Deployment issues where we had to write docker-compose files to set up MongoDB local volumes. In talking with the team, we thought that the weight didn’t reflect the difficulty of the task. In retrospect, looking at the Deployment epic again I can see that there was a lot of confusion, not only because of having to read through documentation for Docker, but also because the initial task that was to be done before the implementation through docker-compose files (the actual mounting of local volumes from MongoDB) was not accomplished by another team, and was even removed from their sprint. This was excacerbated by the approach we took, where each one of us worked on issues individually without much assistance from other group members. This changed towards the end when two team members worked on the deployment together, but by then it was still ineffective, especially considering the uneven distribution of issues. It seemed like the weight of issues did make sense in a vacuum, but considering that I did all of the Gitpod Dev Environment issues for example, it was obviously very quick to complete 4 weight when the first 2 weight was done, because it’s an application of what I just did.

Another consideration: I think having one person (me as the scrum master) deal with a lot of the issue-creating and handling GitLab logistics was efficient, it didn’t lend itself to the most clear working environment for my team members that weren’t very well acquianted with the workflow. Details were located in epics rather than easily accessed directly in the issue that was assigned, and it made it more difficult to see what you were actually working on. In addition, it made it seem as though I did all of the work in the activity log when in reality it was a cooperative process, and the byproduct is that I end up with all of the credit as well.

For next sprint, we should better assist each other as necessary on issues when complications arise. We should assign weights more accurately based on our experience on the last sprint, and allow all team members to share responsibilities on GitLab, both for learning and to better tell what’s going on. As an individual, I should be more proactive as scrum master to really address problems as soon as they arise, rather than leaving everyone to their own devices as long as they check in. With these adjustments, I think our team will be able to perform much better in the next sprint.

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

Greetings everyone, I hope you all had a fantastic spring break. As we begin a new week, I wanted to take a moment to reflect on the recently concluded sprint 1. Undoubtedly, it was a unique experience for all of us as we delved into the real-world work environment. For many of us, including myself, it was a significant learning curve as we navigated the intricacies of our new job. However, I firmly believe that the challenges we faced during sprint 1 provided us with an excellent opportunity to develop our skills and learn from our mistakes.

Personally, I found myself drawing on the knowledge I gained from my computer architecture class in the fall of 2021. Although there was a long gap between that class and my current class, I was able to recap the essential concepts I learned in the CS-343 class, which proved to be incredibly helpful in my work. As we move forward with the next sprint, I am confident that we will continue to learn and grow, both as individuals and as a team. Let’s take the lessons we learned in sprint 1 and use them to make even greater strides in sprint 2.

As a team, we faced challenges during the first sprint, needing more time to learn how things work. However, we did our best to adapt and make progress. Moving forward, we will continue to improve our work process and complete tasks efficiently.  During the first sprint, I faced an initial hurdle with getting visual studio code and docker to work on my new laptop. Fortunately, my Scrum Master and Professor were extremely helpful in guiding me through the process, and I was able to overcome the issue with their assistance.

After resolving the initial challenge, I was able to focus on other aspects of the work, and I quickly identified a pattern that required my attention. I noticed that the variables in the code were being declared with ‘var,’ even though they did not change throughout the program. Thanks to the previous team’s efforts, I was able to change these variables to ‘let’ or ‘const’, in a little amount of time. The second issue that I encountered during the sprint involved removing MongoID from guestinfoAPI. To accomplish this, I had to delete the MongoID schema from the schema folder and remove the schema from the Index.yaml file. With these changes implemented, the guestinfoAPI was updated and functioning as intended. To resolve the third issue, I updated the code in the Dockerfile to replace the existing Swagger CLI image with a multi-architecture version. This was done to ensure that there were no issues running the code on my M1 laptop and to ensure compatibility with other devices. By using a multi-architecture version, the code could run smoothly on different architectures and avoid any potential conflicts or errors.

To improve team performance in the next sprint, dividing the workload efficiently is crucial. This will ensure that tasks are assigned according to each team member’s skills and expertise, leading to a streamlined development process and successful outcomes.

Links to GitLab issues:

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/62  “Change ‘var’ variable declarations to ‘let’ [or to ‘const’ when they don’t ever change]”
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/92 “Remove MongoID schema for GuestInfoAPI”
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/93 “Replace swagger-cli image with multi-architecture version”

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

This week, the first sprint has concluded! And boy, there was a lot to learn and improve upon. For one, within my group, I was the Scrum Master, and it is a bit harder than I anticipated. I had some ideas to organize coming into it already, but sometimes, ideas don’t always meet with reality. At times, things were really effortless, and at others, they were rather difficult.

Some things that worked really well, was the overall organization. As a group, I realized that we were all heading into unknown waters, working with a code base that, though we had some idea of, in reality, we truly had no idea how much of it worked. Because of this uncertainty in many areas, I knew it was crucial to try and share our knowledge with each other as the sprint progressed. Some of the biggest boons, and though it was a bit of luck as well, was splitting our different members into the different portions of our issues.
As an example, we had a cluster of issues in our frontend, backend, and API that dealt with the same thing. Essentially, we had to update/add lots documentation, licenses, etc! This looked very simple at first, but there was some difficulty with clarity, since we simply weren’t familiar with what the specs were. We split three of our members into the three issues, and as we worked on the issues, I made a effort to make sure everyone is keeping each other updated, and this allowed us to realize that despite it being the same issue, we were actually doing things differently from one another. This allowed us to quickly establish what we should do as a group, and from there, we were able to progress forward without additional confusion.

Although things did work well because of our constant sharing of what we learned, not everything went smoothly. Some things that I tried to do as Scrum Master was make sure my group was not overly pressured or crunched for time. In my initial thoughts, I figured that we would have enough ‘brawn’ to sort out the issues with some commitment, and knowing how stressful a time crunch can be, I was very, very lax at times when important issues were being resolved. This relaxed attitude helped with the team morale, but it also did not do much to help with the issues and even stalled some issues. Moving forward, I hope to strike a balance between calming the team when things are not coming to a close, and trying to nudge them forward more when the deadlines are approaching.

As a team, I genuinely believe that we did very well. The biggest flaw in our teamwork, was not actually when we collaborated, but some team members doing things on their own, but these were only very minor issues such as changing issue names without telling anyone, which caused some confusion, as well as encountering a problem and trying to fix it without telling any other group members. Both instances, were very minor at best, and as soon as they were noticed, were stamped out already. Specifically, we know that moving forward, all group members need to try to communicate problems with the team before silently fixing them, and if a issue needs a new name, the new name needs to properly describe what the issue is.

Individually as well, I believe that I was very caught up with making sure that the team functioned, and though that was a great thing, it also negatively impacted my performance as an individual. I oversaw much of the progress, and was kept updated on how various systems worked, so I believe I have a good understanding of how the project works, but I have very little real work to show for it. Moving forward, despite being the Scrum Master, I have to not only manage the group and keep an eye on things, but also use my own abilities to push things forward.

Updating Dev container files
Updating/adding Documentation, licensing, etc

Finally, as much as there was lacking, I believe that moving forward, things will be much smoother. Our group has many great developers, and this was our first time doing a sprint. I already have many ideas on how to improve, and though it might be a bit of trial and error at times, we as a team, have all the ability to clear out our issues!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.