Sprint 2 Retrospective

[kbuffardi]

Anything you thought worked particularly well or particularly poorly?

Any requests/suggestions for how we can adapt for Sprint 3 to be more efficient and effective?

[AbhinavReddy-Dev]

I would to propose an idea of creating better UI since we are developing it all new and there are better ways to implement slick components' css with material-ui. That being said, we can use those old screenshots in the Figma to reference the expected functionality. It will take time to design the prototype and develop, so, it will be best to come up with own design as one develops that is in sync with the existing new UI, like in Login/Signup pages.
Please add to this.

[kbuffardi]

With that said, I've noticed some inefficiencies in the integration between teams. During class, we identified that a few teams needed to have a conversation to make sure that the front-end/testing/CI/DB teams needed to chat to integrate the parts so that we can have the foundation of the infrastructure that will support teams focusing on specific features rather than just independent components of the project.

That has been a general issue for the last couple weeks and it is yet to be completely resolved, which means it persisted for an entire sprint. If anyone has suggestions on how we might avoid those delays and the "silo effect" of teams working in isolation without good cross-team communication, this would be a good place to discuss how we might change how we operate.

[kbuffardi]

Similarly, some people have expressed concern that there needs to be more opportunities for everyone to contribute code, instead of being dependent on a small percentage of the class committing code that's merged into main. I've mentioned a few times suggesting that those who have already committed code to main should take a step back to support others making their own contributions. However, if anyone has suggestions for a systematic way to address this issue, we can try to address the problem with new approaches.

[AbhinavReddy-Dev]

I think that is a fair critique (and part of the intention of stripping out the old branding and replacing it with generic-but-usable components from Material UI).

However, let me also emphasize that the point of the Retrospective is to focus on the process/roles/tools we're using in the development process to improve our approach to delivering value efficiently and effectively. This should be distinct from feature requests that help specify what is valued (i.e. specifying a new UI) -- that info can go in the #54 Future Features thread.

If anyone has suggestions on how we can be more effective (e.g. how we organize in teams, how to communicate between teams, etc.) that could be helpful in improving how we operate as a development team.

I agree, this point of UI should be in the UI feature specific discussion, but we have noticed that those who were working on the pages in the previous sprints, were replicating the old UI, and that is something I think we should do differently in the up-coming sprints.

With that said, I've noticed some inefficiencies in the integration between teams. During class, we identified that a few teams needed to have a conversation to make sure that the front-end/testing/CI/DB teams needed to chat to integrate the parts so that we can have the foundation of the infrastructure that will support teams focusing on specific features rather than just independent components of the project.

That has been a general issue for the last couple weeks and it is yet to be completely resolved, which means it persisted for an entire sprint. If anyone has suggestions on how we might avoid those delays and the "silo effect" of teams working in isolation without good cross-team communication, this would be a good place to discuss how we might change how we operate.

This response is only about the frontend-backend communication, now there are at least 2 people working on each page UI, it would be nice if anyone of the contributors proactively contacts the backend team to discuss about the necessary API responses to start integrating the appropriate components instead of dummy components to change them later.
Also, there is very less communication in the discussions on GitHub and whatever the communication between the teams till now happened in the issues and pull requests, once the issue or the PR is closed, all that conversation is not explicit. My suggestion to this issue is to either have recurring meetings among different teams each week or have a discord server with text and video channels to communicate with different teams whenever necessary. One down side of this is the documentation of the application, but if we are careful enough to document the code as it is written, then it should work out.

Similarly, some people have expressed concern that there needs to be more opportunities for everyone to contribute code, instead of being dependent on a small percentage of the class committing code that's merged into main. I've mentioned a few times suggesting that those who have already committed code to main should take a step back to support others making their own contributions. However, if anyone has suggestions for a systematic way to address this issue, we can try to address the problem with new approaches.

It will be really helpful if everyone who has a merged code into the main can assign themselves to other issues where they can help others by pair programming. Since we have a contributors section in the repo to keep track, we can skip them for commits to main in the next sprint and take up responsibility to help others commit to main in the sprint. Those who have already made commits to main can create more sub-issues necessary for improvement or addition to the project, this will also help in better identification of issues to take up for those who have not contributed to main yet.

This is my understanding (from discussions outside the class) of what is happening with those who are new to frontend, backend, CI, and testing.

[hardikpatil]

