Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save ohnomalone/f8e57bc9862c9d3f7da35bba415713f8 to your computer and use it in GitHub Desktop.
Save ohnomalone/f8e57bc9862c9d3f7da35bba415713f8 to your computer and use it in GitHub Desktop.

Agile & Feedback Reflection Guidelines

  1. What have you learned about the use of agile vs. waterfall in software projects? With software, agile is a great way to proceed. This project was very much set up as a waterfall where we had a deliverable date for it to be used, and that was it. Having the ability to get users input while developing the software is invaluable. Even with empathy and understanding, a developer and user have different experiences and knowledge of the software they are interacting with. This project hasn't provided enough experience to say what I have learned with either process definitively.

  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.)? We did not use any tools besides the provided rubric. We had a repeater in our group who told us last time they spent too much time on this aspect and was one of the reasons they did not pass. His views of not using a project management approach ended up winning against the protest of others in the group.

  3. What role did you take on in the project? Our group faced challenges from day one. The role I took was voicing those challenges and concerns. This let to conversations with teachers and a miss on their part of setting expectations on a project that has repeaters and non-repeaters in it. Both people have different expectations that thus, a different approach. The difference in expectations breeds division and contempt, as a success for one, is a failure for another. We didn't want anyone to fail, but by sticking to that, we now hampered our ability to learn.

  4. What changes would you make to your approach in future team projects? I would have a teacher meet with all members of a project that have a combination of repeaters and non-repeaters to set the proper expectations.

  5. How does retro function in a team project? We did not do a retro for the project, but I would like to!

  6. In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations? A retro was not done.

  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? Sometimes it takes a lot of communication to breakthrough. I appreciate clear and open communication much more after working in a group where it didn't happen much. After clearing communication needs, having a group agreement of how we will work not listened to several times teaches you the real interest of others — at that point, just getting through the project seems to be the unspoken agreement.

@allisonreusinger
Copy link

Great details about agile -- even with Turing projects that have explicit deadlines, think about how you could take on pieces of agile to incorporate in future projects, such as project management tools, stand ups, etc. When participating in projects at Turing, you will be paired up with many students who are different from you, and the expectations that get set come from the group itself, which is why we stress using DTR. Also, we did do a retro in the PD session last Wednesday, so I'm curious how that went for your group since you mention that you didn't have one. If you run into issues implementing DTR or retros in the future, please let me know and I can help you strategize how you can help the group move to the norming phase.

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