Once again, welcome back!

For this term in the game design course, the groups work using the Scrum framework. Therefore, this post will talk about my experiences with working with the Scrum framework.

Background

The big secret that we project managers don’t tell our groups is that we have no formal training in the Scrum framework. The previous term consisted of us learning the fundamentals of traditional project management (the opposite of working in an agile way). All in all we had 3 lectures that touched upon agile project methodologies. Learning that we would be leading groups using Scrum this term was therefore an intimidating proposition, since we simply were and still are not qualified for such an endeavour.

Naturally, one would expect that the project managers would study Scrum in parallel with working with Scrum. However, this is not the case. Instead we are taught a different framework  (DSDM), something that can only be applied to a certain degree to Scrum. Us project managers have lobbied to have the Scrum course changed to the second term (the one we are currently in), instead of having it in the third term.

To ease this unnecessarily awkward situation, the university has provided each group with a second year project manager, that acts as the Scrum master whenever he or she attends the group’s meetings. Us first year students are as a result not the Scrum master whenever they are present. Instead we act as observers, or “apprentice scrum masters”. We are instructed to look at what these more experienced individuals do and are encouraged to mimic their techniques and their way of working with the team. This practice proved to be useful, at least in my case. However, it is a risky approach since it relies heavily on the fact that the second year students are competent and possess adequate teaching skills.

With the help from the second year students and the internet, I managed to get a good enough understanding of how to use the framework, at least in theory. Still, it is always different when you read about a practice and when you actually practice it. Which is also the reason for the title of this post. Each week I tried different things, just to see what worked and what did not work. I then used that experience to slightly modifiy the way we would work for the upcoming weeks.

It might seem that I am talking about things that are not entirely relevant to this week’s topic. However,  I deemed it important enough to briefly cover, so that I can better explain my reasoning for decisions later on in this post.

The start of the project

The start of the project was extremely rough for the group. Out of 5 people in my group, I was the only one attending the lecture that would introduce the group to Scrum. In addition, the lecture was designed to help the students of the other minors get a basic understanding of the framework, since it had little to no new information for us project managers. The next lecture consisted of a surprise test, which had the purpose of making sure that the students did indeed understand how and why we use Scrum. Once again, I was the only one attending, so we as a group naturally failed the test.

My intentions are not to expose the members of my team or to complain about their low rate of attendance. The reason for bringing it up is to explain that the group had close to zero understanding of Scrum when we had our first sprint meetings. In addition, the  very first meeting was led by the second year student, and he also assumed that they understood the very fundamentals of the things he explained.

That turned out to not be the case, and I would later find myself in a position of having to explain the basics of Scrum every single week. There was an overall lack of interest in learning Scrum as well, which made my job very hard. It took a long time before everyone fully understood the value of the practices of the framework.

Daily-Stand up

The daily-stand up is perhaps the most important thing we do in Scrum. The purpose of the daily stand-up is to give a short update that answers three questions. The way the three questions are formulated differs, but the content is usually the same. The three questions are: “What did I do yesterday?, What will I do today? and “Is there something blocking me or hindering me from finishing my work on time?”.

Using this system, any problems will get highlighted early on in the sprint. As a result of this system, late-delivery of tasks is unacceptable.  This was something that was not clear to the members of the group. They did not understand that if there were any issues preventing the work from being delivered on time, they had to inform the rest of the group during the daily-stand up.

The problem stems from the fact that certain members did not see the value of doing things in accordance with the Scrum framework. Daily stand-up in particular was something that my group was resisting heavily. My role as the Scrum master is to make sure that they understand why we do things, in this particular way. It was therefore not helpful in the slightest that the university gave every minor completely different schedules.

The second I heard about the fact that it was mandatory that the daily-stand up meeting  was to be a physical meeting, I could not comprehend how something so fundamental as making sure that everyone had similar schedules was overlooked. Having one minor start at 9.00 and the other one at 14.00 makes it hard to justify having a 5 minute long physical meeting. The daily-stand up should also take place at the same time and at the same place every day.

The suggested solution by one of the teachers was to have the meeting at 8.45 every single day.  If the goal was to simulate a workplace, then this would make a lot of sense. Have the daily stand-up at 8.45, then everyone starts working at 9.00. This is the ideal, optimal situation, but not something that is feasible in our case. Instead it would be something like – meet at 8.45, 2 people head to class at 9.00 and the rest head home since their class is starting 5 hours later.

