After the completion of our first sprint, I believe our team performed very well. There were no issues left in the sprint backlog at the conclusion of the sprint, and, equally important, our understanding of how the Thea’s Pantry reporting system needs to work has grown significantly.

The divide and conquer approach taken worked well for us. Splitting up the issues gave us more flexibility in how we would approach our particular task. For me personally, I was able to do my research and development at a faster pace as opposed to having multiple people working on the same file. On the other hand, our team meetings were extremely useful for getting feedback and help with development issues. Having more sets of eyes to look at a problem often times got issues resolved quickly. The team dynamic in programming and software development, in my experience, is usually a balance between avoiding a “too many cooks in the kitchen” situation and making sure the team is communicating and engaged with each other. I believe our team balanced this reasonably well.

That said, I believe we should work to improve our inter-team communication. Having a good sense of what other members are working on is important if we’re going to continue to divide issue assignments. This is something I should work on specifically too. I want to avoid the habit of staying head-down in my laptop working, and do a better job of communicating on the status of what I’m doing, especially when working on my own.

My main focus for development was writing the code to create a properly-titled .csv report file to be sent and downloaded onto the user machine when the API call is executed. Here are links and descriptions on specific things I accomplished this past sprint:

1. getReport API Endpoint – Developed and tested RestAPI endpoint to retrieve report file.
2. buildReport Function – JavaScript function to build the report itself from RabbitMQ data. Currently, this generates a blank .csv file with the proper title with relevant dates of the report.
3. JSDoc API Documentation – Began setup and use of JSDoc, a markup language for JavaScript to generate developer documentation.
4. JSDoc Deployment Shell Script – Shell script to aid in building documentation files.

From the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave H. Hoover and Adewale Oshineye, the section regarding protecting one’s passion for software craftsmanship stuck out to me. Getting tired or frustrated when writing code is more or less inevitable; being able to separate those feelings from the field as a whole is key. The book mentions the idea of “Drawing Your Own Map”, a strategy for mitigating burnout. The core idea is setting limits for yourself can be as important as setting your goals. One can define the boundaries in which they allow themselves to work within, as even with short-term consequences (the book mentions missed raises and unhappy coworkers as examples), walking The Long Road rewards pace and longevity, not speed. I firmly agree with the statement made by the authors; quality craftsmanship does not come from short, intense periods of work followed by burnout, but by maintaining a steady pace forward across a decades-long career.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Last week, my team completed our first Sprint of the semester and presented our work to our professor and the client. Overall, as a team, we did a great job for having not done or been a part of a Sprint before. Each one of us was assigned an issue at the start of the Sprint to work on over the period. One of these issues was evaluating the frontends, so I reviewed each of them and found that two of them, AddInventory and CheckInventory, did not run properly. It was determined that it was a server/deployment issue, so I contacted a member of that team through private messages. The team was aware of the issue and were working on it, so I suggested to my team that we focus on the backend for this Sprint. However, we decided that it would be better if we try to fix it ourselves instead of waiting. So I was given the CheckInventory frontend. In class, another member was able to get the AddInventory frontend to run, so I asked for their help outside of class, where we determined that the frontend was unfinished. So my task for the next couple of weeks was to fix that, and I did so by comparing it to the AddInventory and CheckoutGuest frontends. I then “borrowed” files that were missing from my frontend, and edited and fixed ones that did exist. This consisted of organizing some files into new folders, copying over frontend-prod-build and frontend-dev-up commands, index.html file, and much more. After I got it to run, I edited it so that it would match the AddInventory frontend. After all of that, I committed, pushed and made a merge request. The pipelined failed with that, due to a yarn lock issue, so I fixed that, linted, and then committed and pushed again. 

What worked really well was communication between the team. I felt that whenever someone had an issue or needed something done, someone answered within the day, which is really good. I think the team chemistry was also really good too, it did not feel too serious but also not too laid back. We also helped each other whenever we could, which is good. On the personal side, what worked well for me was just working in general. Like this whole thing is something that I have not experienced before, so just being part of a team to get work done for someone else kind of gave me fuel to work and make this a good thing. However, something that did not work well for me was the expectation to get enough done. For each week we plan for something to get done, but every time for me, I felt like I did too little or not enough. Maybe it is something in my head, or I am setting the bar too high, but that ghost pressure was not nice. 

