Third Sprint Retrospective

Reflection on what worked well and didn’t work well

After meeting for the Sprint Retrospective with my team as a whole, I can say that the project is progressing well. The flow of group work has improved more since everyone works together much more effectively. The front-end and back-end development teams have made significant progress towards the project. The backend is pretty much complete at this point and the frontend is pretty much there besides a few minor things. We don’t have any major programming problems coming off of our last sprint, just a few potential bug fixes and cleaning up to do. Finally, after looking back at what we did, we made it easier to run the servers, since in the last spring we had to run things one at a time, however now it will run all at once, making it more efficient. During this spring we also cleaned up a lot of the coding and did some minor bug fixes. The backend is pretty much completed now besides testing. We just didn’t have enough time for it, it would have been something we would have done if we had another sprint left in the semester.

Reflection on what changes could be made to improve as a team

The team worked great. We still have everyone on their original development team. The ones at the back end remain at the back end and those who worked on the frontend stayed on the frontend team. Both teams for this spring, started to run out of things to do since everything was either completed or almost completed at this point, or there wouldn’t be enough time to work on a new issue. From the way the meeting went, everyone was able to communicate all the problems they had with each other, and no one was afraid to ask if they needed help. For our last sprint, I would say that there was such an improvement comparing to the beginning of the semester. Everyone was comfortable with talking out loud, helping one another, and overall, just great teamwork.

Reflection on what changes could be made to improve as an individual

From my point of view, the sprint was very good. Since we were running out of things to work on the backend, there wasn’t much to do. I worked on changing the port numbers for the backend to be between 10350 to 10399. Help change the datatype for household members. As well as combining docker-compose for the backend. I worked with colleagues Jared and Vien on these issues and other issues that we had on the backend since there wasn’t much left to do for the backend. Same as the Sprint, we were able to continue to learn more from each other. In this final sprint, I would like to say that overall, I became a better programmer/ developer, and this was a great experience to be able to work on large project in a scrum environment. I was able to become more confident in my skills and also became better with communicating with team members.

Combine docker-compose Backend
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/34

Update Household Members Datatype
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/api/-/issues/12

Update Backend Ports
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/36

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

Sprint 3 Retrospective

With the conclusion of our last sprint, I’ll start by reflecting on the team performance. I think we went into this sprint pretty determined to get the backend fully up and running. Those of us who were involved in the backend development started working on trying to get the backend running in order to test each of the endpoints. Though the container was running, we were unable to use http calls to test any of the endpoints. We realized that there was a bigger issue than what we initially thought, resulting in us spending most of the sprint trying to get the backend server running. Another thing I would like to point out was that we had issues that were a bit too ambitious. We structured our sprint around the idea that we were going to have the backend running fairly quickly. And because of this we were essentially unable to do a good amount of issues because they required the backend to be running.

Reflecting back on my performance, I would say that I communicated well with the team at the start of the sprint. I discussed with my team during the sprint planning, helping the team structure what needed to be done for the upcoming sprint. At the beginning of the sprint, I assigned myself issue #31 in the backend, which was to test the removeInventory endpoint. I spent time trying to test with http calls but I was not getting any response. I then learned that we were having issues getting the backend to run, which explains why I was not getting a response. I think when it came to this point, I started becoming unproductive due to the fact that my assigned issue depended on the backend running. 

As a team, we definitely could have improved in the communication aspect. At some points during the sprint it was a bit unclear as to what everyone was working on. Most of our progress came to a halt by the issues with the backend, and I think we should’ve put all hands on deck to look into the issues. I do also think we could’ve come up with more manageable issues. For example, a task such as implementing keycloak into the inventory system is something that we can’t gauge the weight of until we actually start working on it. We could’ve come up with issues to get the backend running as opposed to things to do after the backend is running.

Coming away from this sprint, I will need to remember to communicate with my team, engaging with them to see if they need help with anything. I think I should’ve spent more time looking at the entire structure of the project to get a better understanding of how it should work, that way I can look into issues as to why things aren’t running. I will also need to consider setting realistic goals and understanding what things can be done in certain time frames. I still learned a lot from these past three springs and I look forward to applying this knowledge to my professional career.

issue #31: Troubleshooting the removeInventory.js endpoint which was unsuccessful due to the backend not running as intended.
issue #3: Bundle items-api.0.1.0.yaml to be used in the backend.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

The course of our sprint was good, we completed large sections on the frontend and backend from the last sprint to get the necessary functionality to integrate the front end and backend together. We achieved our sprint goals by all agreeing on what was most important to focus on in the sprint, which helped us on completing our ultimate sprint objective. We structured our issues in such a way that they were less dependent on each other for completion. This strategy maximized the number of issues that could be completed without having to wait for someone to submit their issue first.

Keeping in mind the lessons from our previous sprints, we continued to work in small branches dedicated to one issue at a time. There was minimal code divergence because of our fast branch, merge, branch strategy. It was tempting to keep developing in the same branch, but with the small size of our project, the structure of our project changed very quickly. Merging large branches together often resulted in breaking code in the past. By our third sprint, we had developed a great workflow and collaborated seamlessly. Two large braking changes we made this sprint were updating the port numbers for the backend and frontend as well as updating the fields within the guest info record.

With our workflow and communication, our team updated internal ports, mapped them to docker images, and reflected the changes in docker-compose files for code in multiple repositions. All while maintaining integration of the frontend and backend code. We also had to remove and add new fields for the guest record. This required modifying the OpenAPI Schema, handling the changes in the backend, and modifying the form on the frontend. By doing small branches in coordination with our team members, these major changes were made without issue. If this was our first sprint, things would have been more difficult. I see the ease at which we made these major updates as evidence of how much we have developed over the semester.

Overall, there were no significant indefinable changes we should make as a team. As always, we should aim to communicate with each other to the best of our ability. In my opinion, we did this well and left little room for a need to improve. Although our in-team communication was excellent, one area that still needs improvement is our communication between teams. We improved on this compared to the last sprint by working with other teams using the credit card scanner, sharing CSS styling, and meeting with the Kubernetes team to discuss integration. However, we wanted to implement keycloak this sprint, but we did not accomplish that task. The reason for this was both due to running out of time and failing to have enough dialogue with the IAM team to learn how their system would integrate with our system. If we had the fourth sprint, I am sure we would be able to learn from our experience and succeed at implementing these features in the future.

Overall, I improved significantly between sprint one and sprint three. I could still improve the amount of communication I have from team to team and take it upon myself to reach out more. I did do this during sprint three more than I had in the previous sprints, but improvement could be made in the number of times I reached out.

Issues Completed During Sprint 3

∙ Create a second connector class for sending data to RabbitMQ to make changing RabbitMQ for another message broker-client simple without updating its use through the code. [https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/35]

∙ Fix the issue where adding a new guest via API request on the backend throws server error and does not add new gues to the database or RabbitMQ [https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/38]

∙ Create an environmental variable for delaying the start of the NodeJS server to wait for the RabbitMQ instance to be ready for connection [https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/40]

∙ Remove and add new fields for the guest record within the OpenAPI for the GuestInfoSystem as well as modify the backend to handle these changes [https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/api/-/issues/12]

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

Sprint 3 Retrospective

To start with, our communication got a lot better about when we were done working on things, and about what needed to be done before the rest of us could work on new issues. Our prioritization also improved greatly, with us figuring out what was most vital in order to get our project as far along as we could in the last sprint. Our issues were also a lot clear in terms of what needed to be done, and we were relatively efficient in assigning and working on them as needed. I also felt that personally, I was extremely productive during this sprint, more so than I had been in the others, and this was the first sprint I felt that I had an extremely clear goal and something that was important and useful that I was working on.

