- What have you learned about the use of agile vs. waterfall in software projects?
Both agile and waterfall processes have value depending on the nature of the project. Agile allows for more progress in less time because it is working through piece by piece, getting feedback, applying that feedback, and moving forward. This means you already have an idea of what the users will be experiencing and needing from the application. Waterfall takes a larger chunk of time working toward the end product without getting or implementing feedback in between. This means that during the process you're only guessing what the users will be experiencing andneeding from the application.
- 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.)?
My group and I tried to use GitHub Projects as a project management tool but struggled to fully implement it into our workflow as more than an afterthought. We did use it as a place to log questions we had or issues we needed to come back to but in terms of the agile process, we used the rubric's step-by-step iterations more than the project management board. Being able to use the simple highlighter on the rubric was an easier way to manage our workflow than the cards on GitHub Pages. The bulk of our work was done all together at Turing but we did use the project management board well when we were splitting off at the end of each day so that we had it documented what each of us was going to work on before meeting up again. We met each morning for a stand-up and did a mini-retro before parting ways each evening to hold each other accountable.
- What role did you take on in the project?
I fell into the role of relationship builder during our project in terms of making sure we were checking in with how we were all feeling and taking poms regularly. Each team member was committed to communication and the value of checking in often so my role mostly included reminding us to do that regularly. Looking back, I also fell in the middle of my two teammates in terms of how quickly we could work through JS functionality. This, and my nature, led me to try to bridge that gap and make sure Karen wasn't feeling like she was falling behind and that John wasn't feeling frustrated if our pace was slower than his would have been. We DTRd our goals for the project and I made a daily conscious effort to make space for Karen to meet hers by inviting her to walk through code aloud and drive in situations where she said she was feeling lost since its hard to follow along without being the driver sometimes.
- What changes would you make to your approach in future team projects?
The first two days I was so focused on making sure Karen felt good about her understanding that I felt pretty emotionally drained. It came from a place of knowing how bad it feels to be lost and not know how to catch up, and not wanting anyone on our team to feel that way, but it was ineffective. After the second day when I was really drained, I realized I needed to be a side supporter of her processes, not a driver. After managing a team for the last several years, that was a transition I had to be intentional about. But we talked about it and both agreed it would be better for each of us. She still knew that I was all-in to help her not feel lost in any way I could. But we both knew that I would hang back and let her speak up when she needed/wanted something. It was great to be able to have open communication about it. I hope that it make Karen feel more compelled to speak up for her own needs which she did a great job of throughout. I still did pulse checks and invitations asking if she wanted to drive/speak it aloud/psuedocode, etc but it was much less energy intense than before. It also opened some space for John and I to realize that she was getting it more than she gave herself credit for. We were able to tell her that she explained it very well and hopefully started to help her redefine her expectations. In the future, I will be supportive but always remember to let each person own their own success/process/learning.
- How does retro function in a team project?
A retro is a chance to look back at the work that was just completed and the processes that were used to complete it and to make adjustments for the future. Its an opportunity to speak openly about challenges so that they can be resolved rather than escalating.
- In your team retro, how did you engage in the feedback process? What principles of feedback did you use in these conversations?
We did a stand up every morning and a mini-retro every evening. I asked for feedback about how everyone was feeling and if any of us had anything crunchy nagging at us that we could work out as a group. I stayed really focused on sharing wins and making space/soliciting feedback from my teammates since I'm more outspoken by nature. I committed to making sure we reveiwed our DTR every few days as part of the retros. We used a fist-to-5 process to see how we were each feeling about each bullet point of our DTR. Our stand-ups and retros were overwhelmingly positive because we were intentional about communication and pulse checks throughout the day each day.
- 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 would describe my ability to communicate feedback as strong as a result of my past experience as a front office manager. I appreciate feedback which helps me feel comfortable providing kind, specific and actionable feedback to others in hopes that they will also appreciate it. I was lucky to have professional development opportunities geared towards this in my past jobs. This experience has helped me start to understand how to best utilize those same skills in this new environment. Continuing to understand that nuance is what I want to continue to improve on. Giving coaching feedback was something I was very strong at as a manager; it was something important to me because it was part of my committment to making an impact on my team. However, I'm not anyone's coach, manager or mentor here. I'm their peer and partner. Its a significant difference that I want to continue to learn to navigate gracefully.
These are great reflections; I appreciate how you've articulated your process, especially in how you struck a balance on how to be a supportive partner and how to do what was best for you, as well as lessons learned to take into your next group project. These kinds of reflections will also help you continue to prepare for interviews, nice work here!