How to get more from Scrum (and why testers make perfect Scrum Masters)
Some years ago, when I was just starting my IT career and SCRUM was becoming the default way of working for software companies, I had a discussion with a more experienced friend about why it was necessary to gain Scrum knowledge. While I was expressing concerns regarding my lack of Scrum experience, he told me something that stuck — “Few companies actually implement Scrum by the book (read: Scrum guide)”. I was relieved to hear that. My lack of Scrum knowledge would not affect how I performed at the job. Little did I know, I was completely missing the real meaning of his words.
Fast-forward to the present day, I am a tester for the Merchandising & Campaigning development team, and for a while now, I’ve also been acting as the team’s Scrum Master. It started when the team needed a Scrum Master, so I took it upon myself, thinking that it would be a temporary activity, which would allow me to develop other skills a tester doesn’t necessarily need in order to perform.
I’m not a certified Scrum master yet, but I had Scrum training at Levi9, and I’ve been working in Scrum teams for at least 5 years.
I saw it as an excellent opportunity to bring my contribution to the team by taking care of some of the administrative tasks to allow developers to focus on what they do best: write code.
In the beginning, my focus was on two things: removing potential impediments for developers and assisting the product owner in managing the product backlog (although this task can also be completed by the tester).
The team
The scope of our team puts us in a supporting role for other teams like Shop Marketing or SEO. What that means is we often get requests from various stakeholders and usually, the deadlines are tight. And, of course, this happens during an active sprint.
The life of a Scrum Master can be hard in the beginning, as it is their responsibility to ensure the team’s effectiveness. The Scrum Master supports the development team to commit and work towards the sprint goal. This is not a simple task for a new team.
Luckily, our team is mature, and that counts for a great deal. The developers are well-adjusted to each other’s way of doing things, and that gives me the confidence to rely on their input whenever a decision needs to be made. This is also the main reason I could quickly take over Scrum tasks without much of a hassle. If you ask me, we are in the ideal scenario where any technical member of a self-managing team can assume the part-time role of a Scrum Master.
Being Agile
As previously said, we receive a lot of requests from other teams, which naturally turn into user stories that must go through the whole Scrum cycle before being considered as done. When working in a dynamic environment and dealing with a lot of things that need to be ready ‘yesterday’, maintaining good control over the product backlog might become challenging.
In most cases, a scrum team will have two refinement sessions per week, each one taking around one and a half hours. Plenty of time to get things done, right? Well, not if you spend it by being rigid about following Scrum rules no matter what, while the user stories keep piling up waiting for refinement.
One way we handled this was to move our refinement sessions from twice-weekly, lengthy (and dull) ones to daily 30-minute sessions straight after the DSU. This might seem counter-intuitive to some, but it allowed our team to have more effective discussions about user stories. We could refine more user stories and it became easier to invite stakeholders to attend our meetings and clarify requirements.
Another thing we did was to put an equivalence sign between the number of story points and the actual number of working hours/days. While this doesn’t fit the Scrum “dogma”, it helped us to have clearer estimations.
Disclaimer: Please keep in mind, this can be a dangerous practice if the team members are not used to working together and it can lead to disaster.
My experience so far
As the sprints progressed, I realized that taking on Scrum master tasks made things simpler for me as a tester as well. If you are actively involved in facilitating Scrum events, you will undoubtedly develop a greater understanding of not only the product backlog but also the general business context in which the team functions. This also applies to a more effective communication with stakeholders and a better understanding of how our team fits into Wehkamp’s tech landscape.
This is where things became interesting:
As a tester, you help define requirements. As Scrum Master, you ensure that the development team understands those requirements.
As Scrum Master, you have no proper authority over the technical aspects of the product. As a tester, you can shape and fine tune the technical aspects by asking better questions and by ensuring the functional and non-functional requirements are met.
As Scrum Master, you are the “humble servant”. As a tester, you try to break stuff and challenge the status quo.
So, do we do Scrum “by the book”? Maybe not, but I strongly believe that we have it figured out pretty well. By having a strong development team, holding each other accountable, promoting open and clear communication, we work towards the same goal and accomplish it sooner rather than later.
Thank you for taking the time to reading this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium.
I am a Levi9 Test Developer working at Wehkamp.nl, one of the biggest e-commerce companies of the Netherlands.
We do have a Tech blog, check it out and subscribe if you want to read more stories like this one. Or check our job offers if you are looking for a great job!
