Revisiting Scrum

Hello! Because of the circumstances surrounding the group during the last time I wrote about Scrum, I will write a new post to describe our work in more detail. For example, I went into detail about why we had problems preventing us from working with Scrum, instead of focusing on the week where we actually managed to work with Scrum. This blog post will therefore continue from where my last post stopped, up till the end of the project.

Working with Scrum has been a good and efficient way of creating structure and to have a more transparent way of tracking progress and what needs to be done. From day one we had an extensive product backlog that really helped us keep a high level plan of the project and keeping it within scope. Throughout the project we had some issues with tasks not being added to the backlog and with tasks magically appearing in the sprint plan/review tabs, but this was something I tried to keep track of to the best of my ability.

For the project I was the Scrum Master, Product Owner and also lead sound for the team. I can in hindsight say that the role of product owner should definitely have been my designer’s. She often had little to do and having her do the job would have been very efficient, in terms of utilizing all team members. The job includes things like prioritizing items in the backlog and developing user stories for them. Nobody offered to take the role of product owner, so I just assumed that I was the only one who was somewhat trained to do it (turned out to not be the case, but it is very hard to know what the other minors are doing).

We had problems with the daily scrum and my biggest regret was that we just completely stopped having them for 1 week towards the end. People were super stressed out and did not want to go to school just to have the meetings, and I tried to be agile and comply with their wishes. What happened was that towards the end we had certain tasks that apparently were very difficult to finish, and I had no way of knowing that a certain person was struggling. The person did not reach out to me personally and I was informed of the issues by a person outside of the team. This would definitely have been brought up during a daily scrum. In addition, as the product owner, I should have cut some of the last minute features (even though the team as a whole deemed them feasible).

Our sprint planning sessions were very efficient and were sped up thanks to our extensive backlog. At the start of the project people often forgot to bring computers to these meetings, which slowed them down a lot, but during these final weeks everyone brought their computers, which helped the process tremendously. For the first weeks, I had done a mistake of not informing them that they had to pick 20 hours worth of tasks, which made it so that (looking back) we had a sprint where one person only had 4 hours worth of tasks assigned to them (woops).

I also completely forgot to have any kind of sprint retrospective. I was so focused on learning how to create sound effects and making music for the game, that I kind of forgot some of my other responsibilities. This was of course a result of a lack of experience and training, but I really believe that they are super important to have.

Finally, I can say that we failed to work in a cohesive way, but still maintained efficiency thanks to the framework. Normally everyone is supposed to work on the same features, but since we had bottlenecks within the team, it resulted in people working on different features. This caused problems in terms of creating incremental value and many things never made it into the game despite having, for example, the art finished for it.

Looking back at the project, I learned so much in terms of how to manage a team using the Scrum framework. I made many mistakes, but I never stopped trying to develop myself and my techniques. I am somewhat pleased with my performance but will always strive to become better.

Thank you for reading!

 

 

About Michael Degirmen

2017 Project Management