The Abstract Class – Sprint Retrospective #1
Our team, named The Abstract Class, reached the end of its first Agile Sprint today and this is my retrospective. This week, I learned about building and running my first Angular application cloned from a shared repository. This was part of a larger group of accounts and applications that had to be processed mentally. There is Trello, Jira, CatME, Slack Channels, and GitHub groups. As a team and individually, we each had to navigate the many new interfaces and learn the intended uses for these new tools. I feel out team effectively grasp and started using the tools as intended.
The most technical feat our entire team accomplished this week was cloning of the AMPATH application and connecting to our test server. We ran into a situation where we attempted to build the application with ng serve and not npm start. This caused errors. Once we realized our mistake, entering the correct command got us up and running.
Our team handled AMPATH application ladda build errors using the class Slack channel. We shared screenshots, log files, and advice when one of us was having trouble. We accomplished getting a teammate up and running strictly through this Slack channel conversation. This provided other class members the ability to view our conversation and avoid the same issues, potentially. We could continue to publicly resolve future issues in hopes that this inclusive feedback will help resolve issues quicker.
Our team worked very well together on this sprint. We used Slack appropriately and resolved issues on that platform efficiently. We could have used Trello more effectively during the sprint, as we were moving the boards around during the end of spring class. Our stand-ups were a little spotty in the beginning but we, as a team, finished strong.
We created our GitHub team group and began discussion on the best way to manage changes and pull requests. We are unsure of which of the following approaches is best:
Create individual branches for each developer on the group’s fork of the Master branch. We would create an additional branch called merge_changes which would act as the buffer between our branch changes and the Master branch. Pull requests would be merged as a group.
Create individual forks for the group’s fork of the Master. Then each individual form would create a branch on their fork. Merge requests would still be handled by anyone who did not create the pull request.
We have yet to determine which of these is best. Our next Sprint planning meeting will have to include discussion on this point.
We also discussed the best way to handle our group’s Trello board. During this spring, most of the tasks were required to be done by each member. This caused some confusion on the boards. We were not sure of the best method to have some of us done a particular task while other were not. There were some suggestions about checkboxes, multiple cards, or color coding. In the end, we determine that the future tasks should be more individualized. This makes the requirement for us to find a better way less important.
Here is a list of things I would recommend for a better and more productive sprint:
Log into Slack everyday of your sprint. Your teammates may have left you messages.
Get Slack on your mobile device. It is a seamless transition between the desktop and mobile versions.
Ask for help. Your teammates are usually more than willing to give a hand.
Looking towards the next sprint, I expect to get much more technical and in-depth. I will also be looking for opportunities to find retrospective material to include.