That being said, I felt like other parts of team communication were lacking somewhat. We still struggled with knowing what everyone else was working on, and there were a lot of cases where it seemed like some people were finished and waiting on others, or were just unsure of what to do next. I felt like the backend not being fully functional still was a huge holdup to the rest of our work, but there were still some small things that could’ve been done without it. I think that having a clear end date on when we would be able to work on the project left us with less motivation to get some things done, as they would likely have to be redone by future teams, so I just think that our overall planning was a little bit lacking for the amount of work we had to do in some places, as evidenced by our remaining issues in the sprint backlog.

As a team, I think that we should have improved our communication a bit more, and more time spent looking at what actually needed to be done in the code could’ve helped us break up the work a little bit more. But I also think that this largely comes from our lack of clear direction and prioritization in the prior sprints. I think that greater clarity and communication about what we did, what we were working on, and what we needed done could’ve helped avoid a lot of the issues we ran into this sprint, and I think that overall having a clearer picture of the overarching architecture required for all of this could’ve helped us a lot. If we had spent more time getting to know exactly what we had done and what we needed to do could’ve helped us significantly improve our performance in this case.

As an individual, I think that I should’ve been more open about what I was doing with my team, and this sprint has given me an example of how I need to, in the future, pay more attention to the vital parts of the project, so we can get those working before we start working on the meat of it all. I should have been more meticulous previously, and less short-sighted when creating issues. Spending more time looking through the code and what we needed could’ve helped greatly here, I feel.

Issue #36: This started off as just adding bin files to start and build the backend server, but became reconfiguring and rewriting all the server files to get the backend server and API functioning.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Breakable Toys

This week’s Craftsmanship Pattern is another important one, breakable toys. This stands for the idea that experience is built upon failure just as much, if not more, than success. This idea is very good, as no one wants to fail, but failing is one of the best ways to learn, as if you are always successful, it is much more difficult to learn what does not work and what to avoid. The idea of never failing means you will never take any risks. To quote one of my favorite memes, “You didn’t grow. You didn’t improve. You took a shortcut and gained nothing. You experienced a hollow victory. Nothing was risked and nothing was gained.” While the above is pointed at cheating in a very difficult video game instead of “Gitting Gud” (intentional spelling) to pass a difficult task, I feel like the same idea applies here as well. It is important to learn what to do to succeed from what does not work, and what does work to continue using it.

To help with this growing, and similar to last weeks, it can be good to set up a private space where you can seek out this failure to learn from the experiences. For projects that you can fail on, try to build you own minor application, maybe a calendar or address book, for example. Things that are not too big, but still good enough to allow for failure without negatively impacting you. One highly recommended thing to do in the book is to create your own personal wiki, as you can use it to record what you learn. They are also nice since they can be simple, but still allows you to learn about things like HTTPS, REST, parsing, web design, etc. Sticking with this long enough will teach you about many things you many not have been exposed to otherwise, again creating an overall positive experience, because you will have some failure along the way, but how you overcame the failure is important. The book shows an email that Linus Torvalds saying that he is making a free OS based loosely off of minix, and those who know know where he went with this, and that is where we got Linux.

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

Apprenticeship Pattern: Expand Your Bandwidth

Christian Shadis

In the apprenticeship pattern Expand Your Bandwidth, Hoover and Oshineye explore the importance of learning as much new information as possible as a new developer. They talk about how many developers have relatively low understanding of programming concepts when they enter the workforce, and how these new programmers can take advantage of the wealth of knowledge available for consumption. They make the analogy of drinking out of a straw versus out of a firehose – increase the volume of information you consume as much as possible.

This pattern particularly resonated with me. I feel as though I have a very solid low-level understanding of several different concepts in the world of software development and data analytics. I lack that high-level expertise in all the subjects I have studied in the past three years. I have attempted to emulate this pattern before learning about it: I have a shelf stuffed with books about everything from CS basics to networking to Machine Learning, and I do my best to read as much as possible about the subject.

