Sprint Retro 1

With the end of our groups first Sprint, overall, I would say we did well as a team. This being the first time any of us were in a group, scrum team, working with Kanban boards, etc. With my group I gave them some reading material on roles/responsibilities of a scrum teams and scrum master. I figured with extra material; we will be able to create a solid plan for this Sprint. For this Sprint, I think we were a little everywhere in the beginning but were able to finally divide the tickets in the backlog with each member taking on 5 per sprint. We were able to get many of the tickets done and then go over what we had done or any impediments that we me have.

I was responsible for the following task:

Create “General” repository: The General repository needed the .gitattributes, CODE_OF_CONDUCT.md, DCO.txt, LICENSE.md, LICENSE_FOR_CONTENT.md, and README.md filles needed to be added. I went ahead and transfer all files over to the Guest Information Systems.

Create “Documentation” repository: The Documentation repository needed the .gitattributes, CODE_OF_CONDUCT.md, DCO.txt, LICENSE.md, LICENSE_FOR_CONTENT.md, and README.md filles needed to be added. I went ahead and transfer all files over to the Guest Information Systems.

check the database format to create our schema: Upon reviewing this task both my teammate Joe and I found that this task was completed before we realized that it wasn’t necessary. The correct tables that we needed are now documented in the documentation repository.

Contact the IAM team to determine security key format: This task was a joint task between myself and Jefferson. We contacted the IAM team, and we are currently waiting on the security key. We will keep open communication with IAM to further pursue future task. We met with Dr. Burdge and determined the two (2) tables and eight (8) API calls we will need for building the API yaml bundle. Currently, that is the only impediment that we are facing.

Study Nest api calls to define our own: RestAPI contained the tables that FoodKeeper needs to implement. After further investigation and the completion of the previous task of contacting IAM team, we were able to determine the correct tables needed. We also developed a plantuml file showing the 8 tables, and created a yaml bundle for the product table, but are now deprecated.

During this Sprint, we really were trying to get to know one another to get a feel of each other’s work ethic. However, we still were not able to showcase each other’s skills or strengths. A good majority of the tickets we had were coping and pasting things over or information gathering. Now, these tickets were and are essential for our next Sprint where we will be able to do actual coding. I think there we will be able to see our strengths and weakness as an individual and as a group to then grow from there.

I think going forward to the next Sprint, we will need more leadership and what we need to get done and keeping a timeframe on that. This past Sprint just felt unorganized, not everyone was being heard and just not as conducive as it should have been. Also, I think clarity from all members of the group is also helpful. Having some members not knowing what is going on can lead to the team not completing their task.

As for personal improvement, I think for me I need to give more input on what we should do as a team. I also think I will take on harder task to help the team move along, with assistance from other members as well. I think working more in a team dynamic to help each other out and complete task in a more sufficient and timely manner. 

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Sprint 1 RetroSpective

Working in a SCRUM team has proven to be a task to say the least. For our first sprint, I was our team’s assigned SCRUM master. Our project? To create a mobile application that runs on android and apple devices to help aspiring U.S. citizens prepare for their citizenship exam. Our project was the only one out of the 8 that had no prior work done before it was assigned to us… aka we were starting from scratch.

The Bad

Before this semester, I wasn’t a stranger to working in a team to complete a project. Despite this fact, working in a SCRUM team felt a bit different. Collectively, we were working together as a team but at the same time we were working independently. At points during this sprint, there were times where we didn’t have great communication. A lot of the same questions kept reemerging after they had already been answered. I feel like we were slower to realize how important effective communication and active listening is. While we did conduct our daily standups, I feel like we only did them for ritual’s sake. Also, I felt the sense of everyone wanting to take the project in different directions because it reflected in how we had our conversations.

The Good

Although I had feelings of stagnation within our team, I do not fault anyone in the group because developing an application while beginning to learn many new things about getting it started is a lot, especially since it’s everyone’s first time. This feeling of stagnation is everything but. Our team’s progress had never stopped moving forward, even if it was moving slowly and that is an amazing display of my teammates willingness to finding solutions in new and unfamiliar territory. During our retrospective meeting we all came to realize that we got all the essential tasks for Sprint 1 project setup completed. I am also hopeful because I feel like my teammates are going to be great to work with once we all learn how to work with one another.

Improvements?

