- What have you learned about the use of agile vs. waterfall in software projects?
- - In my previous job I worked on an Agile team, and began learning the processes through that. Agile really allowed us to have shorter sprints, releasing our product to awaiting customers in batches and getting feedback directly from them and our customer service team in real time. It was new to me, but it was fascinating to see the scope of the project I was a part of change every week, or even every day. I've learned through both our talk with Jeff and Meetups that I have been to how Waterfall is fine for some situations (government contracts, infrastructurally intense projects, etc), Agile is the way to go in almost every other situation.
- 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 started the project with a Trello board, and made some cards at the beginning. We tried our hand at writing user stories, but found that we already had all of our user stories written out in the Project spec sheet. I thought it was good practice, but we got a lot more work done by just writing tests, and letting them dictate our project path. I was taught by an Agile Master that every minute spent writing Spec is a minute spent not writing tests.
- What role did you take on in the project?
- - Fortunately, we all worked on the project side by side for 95% of the project. In our initial DTR, I said I would help with Github, and I tried to drive that as much as I could. Making good commits and PR messages and all that. In the end, I ended up focusing on a lot of the big picture framework elements of our project, things like our Mock/Stub setup in our tests, how our Objects should interact, etc. I had a good time drawing all over the whiteboard to visualize our project.
- What changes would you make to your approach in future team projects?
- - I would have taken a harder line in the Github approach. While we were all sitting together and writing the code together, our commits and PRs were lacking in message/brevity. It was difficult for our team to get behind writing comments on code that we literally just wrote together. I also kind of failed in my DTR mission of teaching my team mates good Git practices because of that.
- How does retro function in a team project?
- - It's a good time to look back through our code and see where we learned, and see where we could have done better. We had a major refactor session the day it was due, which really allowed us to drill down into each of the functionalities we had worked on over the week, some things we had forgotten about and realize there is always room for improvement. I think it was really positive to fully process the magnitude of what we had done with the limited time we had.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
- - We really spent the last two days of our project going over in our heads what we thought we might want to change, or what we could have done differently. This allowed us to have a flowing conversation in our retro, and also come to the points that while we could certainly change some things, we didn't have the time. We had a functioning product, and we pushed it out. Our retro was a learning experience in the fact that sometimes that happens and not everything can go smoothly, and what to avoid in the future.
- 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 working side by side for 10 days really taught me how to hold back and let somebody work through their entire idea when needed. I had a lot of ideas, and I found it was a lot more productive for me to write down on the whiteboard what I was thinking to both get my ideas out into a more palatable manner and to not talk over someone else. I could think through what I was trying to say instead of just blurting out my random brain words. It also allowed others to work through their preferred method of brainstorming and me sometimes to see that my way of going about something was not the most efficient.