agile_feedback_reflection.md

1. What have you learned about the use of agile vs. waterfall in software projects?
   The waterfall method goes through 5 steps. The requirements portion sets up the overall setup instructions for development. The technical portion is where software architects design what the app should look like. Then implementation is when the developers build the application based on the previous steps. Then quality assurance team verifies the program and tests for bugs. The final step is releasing the program to the user. The problem with waterfall is it is one long process and users have little interaction during development. This is where agile is more effective. Unlike the long process of waterfall, agile workflow works in multiple 2 week sprints. The advantage of this method is that it allows users to submit feedback in increments before the final product. The steps are the same as waterfall except you do them quicker and repeat the process multiple times until the program is finished. The downside to agile is there is no real cost estimates.
2. 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.)?
   During our cross check project, we didn't really follow a particular method but I'd say it mostly resembled the waterfall approach. We had our requirements laid out before we started We only had a week and a half so using agile would have been difficult in that time frame. I guess I could also argue that we did one sprint of agile and if given more time, we could have done another sprint. We used a project board to plan out our steps ahead of time and assign different methods to each of us. We held each other accountable by trusting that we would get these methods done in a timely manner and we never had any problems. We also worked together as a team on the first few portions and some of the methods in the middle iterations of the project.
3. What role did you take on in the project?
   I feel like I took a role as a leader of emotions in our group. Although everybody was easy going, I used empathy to relate to both of my partners and find an even ground for everybody's approach to testing or building methods. I wasn't the best developer in the group so I used time working together to learn new things and find new ways to design our program. I definitely learned a lot from both of my teammates.
4. What changes would you make to your approach in future team projects?
   I don't think I'd make a lot of changes. I'm very proud of the way things turned out and I think we built a very strong program. There was a time when I built a few CSV test files to make tests run faster while my teammates worked on portions of the CSV loading files. I wish I had been working with them on these and spent time outside of the group to build those CSV files. Other than that, we all worked with great communication and teamwork.
5. How does retro function in a team project?
   We used retro to look at how far we were on the project at the beginning and end of each day. On the very last day, we were already done with our project, so we looked it over and did a final retro to see how we could improve our methods and refactor the design to be easier to read. Before our final eval we had a final retro to discuss what would we be going over during the evaluation so we would be as prepared as possible individually and as a team.
6. In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
   We gave each other feedback often and received feedback from instructors and our peers to help us along the way. The principles we practiced most were being honest and specific when it came to our compliments, criticism and things we wanted to improve on. I think our strongest feedback was showing each other how appreciative we were on everybody's individual hard work. I especially appreciated how well we worked together and how Alexandra brought great leadership to our team and Stella kept us together and communicated everything she was thinking.
7. 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?
   We all communicated great as previously stated. I think it can be tough sometimes because you don't want to hurt each other's feelings, but we were very honest on things we could improve. For example, I had a method that was very tough but it was also very long. My teammates told me that my approach was solid but my method should be cut into something smaller. I had no idea about rule zero where methods need to be a certain size and now I know thanks to incredible feedback. Feedback helped me and my teammates out and that's really what the last few weeks have really been about. I want to keep improving on my feedback by being as specific as possible. I know that I can speak up more when I want to figure out what my teammate is thinking when they're writing something that I don't understand and sometimes I don't feel confident enough to speak out. I hope as this school goes on, I can learn more and not be afraid to speak up when I know something can be done in a better manner.

Really awesome reflection here and explanation of agile and waterfall -- nice work!