My takeaway on Agile for Humans video YDS: Where Does Quality Assurance (QA) Fit on a Scrum Team? dated 16 Mar 2021

This article is aimed towards expressing how I as a Scrum Master would deal with this situation. I agree with Ryan Ripley where he says the quality team is a crucial piece of the puzzle in delivering value to the customer. What I’d do differently to ensure timely results while prioritising Quality with a capital Q. 

It’s a given that without quality the product adds no value and these two variables are directly proportional to each other. The higher the quality, the higher the value rendered. In the waterfall framework Quality and testing are followed after developing the product. For good reason, Agile working takes center stage. Keeping in mind the time efficiency benefits of Scrum, firstly, I would embed quality into development. How? In the Scrum planning meeting itself, I would invite the quality experts. This is if they aren’t part of the scrum team already. 

In his video, Ryan said “the more that the developer can learn how the Quality guys think, the more defensively the programmer can program”. I absolutely agree with this. It is valuable in understanding their view of where bugs exist, what are the quality-related factors to be concerned about while developing and address them at the beginning. 

For example - A developer does his part of building. However, if he/she isn’t aware of the possible bugs this means additional hours taken by the quality expert/team to fix the bug or to check other aspects and bring this to the developers attention. By having the quality expert at the scrum planning meeting, we can take care of the possible bugs and all quality concerns at planning itself and figure out with the developers how to fix this while building. If my developers understand how to not encounter the bugs in the first place, I have saved time and maintained quality. 

Further, Ryan Ripley pointed at a very important area - Making the Quality member/s part of the scrum team is the solution to the old school style where developers throw the product over the wall to a separate team and do not suffer the consequences of their own work. 

If a scrum team isn’t already doing this, it would take a while to introduce it and get used to the new way of working. But hey, if this change can help the team deliver value, as a scrum master I drive this consistently in my team. In doing this results are achieved, value is created and upward onward we go further. 

Here’s the link to the video. https://www.youtube.com/watch?v=qQieLMFeMh8