The following is an accurate representation of what my typical day/week looks like from the perspective of a Scrum Master. Names, titles, and project details have been altered to preserve the anonymity of my fellow coworkers and to avoid sharing any sensitive company data. Rather than highlight every single repetitive meeting, I sampled some of the most important meetings from the week.
Monday: 9:30am, Bug Triage Meeting
During the early months of my tenure at the software company I work for, we were struggling to handle the incoming flux of new bugs and defects. Bugs and defects are found by everyone from developers, SE’s, customers, and anyone else who uses our product on a regular basis. In order to improve our visibility on the critical bugs that recently emerged, we instituted this triage meeting every morning in order to discuss and prioritize the latest most pressing bugs and defects. We have members from every squad attend in order to provide their own insight and offer advice on who should take on the work and possibly how to resolve the issues. I attend this meeting every morning so that I have prior knowledge of when new work will be impacting my team. Depending on our current backlog, I will discuss the possible work with our Product Owner and determine the best course of action so that our team does not take on work that might negatively affect their current sprint work.
During this particular meeting, a critical bug was reported by one of our biggest clients. There seemed to be a memory issue with one of their appliances. For unexpected reasons, their RAM began thrashing and would spike to the point that their specific software release became unusable. After doing some initial discussion, the bug was assigned to the platform team because of the possibility that a recent change could have caused something unexpected to occur. Due the criticality of the bug and the clout of the customer, we recognized the urgency to take on the bug so that we could begin working on it.
Monday: 10:45am, Platform Team Stand-up Meeting
After attending the bug triage meeting, I knew there was going to be a lot of discussion concerning the new bug that was just assigned to the team. We went through our typical routine and had each team member update the rest of the team on their status, which involves, what they worked on yesterday, what they are working on today, and whether they have any blockers that may be hindering their work. We have a working agreement that we will “timebox” these meetings to 15 minutes so that we don’t get stuck in the weeds with details on specific topics. After the allotted 15 minutes, we allowed the extraneous stakeholders attending the meeting to leave while the rest of the team discussed the best plan of action on how to research the bug, who the bug was going to be specifically assigned to, and how they were going to go about solving the problem. In this situation, we had a developer who had finished his sprint work and had the necessary bandwidth to begin working on the bug. Throughout these types of meetings, I make an emphasis to always facilitate the discussion so that the team can gain the most value from what’s being talked about, while at the same time, minimizing the amount of time that is taken up so that the developers can get back to their daily work. It is also necessary to make sure that I ask the tough questions and confirm that the bug assignee has the right information and vision in order to tackle the task head on.
Monday: 11:30am, Feature Work Meeting
One of the fantastic disciplines that our department has is always planning for features many weeks and months in advance. We do this so that when we get to the actual feature work, the stories are well defined and all the risks, assumptions, and goals are clear and understood. This specific meeting regarded a new feature that was promised to a huge client of ours. We had been having concerns about the authentication and authorization aspect of this feature. Due to the necessity of maintaining the highest security standards in our product, we wanted to make sure that nothing was being forgotten with the implementation. We brought in a security advocate to our meeting to help answer questions and offer advice on how to bake the proper security measures into the new feature. The byproduct of this meeting was a lot of diagrams on the white board, important notes about the implementation and a strategy on how to attack this portion of the feature.
Monday 1:00pm, Customer Call Meeting
Another one of the standard initiatives that our company promotes is having phone calls and videoconference meetings with our clients so that we have the opportunity to watch them use our product and see where their pain points are. This allows us a rare glimpse to see how our customers are truly using our software. During this particular meeting, we were given access to their beta lab so that we could dig around and figure out why a specific beta build was causing problems. I had coordinated with a professional service representative, our product owner and one of our developers beforehand so that we were all informed on the issue and what we needed to be looking for during the call. The preparation paid off and the investigation went smoothly. We were able to immediately solve the client’s problem and found a few issues that could be fixed in future releases. By preemptively going straight to the customer, we are able to save a lot of time and resources and make our customer very happy in the end.
Monday 2:15pm, Architect Team Stand-up Meeting
The other team that I serve focuses on the architecture of our software. They are responsible for creating the vision for future initiatives and helping out other teams when they have questions about how to solve a specific problem. During this stand-up, we talked about the challenges associated with the work they are currently doing to create a new micro-service. This team also has a few remote team members, so I make sure that everyone has been communicating with each other and that the work is staying on track. They are a very proficient team and have many years of experience, but I always find it beneficial for everyone involved to ask a lot of questions so that I understand the scope of their work and also so that the other team members bring up comments about their individual tasks in case they have questions for others.
By the end of the day, I will be tying up any loose ends that may exist. I use the last hour or so to email people or follow up on questions or things that I need for my team. If there are blockers, I will address them as soon as possible. After I have completed my administrative work, I will have a brief discussion with my team members to make sure they are making progress with their work before I head out for the day.