I think as a team we need to put more value into the daily standup meetings. Although they’re short in comparison to the work we’re doing during the rest of our meetings, they are super important in terms of our success. Making sure that everyone is active in the meeting whether speaking or listening is something we can improve upon. Another improvement we can make is being comfortable with having our ideas challenged. Instead of just blindly agreeing with an idea one of us has, we should be able to hold respectable debates on why something may not be great for our project and be alright with the outcomes of the debate.

How Did I Contribute?

Much of the early part of the sprint was dedicated to figuring out which framework we would use to create our application. We broke into three teams of two. Eric and I were assigned to investigate what the Flutter framework would bring in its arsenal to help us complete our project. A few of the things I spent my time researching include:

  • Learning about what type of application Flutter is.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/6

  • Creating a sample “Hello World” -like application in Flutter.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/2

  • Making the decision to install Flutter locally on our system or use docker containers.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/2

Once we decided that Flutter was not going to be the route we were going to take, I used the rest of my time during the sprint to work on the writing portion of our application.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/18

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Sprint -1 Retrospective Post

For our first sprint, I think our group did some things fairly well and had some things that we need to work on. From the first day of Sprint planning, our group got along very well and that made it easier for us to work together. We got straight to work on most days but there were also some days where we all got sidetracked for a while and needed to get railed back in. What I think worked well in the group was we were always asking questions. There were definitely points in the project where we were not sure about what were supposed to be doing and rather stumbling in the dark, we asked each other questions so that everyone in the group was up to speed and knew what to do and what was expected from each other and the project. Another thing that I think worked very well for the group was how open-minded everyone in the group was. We found out very early on in the project that most of us in the group had no experience working with mobile apps. Since we did not know where to start, we all decided to research what frameworks were out for creating apps. This led to the group creating separate issues for each of the frameworks (Ionic, Flutter, React Native). Even though some people in the group already had an inkling feeling that React Native would be the best fit for our project, we still decided to investigate all three frameworks to cover all of our bases. One thing that I think my group fairly well but also poorly was communication. When we were investigating the frameworks, our group of six broke up into three pairs. While we were in pairs, I think we did an okay job communicating with our partners. For example, when I was working on Flutter with Emmanuel, we forwarded resources to another one and let each other know our availability using Discord. So, we kept our partners well informed on what we were working on and when. This is where I think communication is something we need to work on during the next Sprint. Sometimes resources we forward to each through Discord do not end up on GitLab. Discord direct messages is not public information so there was sometimes no public record of what me and Emmanuel were working on. While I think we did a good job communicating with our partners, I think we could have done a better job informing the rest of the group as to what we were working on sometimes. I think as a group we did not do a very good job making sure everything that we did was documented and ended up on GitLab. This is something that I think we need to work on during the second sprint.

As an individual, I think I need to work getting more consistent results. I have a tendency of doing everything all at once so sometimes throughout the week, I don’t think I contribute a lot to the group or the project and then seemingly out of nowhere over the weekend I may contribute a lot to the group whether it be links to resources that I think would be valuable, comments on issues and/or code snippets to mini programs on what we were talking about in class. One thing that I need to work on in class and I am very aware of this issue, is I need to work on listening more to my group. When I work, I tend to become absorbed in my work and ignore the people around me. So, during the next sprint I think I need to work on knowing when to pause my work so that I do a better job listening to my group.  

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective Reflection

In this blog post, I will reflect on the first sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with one sentence descriptions.

To start off discussing what worked well, I would like to pick one thing I decided on doing without much prompting. In addition to checking in with my team during the week and through discord, I made an agreement with myself to try to submit at least once a week a “bigger” message on our GitLab that would hopefully be useful. While I think it is important to post links and resources for us to learn more about certain tools and technologies, I wanted to include some posts/documentation on bigger conversations we had during our stand up meetings and detailed documentation of my setup process with certain technologies (e.g see post on setting up React native and post on the user flow diagram).

For things that didn’t work that well, I would like to discuss some of the technological difficulties I had. For the first couple of stand up meetings, I thought I would be able to do this capstone with my old laptop. After realizing that this capstone would require some more CPU power than my laptop could offer, I purchased a laptop that was more appropriate for the demands of this course. After setting up my laptop, I noticed a significant change in the amount of work I could then produce. I do think there is a minimum laptop requirement as far as performance is concerned, especially when we are testing frameworks and downloading various software/programs to build our first app. For example, I ended up downloading Android Studio for this capstone and this is a large application. There was no way I could have used my old laptop with Android Studio. I’m happy with the purchase I made and I know it will last me into the first couple of years of my professional career.