I think that is a fair critique (and part of the intention of stripping out the old branding and replacing it with generic-but-usable components from Material UI).
However, let me also emphasize that the point of the Retrospective is to focus on the process/roles/tools we're using in the development process to improve our approach to delivering value efficiently and effectively. This should be distinct from feature requests that help specify what is valued (i.e. specifying a new UI) -- that info can go in the #54 Future Features thread.
If anyone has suggestions on how we can be more effective (e.g. how we organize in teams, how to communicate between teams, etc.) that could be helpful in improving how we operate as a development team.

I agree, this point of UI should be in the UI feature specific discussion, but we have noticed that those who were working on the pages in the previous sprints, were replicating the old UI, and that is something I think we should do differently in the up-coming sprints.

With that said, I've noticed some inefficiencies in the integration between teams. During class, we identified that a few teams needed to have a conversation to make sure that the front-end/testing/CI/DB teams needed to chat to integrate the parts so that we can have the foundation of the infrastructure that will support teams focusing on specific features rather than just independent components of the project.
That has been a general issue for the last couple weeks and it is yet to be completely resolved, which means it persisted for an entire sprint. If anyone has suggestions on how we might avoid those delays and the "silo effect" of teams working in isolation without good cross-team communication, this would be a good place to discuss how we might change how we operate.

This response is only about the frontend-backend communication, now there are at least 2 people working on each page UI, it would be nice if anyone of the contributors proactively contacts the backend team to discuss about the necessary API responses to start integrating the appropriate components instead of dummy components to change them later. Also, there is very less communication in the discussions on GitHub and whatever the communication between the teams till now happened in the issues and pull requests, once the issue or the PR is closed, all that conversation is not explicit. My suggestion to this issue is to either have recurring meetings among different teams each week or have a discord server with text and video channels to communicate with different teams whenever necessary. One down side of this is the documentation of the application, but if we are careful enough to document the code as it is written, then it should work out.

Similarly, some people have expressed concern that there needs to be more opportunities for everyone to contribute code, instead of being dependent on a small percentage of the class committing code that's merged into main. I've mentioned a few times suggesting that those who have already committed code to main should take a step back to support others making their own contributions. However, if anyone has suggestions for a systematic way to address this issue, we can try to address the problem with new approaches.

It will be really helpful if everyone who has a merged code into the main can assign themselves to other issues where they can help others by pair programming. Since we have a contributors section in the repo to keep track, we can skip them for commits to main in the next sprint and take up responsibility to help others commit to main in the sprint. Those who have already made commits to main can create more sub-issues necessary for improvement or addition to the project, this will also help in better identification of issues to take up for those who have not contributed to main yet.

This is my understanding (from discussions outside the class) of what is happening with those who are new to frontend, backend, CI, and testing.

Agreed, proactive cross-team communication regarding API responses could help save time and mitigate potential issues down the road.

[hardikpatil]

Similarly, some people have expressed concern that there needs to be more opportunities for everyone to contribute code, instead of being dependent on a small percentage of the class committing code that's merged into main. I've mentioned a few times suggesting that those who have already committed code to main should take a step back to support others making their own contributions. However, if anyone has suggestions for a systematic way to address this issue, we can try to address the problem with new approaches.

Yes, we could also consider implementing a rotation system where different members take the lead on certain tasks or features or enhance newly built ones, for instance, sales reports. This way, everyone has the chance to contribute and learn new skills. We could also have regular code review sessions where everyone can give some feedback and make suggestions on each other's code or similar involvement as @AbhinavReddy-Dev mentioned considering pair programming.

[prestonmasseyblake]

if you guys want to make a new UI / update the UI can you make sure its responsive some of the UI that has been merged is not mobile friendly.

[sachinprasad1998mav]

Anything you thought worked particularly well or particularly poorly?

Any requests/suggestions for how we can adapt for Sprint 3 to be more efficient and effective?

We can add a forgot password functionality.

[hardikpatil]

@sachinprasad1998mav This could be added in the #54 future feature, not in the retrospective.

[ysiddhapura]

Anything you thought worked particularly well or particularly poorly?

Any requests/suggestions for how we can adapt for Sprint 3 to be more efficient and effective?

I think the implementation of scrums really helped to communicate with the teams, and the scrum of srums as well. In addition, if we could also have a better timeline of when things would be integrated or understand the changes a little bit more, to gain more knowledge on some of these technologies, since its many of our first times using it.

[hardikpatil]

Agreed. or maybe more time/room for the discussion on tasks/issues in the class.

[kbuffardi]

Next Tuesday (beginning of Sprint 4), we will conduct a scrum of scrums and then I will share (based on our current state) prioritization of user needs. I hope that will allow time for then teams to organize and plan on issues for that sprint.