As mentioned in my previous post, I entered the Computer Science world far later than I would have preferred and faced the difficulty of entering a vast industry filled with passionate, lifelong learners as a programmer with absolutely no knowledge of anything related to computer science. I believe I have spent my time wisely, learning lots of information about several different subjects, and managed to build up a solid toolkit before graduating.

I hope to use this pattern throughout my career, but especially so over this coming summer. I will be seeking employment as a software developer or engineer, and I feel as though some gaps in my knowledge should be plugged up as soon as possible. I plan to do a deep dive on full-stack development and connecting the frontend and backend of a system and use my newfound knowledge to do a complete rebuild of my website (ctshadis.github.io) with a proper full stack and domain name. I believe this will require learning lots of new information and applying it immediately in a way that will make me more qualified for any full-stack development jobs I apply for.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Share What You Learn

To avoid frustration, I try to keep myself motivated by thinking about the feeling when I complete my task. Along with the feeling of completion, sharing information among people is some sort of motivation that I want to show off every time I learn something useful.

In my view, I am not a beginner applying this method introduced in Dave Hoover’s book since I am not feeling strange when I explain to my mates what I have learnt, instead, I actually like doing it because it is not only a way to help my mates understand the part that I have been working on but also a great opportunity to test my understanding over subject and enhance my memorization onto it.

I started feeling the benefits of sharing information with other people since high school. Back then, I mostly helped my friends when they didn’t understand some math problems in class, and every time I do it, I remember that issue much longer, and I feel more comfortable with the technique used to solve that problem. The more I “teach” them, the better my “teaching” skill and my sense of learning improves as well. As they started counting on me in these difficult tasks, I would perceive the sense of motivation to push my learning into the higher level.

We are afraid of having a conversation about a topic that we do not really comprehend. In both math and code, exchanging information, in my opinion, is an infamous problem since I have encountered lots of people who suffer from it. Coding and mathematics have a similar concept (it is like a feeling, but I cannot think of a more specific word to describe it) that once you understand the flow, solving their problems is utterly attractive. Therefore, besides the benefit of improving my apprehension, I also want to help my friends be able to comfortably debate when it comes to specialized topics.

As we grow, we have less confidence to ask other people, searching for problems online is therefore becoming a more popular approach. Hence, publishing blog posts to share my learning will be my next path to maintain my motivation and improve my understanding. Stay tuned!!

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

Find Mentors

Many apprentices in this craft are inexperienced and have little knowledge of what’s next in store for them or how to prepare for what’s to come. Luckily, most apprentices, are not the first person to walk down the same path, and there are many people who are experienced and knowledgeable who could provide help and guidance when needed. This apprenticeship pattern is about finding these people and having them mentor you in your journey to becoming a master craftsman.

Mentors can be quite hard to find. It may be easy to locate authors of books on the craft, accomplished conference speakers, committers on popular open-source projects, and developers of successful websites. However, it is difficult to convince them to mentor you. They may not be interested, or they feel intimidated by the request. One should expect rejection as a risk. However, the risk of being rejected by a mentor is fairly low, while the payoff is massive. The key when searching for mentors is to be tenacious and appreciative.

One thing to keep in mind when searching for mentors is that it’s important to understand that mentors are also going through their own journeys towards becoming master craftsmen and that no one person knows everything. It’s tempting to want your mentor to be a master because of their vast and deep knowledge of the craft. However, such temptations should always be resisted. You shouldn’t dismiss mentors by over-focusing on their inevitable weaknesses or blind spots, these mentors still have a lot to offer.

Although this apprenticeship pattern discusses a simple concept, it is extremely important. Finding people to guide you in your journey is invaluable. Mentors can help you make the right decisions for you, they can teach you new techniques, they can give you tips about the craft, and they can give insight into what you can expect. Every apprentice should actively look for mentors and learn as much as they can from them. By the same token, it’s important to realize that just as you are looking for mentorship from people ahead of you, there are also people who are behind you who seek mentorship from you. Being able to pass on your knowledge and experience is one of the ways where an apprentice can begin to transition into a journeyman.

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

