Skip to content

Instantly share code, notes, and snippets.

@mronauli
Last active January 10, 2020 15:25
Show Gist options
  • Save mronauli/55a7a4ed162be2354032fc9e6810caa1 to your computer and use it in GitHub Desktop.
Save mronauli/55a7a4ed162be2354032fc9e6810caa1 to your computer and use it in GitHub Desktop.
Agile Reflection
  1. I have learned that implementing an agile workflow is more efficient than a waterfall workflow in terms of saving time. By this, I mean we broke out the requirements, design, implementation, and quality assurance steps each team we would complete an iteration instead of going through the requirements, design, implementation, and Q&A process once at the start of our project. By doing this, we were able to debrief with each other, refactor our code and receive feedback from our instructors along the way. The worse case scenario had we approached our project using waterfall workflow is that our project could have been implemented using logic that does not make the most sense.

  2. Our group used Trello as a project manager. We held each other accountable by talking through the code that we wrote individually the next day. While working on iteration 3 and 4, we stayed at Turing to work on the methods assigned to each individual and rubber ducked each other if we were in an unproductive struggle.

  3. The role I took in the project was diffusor. I tried to make sure that my group members voices were heard when they had an idea. Also, if there some kind of conflict, I did my best to keep our group working together.

  4. I don't think our group communicated as well as we could with each other in terms of deadlines and where we wanted to be the next day in terms of the project. I feel we were disorganized in terms of facilitating our time. In the future, I will get better about communicating that I would like a more concrete course of action in order to feel more confident with our project.

  5. Retro is an integral function in a team project. It allows us to map out our ideas and collaborate with each other. In addition, it lets us set realistic expectations in terms of our project and where we we want to be each day.

  6. I gave positive feedback by acknowledging my team members and told them how awesome I thought it was when they would make our code more efficent by cutting down the spec harness run time and if one of them would refactor a method and make it shorter.

  7. I would say I generally communicate positive feedback well. However, I realize that I did not step up as much as I wanted in terms of giving constructive, positive, actionable feedback. This experience has affected my communication skills by increasing my self awareness. Next time, if I feel constructive feedback should be made, I will communicate that in a positive and actionable way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment