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?
Agile and waterfall are actually similar approaches to problem solving except for the timeframe in which they occur and the scale they cover. They both start with analysis and design, move into implementation and testing then end with delivery of a product. However the waterfall approach tries to define and solve all of the problems from the whole project at once and agile attacks a single part (or several small parts) of the project, before moving on to the next parts of the project. This means that waterfall will take a significantly loger time to get to the deliverable stage than an agile approach and might not end with a project that meets all real world needs. With agile, you can learning along the way because you should be getting consistent feedback from your client as you deliver the small sections of completed work.
- 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.)?
As a group we implemented standups and retros to make sure that communication was ongoing and smooth. We wanted to make sure we were all staying on task so we used a Trello board to keep track of our tasks and the stage they were on.
- What role did you take on in the project?
I was the person who typically gathered the others and made sure the communication was ongoing.
- What changes would you make to your approach in future team projects?
I felt our approach leaned more toward the waterfall method. I think on the next group project I would like to get more consistent feedback from our 'client' (or 'teachers' as they are sometimes called :) ). I feel like we made a lot of decisions along the way that, while I stand behind them, might not have been inline with an outlined specification. On a personal note, I definitly need to get better at checking back into the Trello board or task management tools.
- How does retro function in a team project?
The retro gives the team a chance to checkin with their team's progress on various tasks and make sure that work is moving forward rather than stagnating or being repeated. It also gives the team a chance to voice their appreciations and concerns as well as to ask for what they might need going forward.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
We worked very well together so didn't engage in feedback often. We tried to be open with one another and when we did give one another feedback we tried to keep it very constructive and not personal. We all worked very hard to get the project done so I think we were all happy with one another as a whole.
- 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 that I am often not brave enough to give feedback. I am great at giving appreciation and am happy to recieve feedback, but unless I am very bothered by something, I typically don't want to confront someone with any constructive feedback. I think that while it isn't always bad to let things go, I should bring up things that may be on my mind more often. As long as it is constructive and not personal, I should be braver when it comes to sharing that feedback. When approached correctly, feedback is more often than not, recieved with an open mind.
Complete. This response shows a great understanding of the agile process. Nice work!