KevDev90 · September 12, 2019 16:08 · allisonreusinger · Sep 16, 2019
diff --git a/Agile-feedback-and-reflection b/Agile-feedback-and-reflection
 What have you learned about the use of agile vs. waterfall in software projects?

 I've learned that it's much easier and more practical for me personally to implement a agile methodology as opposed to waterfall in my software projects. I really like the idea of getting to the minimum viable product (mvp) and just get the thing I'm trying to do to get up and running and then recieve feedback on it shortly thereafter so I can move on to the next thing that I need to work on. Whereas with a waterfall type approach I think it would be much more difficult to try and use that strategy because you would essentially have to build everything at once and just hope that everything works well together.

 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.)?

 My group utilized the github projectboard and I felt that really helped with keeping us focused on each particular task that we were working on. We held each other accountable by constantly slack messaging each other and also going over our goals twice everyday; once in the morning and also once before we left turing for the night.

 What role did you take on in the project?

 I took the role as a strategic planner mostly I would say. I liked to keep us on track and focused on working through a particular iteration all the way before we would move onto the next one to ensure our work was being done in a quality type of way.

 What changes would you make to your approach in future team projects?

 I would have liked to utilize more of the driver naviagtor type of workflow in my future team projects. I felt like on this last group project we tried to divide up too many tasks amongst us individually and that led to a lack of communication as well as it leading to some functions breaking other functions and slowing our progress.

 How does retro function in a team project?

 A retro give teams the opportunity to pause and reflect on how things have been going and then, based on those reflections, identify the improvements they want to make. Conducting retros often supports a team to continuously improve their performance. They essentially have us look at our past performance on projects to help us improve our performance on future projects.n In our group for instance we discussed what went well, what didn't go well, what we had learned, and what was still troubling us.

 In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?

 In my team retro I engaged in the feedback process by mostly highlighting what had gone well and what hadn't gone well whenever we took the time to reflect and further break these things down.

 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?

 My ability to communicate feedback is pretty solid but there is definitely room for improvement. This experience has really affected my communication skills because going through that retro thought process over and over really helped me to get a good grasp of where we were at overall and that helped me to communicate to my teammates on a higher level. I would like to improve my ability to communicate feedback further by making the feedback process more continuous. I would also like to focus on our groups strengths as a whole more, I think it's easy to get tied down in the negative things occuring on a project but it's much more constructive to focus on the positives and try to further implement those into everything the group is doing going forward.
	What have you learned about the use of agile vs. waterfall in software projects?

	I've learned that it's much easier and more practical for me personally to implement a agile methodology as opposed to waterfall in my software projects. I really like the idea of getting to the minimum viable product (mvp) and just get the thing I'm trying to do to get up and running and then recieve feedback on it shortly thereafter so I can move on to the next thing that I need to work on. Whereas with a waterfall type approach I think it would be much more difficult to try and use that strategy because you would essentially have to build everything at once and just hope that everything works well together.

	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.)?

	My group utilized the github projectboard and I felt that really helped with keeping us focused on each particular task that we were working on. We held each other accountable by constantly slack messaging each other and also going over our goals twice everyday; once in the morning and also once before we left turing for the night.

	What role did you take on in the project?

	I took the role as a strategic planner mostly I would say. I liked to keep us on track and focused on working through a particular iteration all the way before we would move onto the next one to ensure our work was being done in a quality type of way.

	What changes would you make to your approach in future team projects?

	I would have liked to utilize more of the driver naviagtor type of workflow in my future team projects. I felt like on this last group project we tried to divide up too many tasks amongst us individually and that led to a lack of communication as well as it leading to some functions breaking other functions and slowing our progress.

	How does retro function in a team project?

	A retro give teams the opportunity to pause and reflect on how things have been going and then, based on those reflections, identify the improvements they want to make. Conducting retros often supports a team to continuously improve their performance. They essentially have us look at our past performance on projects to help us improve our performance on future projects.n In our group for instance we discussed what went well, what didn't go well, what we had learned, and what was still troubling us.

	In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?

	In my team retro I engaged in the feedback process by mostly highlighting what had gone well and what hadn't gone well whenever we took the time to reflect and further break these things down.

	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?

	My ability to communicate feedback is pretty solid but there is definitely room for improvement. This experience has really affected my communication skills because going through that retro thought process over and over really helped me to get a good grasp of where we were at overall and that helped me to communicate to my teammates on a higher level. I would like to improve my ability to communicate feedback further by making the feedback process more continuous. I would also like to focus on our groups strengths as a whole more, I think it's easy to get tied down in the negative things occuring on a project but it's much more constructive to focus on the positives and try to further implement those into everything the group is doing going forward.