One More Sprint (CS-448 Sprint Retrospective Blog 3)

INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

  • Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
  • Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

  • To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
  • As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

  • I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
  • In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

  • Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
  • In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.

LINKS TO GITLAB ACTIVITY:

Published by Mike Morley (mpekim)

Current student at WSU. Knowledgeable of C/C++, Java and Python. Always interested in learning the basics of as many languages as possible.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: