Q: What have you learned about the use of agile vs. waterfall in software projects?
A: Agile's approach of several small cycles of the the steps from design to deployment, which waterfall does in large chunks, left an apparency of practicality and flexibility.
A: 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.)?
Q: In our group project, Cross-Check, we organized tasks through use of Waffle.io, Slack direct-messaging and in face-to-face conversation, when able. We formed a standard of frequent progress checks and updates, giving honest feedback to each other. In the span of this project, we did have instances of work not being completed to the standards we outlined in our DTR. In this, we discussed how to reassign the workload to complete the project.
Q: What role did you take on in the project?
A: In this project, I assumed a role of a project manager. My goal was not to dictate what our individual group members accomplished, rather to keep the project on track. In this I frequently asked questions. This was checking in on progress of the other members of the group and inquiring about strategies to implement features. In this it was important to me to give updates on my own progress and check for understanding of features I had built.
Q: What changes would you make to your approach in future team projects?
A: In the future I would like to further hone skills of feedback as well as planning. In feedback while we addressed the issues that arose, in retrospect there were situations I intend to ask more questions. In particular when needing to restructure the workload after our goals were not met, in the future I would like to question more the cause of the shortcoming. In planning I aim to establish a design which throughly breaks down the problem to be solved, before starting.
Q: How does retro function in a team project?
A: In our group it served as a time to reassess our design structure. This design being both our implementation of project features in programming as well as group relationships. Neither was more important than the other in my view, both were crucial in our ability to proceed and develop our strategy to do so with each other.
Q: In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
A: In feedback I am not one to shy away from critical analysis. That being said, a critical view doesn't exclude virtues. I engaged with my group with feedback to affirm, counsel and evalution. Evalution came from the standards we ourselves set as a group and our lessons from instructors. This offered a foundation to either affirm or counsel depending on the situation.
Q: 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?
A: I have focused more on my ability to listen than to talk, resulting in a useful and complete toolset to address feedback. However, this has left we with less experience in detailing this perspective to others. While broad strokes to illustrate feedback come with relative ease, I am striving to improve communication on smaller observations which addressing could offer greater clarity and insight into the feedback I am already able to give.
I appreciate your reflections here and thoughts on how to continue to improve!