Sprint One Retrospective

The first sprint for my software development capstone has concluded. It's served as a good way for me to start immersing myself in the "real world", in other words having a way to practically apply what I have been learning throughout the second half of my CS undergrad. Up until now I have done virtually all of my coding projects alone, this class (besides my research team) is the first time I have had to consistently work with a group of people on a project of any kind for more than a week or so (basically, more than a single assignment). To quickly recap what every student in my capstone is collectively working on (I'm not actually sure if I explained this in my introduction blog post), we are working on the software for a food pantry. We are in charge of developing every aspect of it, from frontend elements like the UI, to the back-end processes. In particular, my team is in charge of front-end testing. We, over the semester, will be developing tests to verify the functionality of the site. My team has five people including myself, so a relatively small team, but a team nonetheless. 

Everyone in the capstone is largely in the same boat as me, in that nobody has much "real" experience working on a larger scale software project as an organization. As a result, we are all inexperienced and have been learning to work together throughout this first sprint. At the very start, no one had a defined role of any sort, and as a result, no one really wanted to take any initiative to "take the first step". I feel like everyone in my group is fairly introverted (including myself). Nonetheless, eventually we got going and found somewhat of a groove. Each week we have two meetings, through which we all share ideas with each other, and discuss what to do next based on what everyone provides. I have found myself as the groups "leader", though I am hesitant to call myself that because no one truly has any defined role, and direction is given mainly based on who feels like taking the initiative for that meeting (though, this part has generally been done by me). I think this style of teamwork has both is strengths and weaknesses. I think our biggest strength is that everyone has ample opportunity to "take the reigns" if they see fit. If someone has an idea for how the group should tackle a sprint backlog item, they are free to recommend that to the team, and the team will discuss it as a group, with no one having final authority on the decision. This promotes a healthy flow of ideas from everyone, and this shows as everyone up until this point has had large contributions to our progress. 

That being said, I think there is room for improvement, even if what we have so far has worked out. For instance, there are times where no one takes initiative for the meeting, maybe having a concretely defined leader would make sense then. I have tried dabbling in that idea a few times, though the first time I took charge, the next week one of the group members anonymously complained about not having a chance to provide input. I decided then that if I wanted to become the group leader, I would need to figure out a way to do so while still allowing for everyone to feel like they could provide input. Over the past few weeks going into and starting our second sprint, I have been trying to lean into that position of leadership more and more. I would like to find a way to promote that input more regardless, as I want to encourage everyone as a team to take more initiative, as this is, in my opinion, where we are lacking the most. 

I have been reading our assigned textbook that I talked about in a previous blog - "Apprenticeship patterns", written by Dave Hoover. Of all of the patterns, one that I feel applies to my progression as an individual has been "The White Belt", whose core idea is to adopt the mindset of a beginner, even if I already know some programming. I am picking this pattern as I feel like it could prove useful for my development if I implement this concept moving forward. Adopting some level of humility while working might prove useful if I want to be a better leader.

Comments

Popular posts from this blog

A quick look at front-end

A look at Refactoring