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?
I've learned that almost the entire industry says it strives for agile practices, but ultimately ends up using a waterfall approach. There are many factors -- but mostly funding and a desire to not show an imperfect project -- that effect everyone's work cycle.
- 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 Idea Box, my group decided to use Trello. We sat down together right away and moved all of details from the project spec to cards and lists. We then individually added commentary to each of the cards to jot down ideas or Javascript solutions we thought might be applicable. (This also served to make sure each of us read the spec closely.) We then created lists for each of the teammates, as well, to make assignments. As items were completed, they were moved to a final 'Done' list.
- What role did you take on in the project?
My group worked very well together. We wrote code side-by-side a lot, and each of us filled the driver or navigator roles on a loose but effective rotation. When we got stumped, we all individually started researching solutions, then making suggestions back to the other two. Then we'd begin coding again. I don't think any of us differentiated all that much from the others. That seems ideal!
- What changes would you make to your approach in future team projects?
I was very happy with our outcome and wouldn't change much for myself. I do, however, understand that each group of individuals has different needs and that the needs change over time.
- How does retro function in a team project?
Retro functions to have frequent check-ins with each other, the project spec, the progress of the team and other higher level conversations. In a business environment, it would be important to cover financial status and even general company news, but the goal is to stay "out of the weeds" on the code and monitor goals and processes.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
We naturally gathered almost every day next to our poster with our goals, which lended itself nicely to revisit them often. We were able to speak openly about frustrations we were having with the project; I found that early and honest communication lent itself to smooth solutions. Appreciation, coaching and evaluation were all used as part of the ebb and flow of conversation.
- 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 feel I am a strong listener and very good question-asker, but am less skilled giving direct feedback in conversation. I prefer written communication because it allows me the time to compose and edit my thoughts. I recognize that time is not always available and both skills are essential in a team environment, so I strive to speak up early and accept that there is always risk of imperfection.
Really appreciate your reflections here; that level of detail will really be useful in interviews!