In my CS-448 class, we are working with the Thea’s Pantry system. I was placed on the team that looks at the automated reporting system and we have just finished our first month long sprint. During this sprint one, the first issue I worked on was the Reporting Integration set up issue which was in the backlog from the last team that worked on it (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/27). Then, after finishing with that, I took the next available issue that we had planned for this sprint and fixed that as well (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/29). After testing and requesting a merge for both of my issues, there wasn’t anything else that we had planned for the current sprint and I didn’t want to start on another month long sprint issue, so instead I helped my other teammates troubleshoot, checked their work, and looked into things such as how the final report file is formatted, what information it has, and how we would go about creating a file like that within the code.

I think what worked the best for us was our original plan at the start of the month so that we all knew what we needed to do and could focus on that. For the most part with most problems being from the project backlog, we didn’t work collaboratively that much as the issues were largely separate but during meetings, we would be able to teach each other about the different systems we were working on. We also were able to get all of our issues done with a little time to spare at the end that we used to further develop some of the small things we would have needed to do eventually anyways. As far as what didn’t work well, when starting to help my other teammates, I felt behind in understanding on the system they have been learning for a few weeks and had to catch me up. Fortunately, with the extra time we had, I and others were able to follow along with other’s progress and quickly gained at least a basic understanding of all parts of the system.

During the next sprint, an improvement that I hope we make as a team is to work more collaboratively, even if the problems we are working on are not directly related to development. We didn’t have much of a chance to work on direct collaboration, but for the next sprint given the opportunity now, I hope that we can progress as a team more so that specialized individual programmers. For myself individually, something that I aim to improve on is my workflow. Last sprint I would try to implement code and get it in a semi working state but then would have to go back and reference other parts of the project or research some other system that was involved. In the future I plan to approach the problems first with getting a full understanding of how the system will work when fully operational and then writing the code, rather than going back and forth between coding and learning.

For this sprint, I feel that the apprenticeship pattern that was most applicable to me was Chapter 2’s pattern of emptying the cup. The book’s author talks about this in the context of learning a new language which is somewhat true for myself as I am not very experienced in all the intricacies of how javascript coding works when developing a website. I felt that this pattern described my experience because I had to learn a lot of new systems that I hadn’t used much before. This is my first time working with RabbitMQ or MongoDB and to a lesser extent the workflow of docker and gitlab. Over time, I got better at using these applications but I had to spend time learning them without “working on” the project.

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

Gitlab Deliverables:

• (Issue Board Maintenance): Throughout Sprint #1, I supervised the creation and progression of issues in addition to readjusting them based on our current scope. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/boards
• (CronJobs Research and Documentation): One of our goals of Sprint #1 was to research CI/CD, and CronJobs was a component of such.  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/CronJobs.md?ref_type=heads
• (Set-Up Documentation): After our group installed Docker-Compose and established a connection to Thea’s Pantry’s FrontEnd, I created documentation walking through the steps on how we achieved this. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/Set-Up.md?ref_type=heads

Sprint #1 was a rocky path, but through our group’s collective efforts, we all learned new tools and skills we can implement in future sprints. At the beginning of this sprint, our group agreed that I would be the Scrum Master and, by extension, manage our GitLab activity. In hindsight, this was a perfect designation as I’ve had managerial experience in the past and continue to be a very organizationally driven worker. With these traits, I sought to make our workspace as clear and accommodating as possible, which would provide a strong foundation for our team to begin working. One area I could have improved upon is making sure everyone’s voice is heard. During Sprint #1, my confidence with Linux started at a 2/10, so over the next couple of weeks, I had to refresh my memory while learning new skills. Due to this lack of confidence, I was much more reserved during group conversations as I was trying to soak in as much information as possible. Consequently, I did not explicitly check if everyone felt as if their voice was being heard. Towards the end of the sprint, my confidence with Linux grew greatly. As a result, I was able to participate in group discussions and ensure that everyone was on the same page. 

As a team, our biggest developmental challenge was understanding when problems should be taken on individually or as a group. At the beginning of Sprint #1, my bias weighed heavily towards solving problems as a team as it would grant everyone equal opportunities to learn from hands-on experience. As we soon found out, this approach is costly in time and does not let people engage with topics that specifically interest them. The task that gave us the most hassle was getting the FrontEnd certified so that the Backend could connect with it. This task was our “group task”, which we used working classes to try and resolve. Beyond this “group task”, we each had individual tasks we would look into. This approach to distributing work across teammates and holding each other accountable for learning unique material has been effective so far. After learning a new tool or skill, I request that the individual creates documentation listing the steps or sources they referred to so that all team members have access to what the individual learned. So far, there have been no issues with this approach, and we will continue to refine it in Sprint #2.