There is not a lot that I would say we can improve on as a team, mainly because our communication is good, the atmosphere is great, we help each other and we get things done. What we could do, just as a minor thing, is clarify what we are working on. Although I do not think this is an issue, it has been expressed by members of the team, so this can be a good way of getting some bearings. As an individual, what I can improve on is just getting more done. Although I did finish my part of the Sprint by the end of it, it did not feel enough to me, so going forward I want to do more. To go with that, I would like to be more open about what I did do, some of my teammates were not aware of what I did in some of the past weeks, so I would like to improve on.

The Apprenticeship pattern I have chosen that resonates with me this Sprint is “Confront your Ignorance,”  which is basically not knowing the information needed for the work at hand. I chose this one because it describes what happened to me during this Sprint. I realized very quickly that I did not understand many things in the frontend and the Inventory system overall, which was scary and discouraged me. If I had read about this pattern before the Sprint, I do not think much would have changed. I still would need to do a lot of research regardless.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/60

This is my merge request for my finished task of implementing nodemon into InventoryBackend in order for developers to utilize hot-reloading and for the correct port to be added for the database.

For Sprint 1, what worked well for me as an individual was my experience with nodemon itself, and being able to incorporate that experience to get a head start on the issue. Although it took me longer than expected to complete the implementation, having some background knowledge allowed me to be more confident in the changes I was making. The familiarity of the subject gave me some peace-of-mind.  

As a team, what worked well for us was our communication skills and being supportive and helpful of each other during class time. We kept ourselves organized with our issues and our Issue Board, which allowed for a clearer understanding of the tasks at hand. Our in-class environment as a team was very open and transparent with our problems and what we’re working on. Our communication from within Discord improved over the course of the Sprint, and we were able to keep each other up to date whenever we ran into a problem, made a merge request, or needed a question answered. 

On an individual level, what didn’t work well was my silence at the beginning of the Sprint. I struggled with incorporating and fixing nodemon, but I wasn’t asking for help early enough. Once I did ask for help, I was able to make great progress thanks to the assistance of my teammates and Professor Wurst. As one of my teammates had noted, if I had asked for help sooner, I might have been able to finish my issue faster. 

On a team level, we did lack in communication here and there, such as a lack of response on Discord, or others not being included or involved as much as they could have been. The Issue Board was too vague from the beginning, which made it hard to choose our issues and perhaps led us to bite off more than we could chew.

To improve as a team, we should be narrowing down our Issues and specify them more clearly, so that our Issue Board and plan for the next Sprint is more refined and achievable. I think we should also start to do stand-ups at the beginning of each meeting to inform the team of what we’ve been working on and the status of our progress. Also, although this applies to mostly me, I think asking for help whenever we’re stuck would be a great improvement. 

To improve as an individual, I, as previously mentioned, should speak up when I am struggling to try and get assistance from my teammates. It’s always good to have alternate perspectives and fresh viewpoints, so someone else may see a problem or solution that I wasn’t seeing. I could do a better job at keeping up with my teammates’ work, as I sometimes don’t confidently, fully know what they’re currently working on. 

Although there are a few Apprenticeship Patterns that would apply to me, I’ve chosen to discuss “Retreat into Competence”. This pattern describes a situation where you are beginning to realize how much you don’t understand about the work you’re doing, what you’re expected to do, or even the work going on around you. It eventually becomes too overwhelming, and to fix it, you revisit your “comfort zone”; you involve yourself in your area of expertise to gain confidence back and to take a quick break. 

I selected this pattern because I often feel weighed-down by an overwhelming sense of ignorance from all of the languages, frameworks, and other factors of programming that I do not understand. It makes me lose confidence in my ability to code, as it emphasizes my weaknesses. In terms of this Sprint, although I chose an issue that I had a little bit of experience with, the roadblocks I hit made me realize how much I didn’t fully understand about nodemon and especially docker-compose files, connecting to databases, images, and the like. Finding my ignorance in these areas reduced my confidence in my ability to program and get this issue solved. 

If I had read the pattern before or during the Sprint, I would have stepped back, worked on something utilizing my strengths, and gained my confidence back. It’s good to remind yourself of what you’re capable of.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

What worked well this sprint was our division of roles and tasks as well as the planning for tasks and the sprint as a whole. Each member had a specific section of our project that we worked on, some even taking part  in more or most of the project, as well as connecting the pieces of the project. I think we spent a lot of time planning and working out what we need to do, the path we want to take, and the many decisions along the way. This hopefully led to less confusion while working through the sprint. 

What didn’t work so well this sprint was the communication. Communication during certain moments in the sprint was lackluster and thus other members didn’t know what certain members were up to or working on. This also led to those other members having to pick up work had the certain member not done their work within a specific time.

To improve as a team, I think we should communicate more. Specifically, what we’re working on, what we can and can’t do, if we need help, and to complete tasks that require more than one member. As we move towards a complete product, I think the work may become more complicated and the communication will be necessary to connect and join respective pieces of the project.

To improve as an individual, I need to communicate more and stay on top of my work. Putting in more effort to communicate with my teammates and completing my tasks should be my number one priority. Personal issues, lack of effort, or lack of understanding led to me not being able to complete my tasks. Not only is that quite the issue, but I didn’t communicate any of that to my team at all, and thus they have no idea what I’m up to and have to pick up the work that I didn’t do. 

The apprenticeship pattern I felt was most relevant to my experiences was “Expose Your Ignorance” from Chapter 2. This pattern states that there are people depending on you to know what you are doing and need confidence that you can deliver. The solution to this pattern says to “Show the people who are depending on you that the learning process is part of delivering software [… and that the …] most obvious way to expose your ignorance is to ask questions.” I felt that this pattern partly describes what I experienced during this sprint. There are people relying on me to do my part but I don’t have the confidence in my ability and am unfamiliar with a lot of the processes that we will work through. My teammates, on the other hand, are very familiar with the processes or are very willing to learn. 

Although I did expose my ignorance and ask questions of some of my teammates who were much more experienced than I am, I could have done so much earlier. Not only that, but I still feel hesitant to ask questions because there are plenty of things I should already know but don’t. Reading this pattern may have encouraged me to ask questions more often and much earlier in the sprint, increasing communication from myself and between teammates, and would hopefully lead to me knowing what I need to know to tackle my tasks.

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

The first sprint was a productive as well as eye-opening experience. This is the first sprint and set of work that we completed as a team during this capstone. The first sprint was able to teach us how to effectively and efficiently spread out the work, ask questions between each other for collaboration as well as knowing when to go to outside sources such as other teams or the professor. In our first sprint, the work revolved mainly around creating a new field for the guest object that would be able to store the value of the date of first entry. This one task was able to be split up into different working portions. These included adding this field to the API, the back end and the front end. Besides the main task we also completed the tasks of mounting a volume to the docker container allowing data to persist even after rebuilding as well as working on a CORS issue prohibiting the back end from communicating with the front end.

This is where things started with working well. Sean was working on the back end while Hiercine was working on the API, since they shared the same subsystem they were able to collaborate to solve the problem together. This was also scene with Lynn working on the front end and Winston fixing the CORS issue they both had experience with the front end so they were also able to collaborate. This is one of our biggest strength is our team working abilities and being able to collaborate to make the work flow more effectively and efficiently. Next, are the things that didn’t work well. I believe that everything we did was to the best of our abilities. The only things that could be commented on as not working well is our lack of knowledge in certain areas. For example, not knowing exactly how certain systems worked within the code since it was our first experience with it. In addition, when it came to linting issues, one linter was for commit messages which we recently learned how to make proper messages so we had to learn how to make them after causing the linter to fail.

I believe as a team we are in a very good spot that cam only go up. I think as a team we can work at continuing to learn more about the systems and tools being used. In addition, I believe when it comes to merge requests we can be more efficient in making sure all work gets merged in a timely manner and we all collaboratively spread out the merging work. As a individual, I believe I can improve on learning more about the code so I understand more what is happening so I can make better solutions for the issues at hand. I also believe I can work more at improving how I collaborate within the team.

