Christian Shadis

This past week, my development team in my Software Development capstone completed our third and final Scrum sprint for the Spring 2022 semester. We completed our final Sprint Review on April 28^th and have officially stopped working on the project. This was my first experience working in an Agile environment, along with my first time working on a Humanitarian Free & Open-Source Software Project.  

There were several areas in which our team excelled. The team did an excellent job of labor division, as through the entire semester, all team members were contributing equally to the advancement of the project. We also worked well together as a group; we were able to concurrently work on code very effectively, combining the knowledge of everyone to solve problems we couldn’t as individuals. Throughout the semester, we improved our workflow, increased efficiency of standup meetings, and improved the organization of our source control and merge processes.

There were some areas to improve for our team. We struggled to create appropriate issues in Gitlab to work on – we often found that we were creating issues that were too vague, too large, or duplicates of another issue. We also could have done a better job of maintaining the Epics board in Gitlab; we focused primarily on the issues and not on the Epics they were attached to.

As an individual, I worked well throughout the semester. I was the Scrum master for my team, a position I had never held and was not confident in. I challenged myself to help the team stay organized and balanced in our Scrum meetings and saw improvement throughout the semester. During the first sprint, we would often get sidetracked during standup meetings talking about problems team members were running into and were using more time than necessary. I was able to help the team keep our focus on the current meeting and save other discussions for after, increasing the efficiency of our utilization of class time.

I believe the semester went well both for the team and for my individual work, but there are areas in which I can improve. First, I found myself feeling disorganized occasionally throughout the semester from making too many changes at once – I would like to get better at treating issues as small, independent tasks that are fixed alone on a branch and then merged, instead of completing several small changes in the same issue and branch. This will make it easier to stay organized with what I am working on and will make the source control system more effective at tracking the work I did on each issue.

I contributed to the project in several ways in the final sprint. The major hurdle we faced was getting the backend and API to connect so HTTP calls can be made to the API. I spent the majority of my time trying to debug the various errors we were running into, such as connection errors and socket hangups https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40 . This issue is a great example of our misuse of issues – while only one issue was listed, it consisted of many hours of work and many changes to files —  Javascript files, the bash scripts responsible for starting the server, and the API itself. While I was ultimately unsuccessful in completing my fix, I was able to gain a more complete understanding of the project and how each file and component fits into the larger picture of the system.

I would consider the sprint and the semester successful overall. Essentially, we have a working and validated API, most backend code, and have linked the two together. The next steps for next semester’s group will be to continue to develop testing, along with incorporating Identity and Access Management and deploy the server on Amazon Web Services. I feel much more comfortable working in an Agile environment and working on smaller pieces of large HFOSS codebases, and I feel far more capable of working as a developer professionally in the coming year.

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

As the third and final sprint for the semester, and with that my involvement with the N.I.C.E project, has come to an end, it is time to reflect on the progress that has been made, as well as what has changed with respect to team and personal work compared to the previous two sprints. The difference between this and the previous two sprints is that this sprint was the proper beginning of actual implementation of the features that we had been brainstorming as a team over the previous two sprints. With this being the case, we were no longer at the stage where we struggled to find some footing regarding the project’s infrastructure; we had actually begun laying the foundation that this project will be based on. In simpler terms, this is the sprint where we were no longer working on spike solutions, but actual source code. This meant that we were overall working with a more hands on approach to this project.

Though admittedly not perfect, this sprint proved to be the most productive sprint both in terms of actual productivity, given how we had to work over 42 issues, and well as individual and team growth. During this sprint we as a team had a much clearer direction in what we thought needed to be implemented, as well as how we would approach said implementation. This meant that members of both the Docker and the Source Code groups were more independent, which helped make some very good progress. That is not to say that all team members were working in complete isolation – on the contrary, there was by far more communication taking place across both Gitlab and Discord between team members during this sprint. This was especially prevalent in the Source Code team, which I was part of, as I made time to meet independently with my fellow team members to discuss or collaborate on certain issues. In my case, I was assigned to work on the following issues:

1) Implement file parsing to implement a question into a card component
2) Implement a method to make multiple copies of the single question preview component
3) Implement the component that contains a single question preview
4) Build a page that shows previews of the questions for the interview
5) Fix the visuals for the card components on the question previews

Sadly, we did not manage to implement certain issues exactly as we had envisioned them either due to bugs occurring or due to lack of time, though we still managed to make some satisfactory progress despite it all. Moreover, unlike the second sprint, there has also been improvement with respect to time management during meetings, something that we had reflected on and had problems with in earlier sprints. Though there were still cases were the conversation would veer off topic, we as a team were more conscious and thus put more effort into returning to our topic of discussion. This was also affected by our documentation; given that we begun to put more effort into documenting the development process into the appropriate issues on Gitlab, it has been easier for team members to be on the loop and communicate any misunderstandings outside of meetings. Moreover, I feel like my own working process has improved as a result, especially my weakness in properly gauging an issue’s proper weight. During this sprint, I feel like I have improved in taking the proper care to dissect and break down a goal into smaller goals so that implementing a feature is easier in terms of what steps need to be taken towards implementation, as well as seeing how my issue could be connected to another team member’s issue. Thus, instead of panicking to implement a vague issue, I noticed that I made better progress by implementing smaller and clearer issues.