As previously mentioned in my review of Apprenticeship Patterns, the pattern that has resonated with me the most this sprint was “Be the Worst”. This self-assessment pattern has allowed me to refresh my knowledge of Linux through completing tasks such as organization and documentation of our completed tasks. This pattern has the individual actively learn and listen to their teammates discuss current issues. From this assessment, the individual can learn from the shared knowledge of the group and will slowly catch up to their level of proficiency. In the case of Sprint #1, my Linux skills were beyond rusty, making me the least proficient in the group. Although I was not able to start helping on the server immediately, I was able to help record our steps. By doing so, I could educate myself on how we approached problems as they arose. Towards the end of Sprint #1, I found my confidence in using Linux and began contributing to the server.

Moving forward, I plan on interacting with the server more, and I have already begun that process by researching encrypted volumes. Additionally, I will continue to refine my skills as our group’s Scrum Master. Now that I am nearly as proficient as other members of my team, I can now focus on making sure we all understand our current goals and have everyone’s voice heard. In terms of teamwork distribution, we have struck a fair balance at the end of Sprint #1. If there is any issue in Sprint #2, I will have to reconsider how we organize and assign tasks. Fortunately, we now have assigned days for backlog refinement, so we can discuss what changes we would like to make during those periods.

-AG

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

During Sprint 1, I went through many ups and downs regarding time management. At first, I was not able to manage my time correctly in order to be more productive, which held me back slightly, and this happened over the course of a couple of weeks. Although, soon enough, I realized that in order to get some work done, I would have to organize my time better. This is when I began to write or research solutions that either I or some teammate needed. Sometimes, even during free time while waiting for something else, I would try to brainstorm for solutions.

Enthusiasm and anxiety were not the biggest help to me during Sprint 1. I got so excited that even before we had any meetings or anything figured out, I was already working on code. As much as the changes got implemented, this is not the best practice. This proved to be correct another time during the Sprint, where I did not realize that I implemented something without verification. As I mentioned in one of my commits, I implemented a way to store the inventory weight in a single database document instance. In order to remove or add any weight to it, that single instance would be modified. I was so excited and had so much work to put in, along with things that I thought could work, that I even forgot one of the most basic practices of programming. I forgot to make sure to add a way to prevent the inventory weight from becoming negative. Enthusiasm is good — it was not the problem. It is actually something that worked well for me. However, the problem was combining it with anxiety. It led to a mess of willingness to get something working against being proactive regarding limits.

Personally, I should try to improve my willingness to get something done while leaving aside the pressure of showing some work. Sometimes the pressure of having something done by the end of the week comes to mind, causing some faulty code to be written.

As a team, we went through many stages during the Sprint. There were stages where communication was missing from some parts. There were stages where not everyone would speak up their opinion. Thankfully, we are past those and seem to be moving on to a stage where there could be slightly more joking around than we should. I am taking myself out of this equation, although I believe that we are all guilty of this, even if not in the same amount. I believe that this should be the next thing our team should work on — to take meetings a little bit more seriously.

The pattern I chose is called The Deep End. It talks about challenging yourself with the work. Sometimes we may procrastinate the decision to go deep, to dive deep into problems. The only problem is that such behavior will only hold us back and lead to no result. You should not wait until you are ready and fully prepared. Always take your shot, go ahead, do it, and do your best.

This pattern relates to my experience since I decided to take this project as the biggest learning opportunity I have had so far. I decided to dive deep, not to look to the sides and overthink about drowning myself with all that there is to learn. This pattern is the literal reflection of how I decided to tackle this class. If I had read this pattern before, I would have come into Sprint 1 with a different mindset. I would understand that it is not just a learning opportunity, but also a chance for me to learn, break, and build without career-threatening risks.

Contributions done to the Project during Sprint 1

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

• Fixed lint indentation problem on openapi.yaml Added a line so lint ignores the API Version long pattern Changed all 401 responses to 400

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

• Changed inventory document instance creation to a single one. Allowing increment and decrement actions to be performed.

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

• Removed 2 difference endpoints for increment and decrement, made a single one for both actions.

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

• Changed where the verification if a document to store the weight exists in the database.

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

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

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

• Updated devcontainer file with new image.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

• Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

• Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas

• Create test calls with mock JWTs to test the endpoint. Test Call

• Implement backend JWT processing/decoding logic. CheckRole.js Implementation

Frontend

• Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

• Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.