⚠️This is not the right place to learn about what Scrum is. This only covers my experience as a Scrum Master for a small group.

One key thing to note in this project is the overlap in roles; our product owner was also one of the developers, which made the project run smoothly. Due to them being able to closely follow the progress and this definitely helps with communication.

Leading Agile

At the start of the project, the question arose of who wanted to be the Scrum Master.
I had some prior experience with Agile development, which gave me confidence in my ability to lead the team through the process. I also felt confident in my ability to gauge how much we could accomplish within our tight nine-week timeline.

People often say that projects take at least twice as long as estimated, but I believe that using Agile principles can help mitigate this issue to some extent. There may still be unforeseen challenges that arise, but Agile can help us adapt to them more efficiently.

Due to my technical background, I feel like my contribution helped estimate the time it takes to develop certain functionalities that the Product owners wanted. This helped us identify tasks that were not a priority and could be cut in order to stay on track.
As a result, we only ended up discarding a few tasks that my product owner described as “just shower thoughts.”

Daily Scrum

We started every morning with a quick scrum session where I questioned if anyone was facing any challenges and inquired about their plans for the day. I recorded these down into my notes to have something to fallback on if there was something I needed to address another day.

These daily scrums were extremely useful as they allowed us to anticipate upcoming deadlines, such as presentations that someone may have forgotten. Additionally, they helped us stay organized and on track during the development process.

Addressing Issues

One of the reasons for our success was due to our group maintaining consistent, effective communication. During the first sprint, we identified a major issue where some of the tasks on our Kanban were too large. We quickly addressed this concern after our retrospective and decided to split the tasks into smaller ones so that we could begin the next week with a clean board.

Another factor that contributed to the success of our project was the fact that everyone on the team had a clear understanding of the scrum framework. This allowed us to seamlessly integrate the principles and practices of scrum into our work process, without the need for any additional explanations or clarification. It simply became a natural and intuitive way for us to approach the tasks at hand.

DoD (Definition of Done)

To better manage bug issues, we implemented a pipeline on our Kanban that would send tasks marked as “done” to a separate Kanban for testing. Before a task reached this stage, we ensured that all acceptance criteria related to the wanted features were met.
However, due to time constraints and the need for everyone to prioritize development, we were unable to fully utilize this system and ended up having all team members take on testing responsibilities leaving the other QA Kanban unused.

Summary

I used my previous experience with agile development to lead the team through the process. We utilized daily scrums to stay organized and anticipate deadlines, and communicated effectively to address any issues that arose.
To manage bug issues, we implemented a Definition of Done process, but due to time constraints, all of us ended up taking on testing responsibilities as well.

I believe that using agile practices helped us complete the project within the tight timeline, since our team had a strong understanding of the scrum framework, allowing us to smoothly integrate it into our work process.

Our team’s success was also due to effective communication and a shared goal for the product, which allowed both programmers and artists to complete their tasks efficiently. Our close proximity in the same office allowed for any questions or concerns to be promptly addressed, and our positive teamwork and communication was noticed by other groups in the same facility, with one group’s Scrum Master even stating that we had the best communication of all the groups. Which I would understand more as having the best group spirit.

The picture shows the final state of our Zenhub which we used for task tracking.

The hidden TRASH label represents the “icebox,” which is a place to store tasks that were added during the development process but were not given priority due to time constraints, such as a lack of time to complete a spike* or for implementation and testing.

The jump in Closed tasks around 1st of December was due to us doing a lot of testing before creating a build for the final demo day.
Since we stopped following the QA pipeline during this time, the Closed label represents the real equivalent of the Done status in Scrum in this picture.

*A short investigation or experiment to explore a problem or potential solution in order to gain more information.