Even though I thought that the scheduling and the proposed “solution” were awful, I never complained openly to my group about it. My philosophy is that I will try everything that is suggested either by the school or the framework itself, before I decide which way of doing a particular practice is optimal. It is important that you as the leader keep a positive attitude and that you do not let your team know how you truly feel (if it does not help the project). In other words, I try to keep a professional, positive relation with my team. Failing to do so would cause negativity to spread like a disease.

I am also very agile in my way of working, and like I stated earlier in the blog, I do not know the best practices yet. At the same time, my team was practically begging me to have the daily stand-up meetings digitally. I considered their idea but felt that I needed more data before I could make a decision. So, I went and talked to some second year students and asked if they had tried having the daily stand-up digitally, and how that had worked. The reponse I got was basically “It has to be physical, or you are a sloppy project manager”. That did not sound very agile to me, so I was motivated to try it out, just see how it would feel like. My team really wanted it to be done through Discord, which is the software we use to communicate, so we had a vote, and we decided to try it out.

For the first week or so, it worked excellently. However, as the days went by, people would forget to update or not do it for several days in a row. As a result, I had to start reminding them that they had to write a small update, every day (something I thought was very little to ask for). In the end, I felt that it was not worth the hassle and reverted back to meeting physically. While in theory the idea is good, it requires discipline and trust.

Sprint planning & review

For the first two weeks we had no programmer in our group. She was abroad, which made it incredibly hard for me to conduct the first sprint plannning sessions properly. Not only was she missing, but another person was also absent for medical reasons. My skills have defintiely evolved as this project has progressed, but at the time when I was having sprint planning meetings with only two other people attending, it really was very difficult to get value out of the meeting.

It was not until the third week that we finally had a full group for the first time since the term started. It was also around this time that our second year student lead a sprint plan and review  session with us. I learnt a ton from him and am really thankful for his expertise. He also clarified and said many things that I had also said previously to the group. It was definitely a confidence boost for myself, since I was unsure if I was doing things properly at the time. After this particular meeting my technique improved greatly and my sprint plannning meetings have become very efficient (in terms of deciding the right tasks).

Sprint reviews have been a bit of a nightmare. I talked about this in detail in my previous blog post, but I will very briefly go through it again. We had massive issues with things not getting delivered on time. I would ask to see progress and get shown next to nothing. This relates back to the lack of knowledge that my group had of Scrum. In their minds it was perfectly fine to deliver late without letting the group know, (during daily-stand up) that they were having problems. We still have this issue in the group, even though it has greatly improved, after we incorporated certain principles from the DSDM-framework.

All in all, we are finally working in a Scrum way. It took several weeks, but we are finally doing things properly. I could go on and on about issues that have since been resolved (people writing in random tasks in the sprint plan, that do not exist in the backlog, for example), but everything has not been negative!

Other thoughts

I think much of the issues we experienced relate back to a lack of knowledge of what Scrum really is. I learnt a lot by doing things practically, instead of just reading about it. However,  I still find it strange how we were not taught about Scrum in detail before we were asked to practice it. If I compare how I did things in the first weeks compared to now, it is all very different. At the same time, I feel like I was dealt a really rough hand, since it was hard to decide sprint goals when you have nobody who can code present at the meeting. Her being on an 8 hour time difference did not help either. In the future. if such a situation reoccurs,  I would most likely have the meeting at 16-17 (roughly 8 am for her), and bring her on digitally. It was in other words not a situation that could not be resolved, I just lacked the experience and knowledge of what to do in such a situation.

Now that people understand Scrum, and we have the additions of certain principles from the DSDM framework for additional structure, I feel like everyone finally finds our way of working optimal or at least good enough that they wont question it. Daily-stand up is now physical again, people timebox their individual tasks and we have clear  well-defined sprint goals each week.

I also want to apologize in advance if this post had a very negative tone, but we have had tons of issues, and I certainly left out a lot of details that would make things seem even worse. My team is not bad by any means, they just did not understand Scrum and some of them have other real life problems that are distracting them from working properly. It is all natural, but the post is also the harsh truth of the situation. I did not want to sugar-coat things, while maintaining honesty and not making it seem like I have done a spectacular job with this group.

Thank you for your time!

About Michael Degirmen

2017 Project Management

View all posts by Michael Degirmen →