This sprint, I handled the Gitpod Dev Environment implementation for the Reporting System, specifically for the Reporting Integration, Reporting Backend and Reporting API repositories. I also acted as the scrum master for the team, handling most of the logistics and communication with the product manager.
Gitpod Dev Environments: Import extensions via the .gitpod.yml file, set workspace settings via the .vscode settings.json file.
In terms of what went well, we did complete most of the issue weight (75% of the weight assigned for the sprint was dealt with). Speaking with my team members, we agreed that the meetings were productive and efficient, and we didn’t waste time on any of the meetings we had. I made it a point to not have meetings that could have been done over a short text conversation, and it seems to have paid off. We also agreed that the communication that did occur was quality communication.
While we completed most of the work for this sprint, there was still 25% of the weight left. This was entirely comprised of the Reporting System Deployment issues where we had to write docker-compose files to set up MongoDB local volumes. In talking with the team, we thought that the weight didn’t reflect the difficulty of the task. In retrospect, looking at the Deployment epic again I can see that there was a lot of confusion, not only because of having to read through documentation for Docker, but also because the initial task that was to be done before the implementation through docker-compose files (the actual mounting of local volumes from MongoDB) was not accomplished by another team, and was even removed from their sprint. This was excacerbated by the approach we took, where each one of us worked on issues individually without much assistance from other group members. This changed towards the end when two team members worked on the deployment together, but by then it was still ineffective, especially considering the uneven distribution of issues. It seemed like the weight of issues did make sense in a vacuum, but considering that I did all of the Gitpod Dev Environment issues for example, it was obviously very quick to complete 4 weight when the first 2 weight was done, because it’s an application of what I just did.
Another consideration: I think having one person (me as the scrum master) deal with a lot of the issue-creating and handling GitLab logistics was efficient, it didn’t lend itself to the most clear working environment for my team members that weren’t very well acquianted with the workflow. Details were located in epics rather than easily accessed directly in the issue that was assigned, and it made it more difficult to see what you were actually working on. In addition, it made it seem as though I did all of the work in the activity log when in reality it was a cooperative process, and the byproduct is that I end up with all of the credit as well.
For next sprint, we should better assist each other as necessary on issues when complications arise. We should assign weights more accurately based on our experience on the last sprint, and allow all team members to share responsibilities on GitLab, both for learning and to better tell what’s going on. As an individual, I should be more proactive as scrum master to really address problems as soon as they arise, rather than leaving everyone to their own devices as long as they check in. With these adjustments, I think our team will be able to perform much better in the next sprint.
V's CompSCi Blog 