One thing my team could improve on for the next sprint is better documentation. This is something Dr. Wurst had mentioned and also a bigger conversation we had as a team during our retrospective team meeting. We discussed how although we may be doing a lot of work and research on our own, if we are not documenting this process, it’s like it never happened to future groups who join this capstone project. We discussed how sometimes it’s difficult to document as we work because it breaks up our “flow”. One solution we came up with to address this problem is setting aside 10-20 minutes at the end of our work to strictly document what was done.

One thing I think I can work on doing better in our second sprint is documenting the work I have done. This was especially a challenge for me in the beginning when I was transition from one laptop to another, but now that I have a more reliable set up, this is something that should not be as much of a challenge to do. Moving forward, I like the idea of checking in at least once a week with my teammates outside of regular class time to update them on the progress I have made. This would be a great way to build a routine where I am regularly creating some form of documentation.

Lastly, I will include links as evidence of activity on I’ve contributed to GitLab with one sentence descriptions.

    • In this post, I wrote some notes on some of my research in deciding whether React was a viable framework for us to use.

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

Naturalization Interview Confidence Environment “Sprint 1 Retrospective”

During our first sprint, our group was tasked with creating everything from scratch for this environment from the documentation to selecting the framework we were going to choose to proceed with. I was given the main tasks of assisting with the Read Me and trying to develop a working framework that was able to show IOS compatibility with React Native. The initial issue that we had was that most people in our group did not have a macbook and we needed to find a solution to developing on an ios device without the need of one. React eventually became our only solution and with it being able to project onto an ios device through expo and metro bundler. During this time we were able to assist one another achieve working react environment on everyone’s laptop.

Toward the end of our first sprint, we then proceeded to try and experiment with React where we stumbled upon another issue, and that was that we needed source code for everyone to work off of so that when merge our work together later on, it would work. Along with that, we now needed to think of the future so that students in the coming semesters would be able to work on that too. To be able to accomplish that, now we needed to create a synonymous docker file for everyone to use because many members of our group were working with different dependencies and now we needed to make it work so that not everyone has to go and download multiple things in order to get the code to work.

What worked well during our first sprint was our team chemistry and our ability to bounce ideas off one another as well as being able to assist each other with things we were stuck one. With a group that was able to communicate very well, we used class time to really try and move past any confusion regarding our project. It was also nice that no one judged one another and that we were able to openly express our ideas without any worries.

There was one thing that we lacked as a team the most and that was a sense of direction and urgency from time to time. Since our first sprint was primarily focused around picking the proper framework and most of the basic things of setting up our environment, it felt as though sometimes people didn’t know what to do due to the lack of work. I also believe that because this project was so new and no one was too sure about how things were supposed to go that maybe we were more worried about what we could achieve instead of what we couldn’t.

Individually, I felt as though I could have don’t more to put myself into contributing to things. There were times everyone was assigning things to themselves and I kind of put the groups priorities first instead of mine, and at times that felt as though I was not given enough to do. It also does feel like I am scared about trying to learn a new language and approach things I have not done before. I have the enthusiasm to go and try to learn things but also have the worry about possibly letting my team or myself down, and that might be a reason why I have not stepped up as much as I should.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

My group for this sprint was team 3, and we worked on the FoodKeeper for LibreFoodPantry, and at the end of our first sprint, we have made a pretty good amount of progress. A lot of work has been done to the API for its schemas, paths, and responses, and we have done some work on the backend too with its endpoints.

We have worked well as a team so far by staying communicated with each other and everyone had a roughly even amount of weight and work. We were assigning issues to different people and learned quickly not to have multiple issues assigned to a person at a time because the work would be unbalanced and/or other people would be left without things to do. Each person had an issue either done or mostly done by the next meeting, and they had their next issue assigned after resolving any problems. Everyone was involved in the in person discussions.