Sprint 3 – Retrospective

I thought that the team functioned well this sprint, despite not being able to complete our ultimate goal, which is to have the backend be fully functional. I think the team communicated much better during this sprint than in the past two sprints. I also think every team member tried to put in the effort to do their part and accomplish our tasks despite coming up short. I think we underestimated the sheer amount of time that it would take to finish the backend. We all thought that we were very close to getting to work and that we would have plenty of time to work on testing the endpoints and other files. However, that turned out not to be the case and we spent most of the sprint trying to get the backend to work.

Individually, I think that I performed well during this sprint. I tried to take an active role in the sprint planning portion of this sprint, and I tried to communicate with teammates more often than in previous sprints. I managed to this sprint to upload the RabbitMQ demonstration that I created and researched during the last sprint in the general repository. I spent time working with Julion to merge the updatedFunctionality branch to the Main branch in the CheckoutGuestFrontend repository. The updatedFunctionality branch had all the necessary src files, and by merging this branch to Main, the CheckoutGuestFrontend finally has functionality like the other two frontends in this project. I also spent some time looking at the backend near the end of the sprint trying to find solutions to the errors that we were facing.

I think that the team could have done some things better in this sprint. I think when we figured out that the backend was going to take a much longer time than expected to get it working, we should have redirected our focus for the sprint and had the entire teamwork on getting it to work. I think the team should have done an overhaul of our issues. Many of our issues were either too ambitious or required the backend to work in order to proceed (testing the endpoints for example). I think many of the tasks in our sprint backlog and product backlog could have been broken down into smaller, but simpler and more realistic tasks.

Personally, I think I have a lot of room for improvement after this sprint. I should have definitely spent more time looking at the backend and researching ways to solve the different errors that we kept getting. I also should have paid closer attention to the issues that we created during the sprint planning period and really evaluated how much time they would take. Over the course of this sprint as well as the past two sprints, I have learned that taking an active role in communicating and helping my teammates, being more involved in the planning process, and being realistic about what I can do during a sprint are all things that I will need to succeed in my professional career as a software developer.

Issues that I worked on:

Issue Community#69: Upload RabbitMQ demonstration to General

Issue CheckOutGuestFrontend#11: Merge the updatedFunctionality branch to the Main branch

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

Find Mentors

Programming alone can be difficult with unclear paths to take with lots of uncertainty about which approach will be the best. Without someone who can give you guidance, it makes it difficult to move forward alone. It is necessary to find a mentor who will be there to guide you in times of uncertainty. The mentor you find does not need to be someone who knows all, but someone who has more knowledge and experience than you in a particular programming area. Finding a mentor requires a lot of searching because they may be hard to find, especially finding someone who is willing to spend the time to help. However, when you find one, they will provide a world of experience.

I found it interesting the author himself found a mentor after a few years of already being a programmer. It shows that it is never too late to find someone who knows more than you and to ask for help. This practice relates back to a previous pattern about exposing your ignorance. You must be willing to do this in order to get the proper guidance.

This pattern focuses on the theme of approaching programming as a craft where you must start as an apprentice. This reminds me of my grandfather who was a carpenter. When he was young, he started small jobs without much knowledge. He learned from the other men on the job who were eager to teach him what they knew. Eventually, he learned as much as they did and in his later years went on to share his knowledge with those who were younger just learning their craft.

After reading this far into the book, I have reshaped the way I view the development landscape. I feel that it requires the perspective of apprenticeship and the need for finding others to help you develop your craft. I think it is possible that at the same time you are being mentored, you can also be mentoring someone else. There are no areas in this pattern where I disagree with the author. I find that his recommendations and personal experience are well thought out and are great advice.

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