I wrote an essay titled “Building the Golden State Warriors” a semester ago. It was about what I thought was most important to working in a software development project with a team. It covered leadership, communication between team members, and other steps I thought one should take towards successful development of a project. This time I want to stress over the consequences of poor leadership, poor communication, and anything else that could happen during a team project.
But some context before moving forward - I had the wonderful opportunity to be able to work on a project for an actual client this past semester. The goal was to create a sort of VolunteerMatch competitor platform, and after an initial meeting with the client we were provided a ‘wishlist’ of features she’d like to see implemented on this application. The class was initially split into five groups of eight students, and while each group worked independently from each other we effectively worked on the same project building ‘prototype’ applications. My team, after quickly getting to know each other, went to work by setting up the project using a template and creating some user stories to address the type of features we’d expect a user to want from this application. We also set up a group Discord to efficiently communicate messages with the group or individuals.
From the get-go, I understood that some team members might not be entirely committed to working on the project. There were a few concerns I collected early on from within the group: We were working on an actual project for a real person without monetary pay, some members were on their last semester before graduation, and some felt overwhelmed with the potential task list given to us. My intentions for this class were simply to gain more experience on software engineering using what I learned last semester; this class was an opportunity to continue building upon a skill I wanted to develop. The issue I encountered immediately with the team setting was differing levels of motivation. Over the past few months, participation in the project and group discussion would sharply decrease. This is understandable as all of us are students with our own lives. In fact, two members of the team dropped out early on for personal matters. But the combination of a weak desire to work on the project and heavy workload means productivity won’t be high.
Over spring break, I decided to use most of it working on the project. I felt that the application’s current state at the time was not up to my personal standards. At the time, we simply had a bunch of unused collections, unused roles, and pages with limited connectivity. Even the landing page was something I could barely tolerate. The week actually proved to be very productive, and I was able to accomplish most of what I set out to do, even introducing some new issues as opportunities for some of my members to be able to contribute to. But something surprising happened - No work was done on the project for a solid two weeks besides the one night prior to the next milestone meeting. Why was this? I theorize that I did so much work that my teammates felt it was sufficient enough to submit as the milestone additions. And after that, even less work was done on the project as final exams came closer and closer. At that point, it was clear to me this team only existed in name alone.
My teammates clearly had different goals in mind when taking this class. I felt that most simply wanted to check off a box. I also don’t think that many were interested in the idea of making the type of application we were trying to build. In terms of working with a team, it’s important that the team sets clear expectations early on.
We decided at the start of the semester to meet once or twice a week to discuss the project. The truth is, we never met once as a group. I was actually a little confused early on about if we were going to meet at all. Each week I post a general question to the group Discord asking what the plan was. In most cases I actually got no response back. I’d figure out early on that everyone would assemble or be working on something the night prior to a milestone meeting. There are a couple of issues I’ll highlight that arise from this:
To minimize this issue, I often tried to assign issues to specific members so that I was aware of what type of code they were expected to push to the project. I also suggested using pull requests to have members review each other’s work before merging so that we could catch duplicate files.
Our team lacked leadership. While I had to take initiative to ensure that certain aspects of the project were completed on time, there’s more to leadership than initiative. I felt that at many moments I needed to be more assertive with certain team members. The approach I took all semester involved direct messages to avoid putting a spotlight on people, but I never felt that this accomplished anything. Two members, in particular, didn’t contribute much to the project, and to this day I still don’t know why. I’ve approached both of them separately to understand what they’re working on, and how their progress on their work is. One would tell me that work is going fine, but I never saw any commits from that individual. The other told me that they didn’t know how to use GitHub, and therefore didn’t know how to push their commits to the project. I attempted to help them out by demonstrating how to do it, but the code pushed onto the project immediately resulted in the application no longer working thus I reversed the commit, and asked them to work on it again. Because of that experience I pushed the team to use pull requests so that other members can review work prior to any merging.
But the area I feel -I know- I could have improved on was on helping some of my teammates. I usually answer every question asked in the group Discord regarding deadlines, application components and additions, or how to implement something. I thought I was fairly active as a group memeber, but I never put much effort trying to figure out why some members never contributed much when we needed to submit or present work. Perhaps there was something they couldn’t understand, but were too afraid to ask for help. At this point, I’ll never know, but I do believe it’s important to iron out those types of details as early as possible.
I’ll say this project didn’t pan out the way I thought it would coming into this semester. But it’s still a very valuable experience, albeit really stressful. It’s reality that I’ll likely work with more people who don’t feel like doing much work, or with people who won’t express their concerns about their work with me, or even people who just don’t care about the project we’re teamed up on. I already work a 30-hour week job, so I have experience with bad coworkers or teammates. I just need to frame these experiences in such a way that I can learn from them. This class felt more like an exercise in team management than in software engineering - Perhaps that’s the point of this class. I’ll certainly never forget this experience as I move closer to graduation.