Our main area of improvement is communication on gitlab, because for our first sprint, the majority of our discussions were in person or on discord. Because of this, there was not much discussion on gitlab in the comments of epics, issues, and merge requests. This can make it look like we are not having these discussions when people look at the project and go through the work done for it because they can’t see our discussions on discord or in person, so we will using gitlab for our discussions and questions more often. The two other areas that were talked about were how we handled our standup meetings and merge requests. Our stand up meetings would go a little longer than intended because we would have minor discussions when talking about what was worked on, and we agreed to wait until everyone talked about what they did, what they plan to do, and what is stopping them, before we go into our questions and discussion. With our merge requests, we thought it would be a good idea for a few people to check and approve requests before the meetings, so less time is used on reviewing the requests.

As an individual, I think I was doing a good job on the issues I worked on, and I was involved in the in person discussions. However, I was not talking that much on discord because I wanted to wait until I was in person with the group to ask any questions I had. We are focusing more on having discussions on gitlab instead of discord, so I want to be more involved on there than I was on discord for the next sprint.

Gitlab links :

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/merge_requests/13

The schema for modelandview, I originally made it as a .js file and had to change it to a .yaml file.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/merge_requests/28

The paths for the category object that includes getAllCategories.yaml and getCategoryID.yaml.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/3

The endpoints for the category object that include getAllCategories.js and getCategoryID.yaml.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/merge_requests/5

The product endpoints that includes getAllProducts.js, getProductWithID.js, getProductIDName.js, and getProductCategoryID.js.

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/merge_requests/33

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/blob/main/src/paths/index.yaml

The index.yaml file that covers the paths for the api, the put methods from the first request were meant to be get methods, which has been fixed in the file itself.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.

Issues I was Assigned to:

Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.

Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.     

List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.

Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.

Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.  

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

Sprint Retrospective

The first sprint was the very initial experience of me being a Scrum Master. It was an astonishing experience, and I have learned many things from this Sprint as well as from my teammates. From a personal perspective, I think things that worked well with us were being able to finish the entire issues that we had listed out during Sprint Planning. In addition, our team worked very efficiently as a group and barely had any conflicts during this first sprint. Everyone had the opportunity to express their ideas and to be able to ask questions. From that point, we had been able to work out the issues as a group rather than individually which was also a good point. Our team was also exceptional at listening to each other. This is a plus point, by listening to other people we would be able to learn more about that person along with the ideas.
Despite all the good things that we had during our first sprint, there were also some key issues that we would need to work on. First, although we communicated well and didn’t have any collision during the first sprint. We need to improve the communication on Gitlab. This was also mentioned by the professor in the Sprint Review. We did not show enough participation in Gitlab which led to our group losing one point for Sprint Review. Second, we did not split the amount of work equally and did not organize the work effectively. Hence, team members occasionally were confused about who was working on what part. During the first Sprint Planning, there was only one team member who contributed most of the issues and as a Scrum Master, I do not think I have done enough and contributed enough as I took on this big role.
The changes that I think we would need to do is to communicate on Gitlab by commenting on each other issues and contributing more to the issue board. Also, I think that every time we change the code, we need to inform our team members so that they could review changes that others have made to ensure that the code would not break the initial system. Another point is that our team needs to communicate more outside of the classroom such as Discord. During the first sprint, the only time that we talked and solved the issues was during class time.
As an individual, I think I would need to be more productive and do a better job as Scrum Master. During the first sprint, I did not have much idea of how to be a Scrum Master and specifically is how to be a good Scrum Master. As a scrum master, I did not do well with bringing everyone onto the same page and did not split the work evenly for every member. Also, I failed to keep track of the work that every team member had contributed. This to me in the future would not be a good thing because a good scrum master should be able to maintain and keep track of everybody’s work to make sure the products would be delivered on time.
The first sprint was such an interesting experience for me at I started working as a team compared to the previous semester. Even though there are many things that need to be improved individually and also as a team. Overall, the first sprint was not as bad as I thought it was going to be.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Reflection on the Craft over Art Apprenticeship Pattern

The Craft over Art Apprenticeship Pattern describes how despite us as software developers wanting to make artistic code, we must always prioritize utility over artistry. It is important to make code that serves its purpose over code that is technically challenging or code that has extra features. If we aren’t meeting what our customers want then we are no longer craftsmen.

