In interviews, you'll be asked about how you approach working in projects, and being able to describe how you utilize agile processes is a great way to help you stand out as a junior developer candidate. This reflection is meant to help you develop this skill.
With that in mind, please answer the following questions in your own gist about your group project:
I learned that the more dynamic and robust Agile method of consistent testing and feedback is a better workflow than waterfall where one piece of functionality is completed and deployed at a time. Even though 'deployment' right now just looks like merging to our master branch, I can see how a more Agile workflow increases productivity and quality.
2. How did you and your group approach project management in this project (what tools did you use, how did you hold each other accountable, etc.)?
For IdeaBox, we used a Trello project board to track our user stories. We each would assign ourselves one story to work on, then move it to the 'in review' column when we thought we were done. Then, the other group members would review that story. If everything was good to go, that reviewer would then move that story to the 'complete' column. We also did a lot of group work on Slack calls, so we were able to work together and stay on the same page. Even when working remotely, we tried to follow our normal workflow regarding the project board and git/GH standards.
I feel that we all had equal roles in this project, especially since we did so much remote work. I wouldn't say we had one designated leader. I attempted to stay on track with my team and make sure we all did an equal amount of work.
Our team did not do a great job of making small commits on fewer number of PR's. In the future, I want to better utilize PR templates to make sure our repo is as easy to read as possible. I think we did a good job of reviewing each other's code when needed, but I want to have a more organized repo next time around.
A retro is important to ensure that a team is sticking to the expecations we set for one another at the onset of the project with the DTR, and to make sure everyone has a chance to be heard. It is important that each person feels comfortable to say if they feel like the team is meeting the set expectations, or to say what things are working well. Retros keep lines of communication open and make it harder for team dynamics to fall underneath the radar.
6. In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
Unfortunately, I was sick during our team retro last week. However, I did follow up with my group. They were honest and explained to me the challenges and wins they had experienced so far in the project. The principles of feedback were definitely kindness, honesty, and growth mindset. In our DTR we said that we wanted each other to know that all feedback comes from a place of learning and that would not try to 'one-up' one another or speak rudely.
7. How would you describe your ability to communicate feedback? How has this experience affected your communication skills? How do you want to improve in your ability to communicate feedback?
I think I am good at giving feedback for the most part. Possibly at times I can be a bit too blunt, and could make it mroe clear that I don't mean to upset or call anyone out, but that I just want to get to the bottom of a problem. I don't think that was an issue on this project, but something I should keep in mind for the future. This experience defintely made my remote work skills much stronger due to the snow days. It was a challenge to stay focused and organized working completely remotely, but I thought it was a great learning experience.