As I mentioned, this sprint was by far the most productive sprint for the course. Though there may have been some occasional flaws or problems in productivity, these flaws were not as significant when compared to the second sprint. Overall, as a team we have noticed that we had finally gotten on a steady and clear path.

Direct links to issues:
1) Implement file parsing to implement a question into a card component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/42
2) Implement a method to make multiple copies of the single question preview component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/41
3) Implement the component that contains a single question preview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/39
4) Build a page that shows previews of the questions for the interview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/28
5) Fix the visuals for the card components on the question previews: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/48

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

This last sprint I feel as though I went backwards. I am not too happy with my results. I spent the majority of my time working on semantic-release for the backend, frontend, and api branches, which I was only able to partially complete. Reflecting on this sprint, I should have absolutely given up and started work on something else. If I had given up someone else might have tried, and one of my team members might have had a different way of approaching the problem and solved it. If I were to look at this optimistically, its good that I messed up in class rather than in a real job. I was also able to write my findings in the issues I was working on so that the next student to take up the issue won’t be starting from scratch.

When working on the backend and api branches I was getting errors that did not make sense to me. I believe that there is something wrong with the repositories since that should be the only difference between the backend and api. I communicated this in my issue descriptions.

If I had to say something good about myself I really do like my issue descriptions. I am not sure if it will be helpful for the next students, but I really hope it is. I even tried to suggest possible solutions I was thinking of. I knew that I had to try hard to write good documentation because when we inherited this project from the previous group, there was little documentation for us to go off.

Something I think my team could have done better is to check in with each other more often. Sometimes I did not know what my teammates were working on, which is something you never want when working in agile production development. We slacked off on our daily standup meetings; if we didn’t I could have communicated my struggle with semantic-release. We could have made more of an effort to perform out standup meetings correctly, and I know that would have definitely helped me, and probably others as well.

Something that I could have done better relates to communication as well; I could have asked for help. I am not sure why, but throughout my struggles with semantic-release I did not ask my group for help at all. I did ask other people, but if I had gone to my group they would have known about my problem, been thinking about solutions, and they would care about fixing it since it directly relates to them. For whatever reason I kept believing that I could solve it myself since I got it working on the frontend, but now I realize this was a mistake.

I am not going to lie to myself; I did worse this sprint compared to sprint two. I think it is important to look at your own work objectively and critically in order to improve. Like I said before, I am grateful for this learning experience while still in college. I know that an employer will expect me to make mistakes, but I am not the kind of person to be satisfied producing sub-par products. I will do my best to learn from this experience and try to not repeat the same mistakes in the future.

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

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.

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.

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.

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.

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.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/58

The card I created for adding rabbitmq to docker compose

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/8

The card I created for adding message sending to the backend

This sprint not much worked well for me, mostly because of outside forces unrelated to the class. I simply was not able to put as much time and effort in as I wanted to. Most of the sprint was spent working on figuring out the messaging system. I was able to send and receive messages locally. What I was not able to do was send messages to other computers. I am pretty sure if I kept working on it I would have gotten it eventually; I found many solutions online that I did not get to try yet. 

That does not mean everything went poorly though. Something that did work well was transitioning between the two teams. This sprint I worked more with the event system so I had to meet with Derin and Rainiery more often. It was really easy to get the team together because discord is made to do that. If we were using zoom for class meetings it would have been a lot more difficult. 

I think my team did well this sprint. Marcos and Tim were able to do a lot of work on the front end and while it did not get where we wanted it to be we still got far. This sprint I think David was able to do a lot really fast and because of that he was able to start working on the integration portions. Cam was a lot like me in that he did a lot of work outside of our system with the IAM team. 

Even though this was our last sprint, there are a lot of things I can do to improve. The improvements may not be for the next sprint (there isn’t one), but they will be things for me to carry into my career. Time management is a huge thing I need to work on. Expecting to be able to do a ton of things all in one day just does not make sense. This sprint and this class really taught me that I can only be productive for a few hours at a time. Anything after that is probably wasted. It’s better to let a bunch of short work sessions add up. I also need to make sure I do a little bit every day. It is more efficient and I forget less if I minimize time in between work sessions. 

As a team, if we were to work together again I would want us to communicate more. I think David and Tim both were looking for more work to do during the sprint. I should have asked them for help with rabbitmq. We could have sent mock messages to each other and probably would have figured out the messaging system a lot faster. When I got stuck I also could have taken a step back and helped out with some other parts of the system, maybe doing something like helping test out the front end. That would have helped me clear my mind but it also would have helped make sure the front end worked for when we demoed it.  

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.