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.
- What have you learned about the use of agile vs. waterfall in software projects?
I like the agile method, because you can move the status of various tasks around based on it's present state. So if you thought it was done, it's easy to move it back to "in progress". I also much prefer getting feedback throughout rather than just at the very end.
- 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.)?
We used Trello to manage our tasks, and monitor the progress of the project. It was nice to have the ability to see where everyone stood on their assigned parts.
- What role did you take on in the project?
I set up and managed the trello boards & lists, in addition to helping with the project of course.
- What changes would you make to your approach in future team projects?
I think ensuring members are updating Trello is really important. This was mostly done, but given I took on that task, I would view it as the most important thing to stay on top of it, because it tells us exactly where we stand. In addition, I think I could do a better job of creating lists and tasks that more specifically show what the full scope of our project will be, so that we don't get stuck with additional tasks soon before the project is due.
- How does retro function in a team project?
It's an opportunity to come together and discuss where we each stand on the project, plus voice any concerns and victories we're having. The most important part of this is ensuring the team doesn't split or drift apart.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
I don't think we utilized it as much as we could have. I felt communication was actually quite good, but in terms of meeting together regularly with the express purpose of the retro, I think we could have done better. I also didn't provide as much feedback as I could have, beyond "this looks great", and I think some concerns of mine, and others, weren't addressed because of this.
- 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 err too much on only providing good feedback, and just counting on things to work out in the end if I have valid negative feedback. I'm too concerned with it being viewed as a personal attack, instead of an opportunity to be heard, and to share my own knowledge for the betterment of everyone. The experience in the group project sort of shined a light on this shortfall. In the future, I'll probably try to be more proactive in voicing my opinions.