What have you learned about the use of agile vs. waterfall in software projects? Agile is a much more efficient and safe process than waterfall. With waterfall, you invest large amounts of time and money into a project, essentially betting that the end product will be successful.
With agile, you can get constant feedback and make minor improvements with every incremental release. You can really utilise 'iterative development.' This ensures you don't waste time on pointless features, and can improve other featuers based on specific user feedback.
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 utilised Trello projects boards in this project. We made sure that if we ever split up for a night that each person would have a certian piece of functionality to work on. Otherwise, we worked together.
What role did you take on in the project? I felt like I was a good balance of executing things (taking initiative to solve functionality to keep us on schedule) but also there were points where I felt like an overseer, making sure the group understands the big picture while we are working through a problem. It was actually very helpful because the driver would often have a more close view of our problem, where I'd have a more birds-eye view of walking through our operations and then the driver who had a closer view of the code would realise when I was walking through the operations at which point our functionality was messing up.
What changes would you make to your approach in future team projects? I think our group had a good balance of slowing down when needed to get everyone up to speed, but also picking up the pace when we needed to get stuff done. I think I would take more days to work in the future because there were a few days, probably more in the beginning, where we could have gone further but since we met our goal for that day we stopped, even if it was after just a few hours of work. There's nothing inherently wrong with this.
How does retro function in a team project? We would retro once a work day or once every few work days, just to get on the same page in terms of what we have achieved and what we can accomplish in the coming day/days.
In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations? To think of some examples, there were a few times when two of us would come up with an idea at basically the same time and whenever this happened we would both voice our ideas and reasoning and we'd either choose one or try our code both ways to figure out which works better. There was never really any disagreements because we voiced our reasoning. At other times, if we worked alone on code, if someone brought in code that raised concerns for someone else (might cause problems in the future, don't fully understand why the code is written the way it was), we were also open about that. Basically we were all open and up front and it never felt confrontational, because it was all for the betterment of the project.
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 can communicate feedback well and not in a critical way. It's not always easy, but this project reinforced the value of being honest and open in non-confrontational ways. In terms of how I could improve my feedback, I want to make sure any criticism I give is always presented in an open and friendly way. I think I am pretty good with this, but it can be easier or harder depending on the person or group dynamics. We had a great group dynamic but I just want to make sure I can carry on the same qualities from this group into all groups I work with in the future.