Retrospectives reflection

Reflections from sprint Retrospectives

Name	Reflections
Aaron Zhong (azho472)	Prototype: Initially it was hard to plan tasks and coordinate work as some team members worked from other locations (computer labs) or from home. I encouraged everyone to come to the assigned group meeting times so that we can work on the project more efficiently with co-location. Final: I found that pair programming worked best because it often made for better quality results. This also meant that we only had to schedule times to meet with our pair rather than the entire team. Although most of the time we did pair programming as a group. This made turnaround for questions between groups working on different tasks easily. I also found that we needed to remember to update Trello regularly to prevent issues like two pairs working on the same task. Also, it was often difficult to test all the features after implementing a feature so bugs were introduced without being noticed often. This needed to be check before merging into the master branch
Van Pham (Johnny - dpha010)	Prototype: Working with the customer, we had a few main user stories and there was only so many tasks into which we could break them down. Around sprint2 I suggested that we stop resetting our scrum board which is a feature of Kanban. We now understand that development teams tend to choose agile hybrids to match their specific requirements. Final: Sometimes people were working on secondary branches for new features for too long before merged, I suggested we do quick merges as soon as the features were done. People often forget to refractor regularly, especially cleaning up dead-code and unused code. I recommend we refractor and document the code more often, this can be done in team meeting where we can examine the code together.
Stella Li (hli936)	Prototype: As this project is a practice for Agile development, the customer and our team are more focus on the functionality instead of the UI. However, when I worked in the industry, my primary task was coding precisely as current UI design. Good UI design can help a team choose a suitable platform and simplify unnecessary coding work. After I informed the importance of UI design to our team members, they agreed with me, and I started work on the UI concurrently while still helping with the backend and making sure I knew how they would integrate.. Final: The inefficiency of pair programming is because all of us are junior programmers. When we met a problem or bug, we need to search online to find a solution. However, all of us has a different thought that delays our troubleshooting process sometimes. In this situation, if one of us is an intermediate/Senior programmer, the problem can be found and solved quickly. Additionally, regularly optimizing our code is vital, it decreases the code redundancy and the appearance of bugs.
Sudara Fernando	Prototype: We did a lot of work individually in the first few sprints. After discussions with the team we agreed to have everyone work in pairs. It worked well and we have been doing that since. Generally, after the task selection in our sprint planning, members choose their pair partner by themselves usually based on tasks. During the final stages, we even worked in pairs of 3 or 4 which made us progress faster than we expected. This was the first time I got a chance to work in pairs in a real-world-like project, and I think it is one of the best practices that Agile has to offer. Final: Sometimes people could not attend the meetings which is understandable. However after discussing with the team, we agreed that whoever cannot come should inform everyone in advance to be able to know how many are coming and plan accordingly.
Kaimin Li (Alex)	Prototype: Attendance in our meetings was sometimes problematic, and often it was the case that someone knew something but was not in the meeting slowing down progress and causing inefficiencies. We decided that everyone should try their best to attend the meetings and should attend at least one per week. This worked quite well and made our work on the project much more efficient. Final:I felt that our testing procedures were not comprehensive enough, and that we were completing sprint tasks without checking to make sure that new bugs didn't arise. I suggested that we do end to end testing as well as edge case scenarios after major tasks are completed to make sure most bugs are found and fixed.
Jay Pandya	Prototype: Pair programming was one of our most applied agile practices during this project, however I noticed some inefficiencies in how pairs were made. There were some cases where a member of another pair had knowledge of how to solve a problem that another pair was having, but this was not being communicated. I suggested that pairs should not be fixed, and that we should introduce fluidity into pair programming, allowing team members to move to different pairs. This meant that the skill-set of each person was utilised to its full potential and also meant that issues were solved quicker. We decided which pairings would be most appropriate for every pair programming session, and found that we were able to work much more effectively. Final:We found that the Trello board was not being updated quickly, meaning that work was being done but not documented nor communicated to the rest of the team. It was agreed that we would assign ourselves to all Trello tasks that we were working on, and updating the status before moving on to the next task. We also made it a priority to have our work reviewed by another member of the team before it was marked as completed.
Waleed Al-saady	Prototype:We sometimes seemed to be working on tasks in isolation, without communicating with the other areas of the project. I felt that this slowed down our progress towards the goal and that focus on what we wanted to achieve in each sprint by thinking about the integration of the tasks would be very helpful. We communicated a lot more between pairs and also sought to focus on a specific overall goal in each sprint such as deliverables or completing specific functionalities. Final:While the Firebase Nosql solution fitted well with our project's structure and flow, unfortunately there is no API documentation for it which meant that sometimes we were using methods that we did not fully know how they worked or if there were better methods to use. This caused some slowdowns in initially. I suggested that we share our knowledge of how the Firebase API works, and discuss how to best implement our features that require database interaction.