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:
- What have you learned about the use of agile vs. waterfall in software projects?
The key to me is ALWAYS revisiting the requirements. I go into this more when I talk about project management below but my opinion is as a project progresses in waterfall it is more difficult to consistently compare the project against the requirements. Considering that requirements can be confusing and hard to explain, different people may interpret requirements in different ways. In agile the whole group seems to review requirements consistently, which in industry can find problems with the requirements quicker allowing for the designers to contact the customer and reevaluate the requirements.
- 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.)?
To keep the group on track and organize our requirements we used Trello (https://trello.com/b/gl2w5jps/ideabox). The idea was each card was pulled from the rubric and should correpsond to one piece of functionality. Thankfully the rubric for IdeaBox is layed out in a logical sequence of tasks which made it weasy to break into Trello cards with a checklist of requirements. All cards will have a title (what the functionality is), most will have a description (on the user should ). Labels are also used to organize cards by phase or rubric requirement making it easier to read glance at and get an idea of the project status. Unfortunately the groups GitHub practices and workflow were not as organized as the Trello, but the idea is each branch should correspond to a card and the card can be moved from ToDo -> Awaiting Review -> Awaiting Pull Request -> Master.
- What role did you take on in the project?
I got lucky with IdeaBox because each teammate took on the same role with minor differences. We all took lead on separate pieces of functionality and followed through with our promises. I personally took over the Trello because I believe I have a good system for project management, however during the first retro we concluded the Trello should be made together to give everyone an understanding of the project. I paid close attention to detail to be sure that we were fulfilling the requirements and not running away with the project and ignoring the rubric.
- What changes would you make to your approach in future team projects?
Better GitHub workflow and more consistent attention to the Trello. Although the group is smart and codes fast, sometimes I thought we were coding too fast and needed to slow down and look at the rubric to remind ourselves what we are trying to accomplish. It is easy to knock out a piece of functionality, get overly excited and use that energy to roll straight into the next piece of functionality. More deliaberate thought is needed to be sure the project is clean and doesn't miss any requirements.
- How does retro function in a team project?
Retro is a solid moment to block away a specific amount of time to relfect on a specific timeframe in the project. This gives individual members of the group the chance to bring up any instances that they feel the DTR was not upheld or if they feel the DTR needs to be ammended. With enough honesty and active listening the team can improve as the project goes on instead of sink into their individual thoughts and hold grudges about how the group dynamics functioned or with the project results.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
I would always address the team. We are not doing something well or we are all doing someting well. Specifically for this project our team was on the same page because of our constant communication on Slack. So our feedback processes were simply extended conversations of the ones we were already having throughout the project. One of our rules in the DTR was not to take critism to heart and recognize we all have the same goal of creating the best IdeaBox that we can in the time that we have.
- 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 have been extremely bad at comminucating in a way to not offend. Actively thinking about what I am saying and taking to pick the right words (and having my girlfriend read over my feedback) has helped good feedback come easily to me. But what has helped the most is probably having a solid DTR and open communication the entirety of the project. This makes it easier to be honest at the end of the project because the feedback at the end is nothing I haven't mentioned already. Feedback is a consistent process and the feedback at the end of the project seems to be a formal conclusion of the feedback that has been presented during the project.
I appreciate the level of detail in your responses here and how you've demonstrated the understanding and use of agile. I also appreciate that you've given thought on how to keep improving as a teammate, nice work!