I think that this pattern is pretty important to keep in mind. I often find myself trying to make code that is interesting or that I think will do a better job than what I am being asked to do, but this sort of over-engineering is not what isn’t what I am being asked to do. Despite wanting to do what I find more fun, the needs of the assignment or customer come first. Function over form. Most of my friends are artists, and my dad is an artisan over being a craftsman, so to me, this isn’t something that comes naturally. Moving forward, I need to make sure to keep in mind that what the customer is asking for is what they want, not what I think would be better. I really liked the emphasis that they put on utility as being paramount. Something that is technologically brilliant but has no utility is ultimately not the job of a craftsman, and not really what we should be looking for as software apprentices. They aren’t saying that we shouldn’t still strive for beauty though, which I am sure I will never quite be able to shake, but just that we need to prioritize the function. I think that this mindset will serve anyone well, especially in this profession. People that can’t listen to what the customer wants won’t last long in any professional field.

I do disagree with the idea that all software must be crafted for utility though. Technologically brilliant software, beautiful software, has a place and is ultimately important to the future of this profession. If developers never thought out of the box to create something truly amazing, we’d still be living in the dark ages. But I do agree with the overall point of function over form. Even in that mindset, however, I think that we should take creative liberties when it is appropriate, and allow ourselves to be shown in our work. Much like the world without art, code without beauty is miserable.

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.

Retrospective 1

When I saw the assigned group for the project, I had no idea who the people were. I saw the familiar faces, but did not know anyone’s name. On the first day of us seeing each other, we had a good greeting, even though we were missing two people. That day we all just talked about our repository, discord, and how to access them. We also talked about who will be the scrum master, for the project. The day went smooth like a butter.

On to the next week, all 6 of us were there and our scrum master (Vien) already had in his mind what to do for the project and how the planning should be, while all I did over the weekend was sleeping. Our scrum master divided the group into two, Frontend and Backend. I choose to be on the frontend team as I kind of wanted to learn more about frameworks such as Vue, React, or Angular. As I cloned the repository to my local machine, I had no idea what I was looking at, the docker images were wrong, the form for guest info did not open all the contents, the styling of the form was not responsive, and so on. Our (frontend team) first task was to refactor the frontend repo using vue.js and this is exactly what I wanted, I wanted to get more in depth with Vue.

On the third week, our scrum master already put up a lot of issues in the issue board, and I was so happy he did it. There was already a branch called refactor-branch which was created by our scrum master, and it had two components inside it. Frontend had 2 separate parts to complete. When a page reloads for the first time, it should only show an option for guest ID and nothing else, once the guest enters the ID, the rest of the form should display. Our main goal for that week was to display the rest of the form when the user clicks the submit button. One of my teammate refactored the guest login while the other teammate did the rest of the form in vue.js, and I connected both of their work/component in the main app.vue.

Fourth week, our side of the project were starting to look well, but there were still lots of work for us to do. Although I connected the two components together based on the button, it had its flaws, the form opened and closed once the user enters all 7 digits of their ID. To make it short and easy to understand, the button acted like a switch for a light. If a user clicks once, the form shows and when a user clicks again then the form hides plus the form stayed there even if a user removed their ID. It was a little success from my side, but in general, It looked lame, and I felt stupid. In order to fix that, I made little changes in the id-input component, and I was able to get the form to show only once and when a user removes even one digit from the search input then the form hides until he/she enter all 7 digits again. link.

5th week, Everything was going smooth. Teammates were adding small little important details here and there but at the end, who would want to use a form that has no style right? So I took a task to style the whole form which was left by previous students. And at the end I was able to get the form to look decent, although we might change the style or import one from the existing website.

At the end of the sprint, when my teammate displayed the form in a larger screen than my personal device, I noticed that the form stretches with the screen size. I managed to make form adjustable in phone screen, but I forgot about the screen that’s bigger than my computer, so I fixed it by setting a max width here.

Overall, I think our spring went well. The frontend side did a pretty good job and I when I looked over all the commits in the backend repositories, I noticed that they have been working even harder than the frontend team. In my opinion, I think it would be better to have only 2 people on the frontend and have 3 people for the backend while scrum master looks over all the infracture/review for the tasks. As for myself, I need to discuss more with my group about my work and share everything. With all due respect to my teammates, I don’t think we could have done this well without our scrum master (Vien) who have a good vision and I can tell that he is really putting all of his time to this project. Overall, I’m glad I’m working with this amazing team.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.