The pattern I selected was “Rubbing Elbows”, I chose this because I felt it related very well to how we worked as a team. Even though we all had our own assigned issues, we were able to find commonalities between them allowing us to work together to increase efficiency and find solutions that we would not be able to find on our own. The “Rubbing Elbows” pattern is knowing when to seek collaboration and being able to learn from those you are working with. I don’t think reading this prior to the sprint would change anything since we already were collaborating.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/139
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/107

https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/-/epics/56

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Retro

This first sprint was a deep dive into new territory. Our team focused on understanding our project, setting up the proper tools and environment, and managing challenges as they arose. We have created a working agreement, completed multiple issues on GitLab as individuals and as a team, and we have ensured collaboration was a priority throughout each task.

GitLab Activity:

• README.md – Updated the README document for our GitLab group to detail the major goals of our project.
• Docker Compose Watch Documentation – Drafted documentation for Docker Compose Watch for possible use for CI/CD later on

Our team dynamic has been great from the beginning with a strong working agreement in place from day one being we were able to focus on the work getting done without worrying about team cohesion. We were able to complete a lot of research during this sprint to gather information about Docker and its many variants, NGINX, and CI/CD options. This research was turned into details documentation within our GitLab group. We worked successfully toward solving problems like issues with debugging Docker Containers, using SSL certificates properly, and scheduling our tasks based on priority. Overall, flexibility in our team has been vital and we have adapted to any challenges that we have faced.

I believe we have already learned a lot through our research and time spent of digging around in the server for answers, but we can still work toward improving our outcome by approaching our research differently and ensuring we have a clear focus on what we want to accomplish. Personally, I plan to improve my work by improving my time management regarding troubleshooting/research because sometimes I can find myself down a rabbit hole and working to ensure that all of my teammates and I are on the same page through clear communications.

Apprenticeship Pattern: Retreat into Confidence

“Retreat into Competence” is a strategy for regaining confidence when feeling overwhelmed by complex challenges. It involves stepping back into an area of expertise before pushing forward again. The key is to avoid staying in the comfort zone for too long and instead use the retreat as a way to launch forward with renewed energy. During this sprint, there were moments of troubleshooting that felt a bit discouraging, particularly with Docker and SSL certificates, where progress seemed a little slow and confusing. The feeling of being stuck highlighted the need to step back into something familiar—whether it was revisiting basic Docker configurations or focusing on smaller, more manageable tasks like completing documentation on GitLab—before tackling the larger issues again. Had I known about this pattern sooner, I would have structured my work differently to maximize results. Moving forward, I plan to:

• Time box troubleshooting sessions to avoid going down the rabbit hole
• Focus in my research to ensure that the resulting information is useful to our project
• Seek help from teammates during moments of need
• Ensure that I am still completing the smaller tasks that can be completed while working on larger issues

This sprint was a valuable learning experience in both technical and team collaboration aspects. While challenges arose, the team adapted, and I gained insight into how to manage difficult situations more effectively. By refining research strategies, improving troubleshooting workflows, and applying patterns like “Retreat into Competence,” I can optimize future sprints for even greater success.

From the blog cameronbaron.wordpress.com by cameronbaron and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/blob/WEB-APP-FRONTEND/src/frontend/src/components/UPCScanner.vue?ref_type=heads

This is a link to the UPC scanner component that I recently implemented.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/blob/WEB-APP-FRONTEND/src/frontend/src/layouts/MainLayout.vue?ref_type=heads

This is a link to the Main Layout for the Web App, this is essentially the homepage.

Reflection on What Worked Well

One of the biggest strengths of our team has been our ability to delegate and handle specific tasks effectively. Each team member has taken ownership of different aspects of the project, whether it’s the frontend, backend, or database. This clear division of work has helped ensure that progress is made across all areas of the application. Since I am working on the frontend, I have been able to focus on designing and implementing the UI while relying on my teammates to manage the backend and database.

Reflection on What Didn’t Work Well

Despite our strong ability to divide tasks, one area that has posed challenges is communication. There have been instances where misunderstandings or lack of updates led to delays in task completion. Additionally, not all tasks have been finished in a timely manner, which has put extra pressure on certain aspects of the project. This lack of synchronization has occasionally resulted in blockers, where one team member is waiting on another’s progress to move forward.

Changes to Improve as a Team

To enhance team efficiency, we need to establish better communication channels. This could include:

• Holding short daily stand-up meetings to discuss progress and blockers.
• Setting more reasonable due dates that account for individual workloads and unexpected obstacles. By implementing these changes, we can reduce miscommunication and ensure that tasks are completed within a reasonable timeframe.

Changes to Improve as an Individual

On a personal level, I recognize that I can make improvements by:

• Checking in with my teammates more frequently to see if they need help with their tasks.
• Setting personal deadlines to ensure I complete my work on time.
• Being more open to suggestions and feedback from my team, as collaboration often leads to better solutions. By making these adjustments, I can contribute more effectively to the team and help ensure the overall success of our project.

Apprenticeship Pattern: “Be the Worst”

Summary: This pattern emphasizes surrounding yourself with more skilled individuals so that you can learn and improve at a faster rate. By putting yourself in challenging situations where you are not the most knowledgeable person in the room, you can grow and develop your skills through observation and experience.

Why I Chose This Pattern: During this sprint, I have noticed that I can learn a lot from my teammates, especially in areas I am less experienced in, such as backend development and database management. Rather than just focusing on my own tasks, I want to take the opportunity to learn from their expertise and improve my overall skill set.

How This Pattern Would Have Helped: If I had adopted this mindset earlier in the sprint, I would have been more proactive in asking questions and seeking guidance from my teammates. This could have helped me avoid certain mistakes and speed up my development process. Moving forward, I will embrace this approach to accelerate my learning and become a more well-rounded developer.

From the blog CS@Worcester – Software Dev Capstone by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Throughout the first sprint there were many learning experiences earned, and a great amount of progress was completed for our server. For a first sprint together as a team, I would say we did very well overall; and the second sprint will only be better. What we did best overall in the first sprint, was completing our manageable goals. In our initial sprint planning, I felt that we set attainable and workable goals. These goals were met by all members of the team in some capacity, demonstrating an equal workload across the team. We were very transparent in our communication, and our communication was frequent and on-topic. It felt that we were very efficient in coming to decisions and working towards a greater goal. I spent my time doing three major tasks; setting up and testing Thea’s Pantry on the server, researching Docker volumes and coordinating with Gio of team 2, and troubleshooting SSL certificates to allow the back-end and front-end to connect without an HTTPS error. 

What didn’t work well in the sprint was our lack of knowledge going into it. Our team in particular is charting entirely new ground, which requires us to learn a good deal before moving anywhere with our project. We also ran into a major issue quite early (SSL error above), which sidelined any progress with Thea’s Pantry on the server. We were able to overcome most of our obstacles, and prepare for an even better sprint two, but there was a rough start with the freshness of the material and our inexperience running sprints. 

As a team we could better work independently, as that is our main drawback. We had very little issues communicating, planning, or working; but most work was done as a group and we pooled our brains into individual issues. This slowed us down, and although we reached many of our goals, had we worked more independently we may have gotten through more. This is something we can improve for sprint two, and be more efficient with. As an individual I could better deal with frustrating issues. I got quickly discouraged by major issues that I could not solve, most notably with our SSL errors. My inability to switch tasks held me back from one of my sprint goals, because I was determined to solve an issue that I did not have all the tools to solve. I could also better document my work, as going into this retrospective I realize that outside of completed issues there is very little documentation of what I had done. 

The apprenticeship pattern that best describes my work in this sprint is Confront Your Ignorance. This fit because the work done with the staging and deployment server is something entirely foreign to me. To be able to approach the work, I had to swallow my pride and confront that I know nothing about the topic. And to improve that I did research throughout the sprint to better understand how to make progress. Reading this pattern allowed me to reconceptualize my lack of knowledge into an opportunity.

My tasks:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/6
This was my first task in the sprint. I installed docker and docker-compose on the server, and got Thea’s Pantry running on our server. I have since tweaked our compose file and have been working on getting the back-end and front-end to connect on the server.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/16
Most of my sprint was spent tackling the issue of SSL certifications for our server. I made progress in getting a self-signed certificate to bind to the IP, but I could not access the index file to allow the front-end to work with the volumes used for the nginx config and certs.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/4
Here I made a minor contribution in establishing how we should go about implementing CI/CD, I researched how we could make it work and presented it in class. In the future I plan to implement a Python script to aid Andrew in this task.

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.