Like every human being on the planet, I too have had challenging experiences with teamwork. As the Capstone course is entirely composed of a group project, I’d like to share some tools I’ve learned that have helped to mitigate the consequences of difficult team dynamics. My top three favorite tools are team standards, communication, and vulnerability.
I was taught team standards during my coursework at OSU. This is a written document created at the start of a group project. It contains a plan for the group including methods to help resolve conflict, mutually agreed upon before everyone starts tearing their hair out. For my Software Engineering II course, I participated in a group project with my good friend Ronny and another student, let’s call him Jay. When setting up the standards, I rather arbitrarily suggested we have a conflict resolution strategy that the majority rules. This one sentence in our standards document saved our proverbial bacon.
We were each given one problem to solve with the constraint that we weren’t allowed to use built-in methods or Python modules in our code. In addition, we had to create our own black box, white box, and random testing suites for each problem. I was responsible for reviewing Jay’s code when I found an issue with his algorithm. It was taking over 20 minutes to run 1,000 random inputs. The instructor stated he would be testing 10,000 inputs for each problem and each testing suite had to finish in less than a few hours time. In my code review I recommended that Jay optimize his algorithm so that we wouldn’t lose points but he stated that it couldn’t be done.
I reviewed the algorithm Jay wrote to calculate the month, day, and year given the number of seconds since Unix epoch. I realized that there was a simpler way to perform this calculation. Jay was iterating through each day, then incrementing month and year. It seemed simpler to me to reverse the algorithm. Start by checking if the current year (set to epoch 1970) is a leap year, if not, subtract 365 days from the remaining days. By decrementing a year at a time, it saved us 365 times through the loop. Jay refused to work on the optimized version so I refactored his code using this simpler approach. Jay had the most difficult algorithm to be sure, and I believed he was having trouble asking for help. Though it took several hours to fix, we went from running 1,000 test cases in 22 minutes to running 1,000 test cases in 2 seconds.
I brought the optimized code to my group and Jay stated that he didn’t want to use it. I knew it would surely get us all the 4.0 grades we wanted, whereas Jay’s code was an unknown. I tried to communicate this with Jay but he was adamantly against using the optimized code. My second teammate and I decided to accept my PR since the majority rules in our team standard. We received a 100% on the project and all got A’s in the course.
“Teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”
– Patrick Lencioni
Truthfully, I don’t understand why we had to fall back on a “majority rules” standard in this case. Teamwork is a difficult balance. Was I being pushy or domineering? Solely focused on optimized code to ensure my own end goal, an A in the course? Was Jay being prideful or lazy? Not willing to put forth the effort or accept help from his team to ensure everyone’s success?
I don’t think life is ever so black and white. There are plenty of shades of gray here. I just hope that I can do my best to follow our group standards, keep the lines of communication open, and stay humble throughout this Capstone course. Worst case scenario, I have another example for interviews to discuss how I, hopefully, mitigated conflict 🙂
