Agile First-Class Citizen

By Lisette Zounon, CSM- CSP, DTM

 

Today I wanted to share a little bit about a talk that I had last week.

I had the opportunity to give a lightning talk at the DFW Scrum user group. My talk was titled “Agile First-Class Citizen.”

Usually, if you have ever been in any agile training, what we learn about agile and scrum role include the following:

1- Product Owner

2- Scrum Master

3- The Last Development Team Everybody else is a group under the development team.

I’ve seen organizations use that as an excuse to exclude the Quality Assurance Analyst, Quality Engineer, or tester from the team. The organization is usually saying we’re going to do an agile transformation. We are going to start a DevOps transformation, so we don’t need a QA. When I hear that, it is usually the following complaint that starts experimenting with a lot of quality challenges. One of my clients just told me that sometimes they don’t even know what went into production, they don’t even know what kind of application they have, who and what was tested? The user group is usually complaining because they are having a lot of issues in production.

Who should be responsible for testing? I strongly believe QA should be responsible for testing. It should be somebody solely responsible for testing, somebody that is solely independent and also advocating for the stakeholders and the users, that knows how users are going to use the application. QA should come up with scenarios/test cases to test user experience and expectations of the application, software or product. So, we need to make sure it’s somebody that is independent.

Three things make QA a valuable asset in software delivery:

1- First, we have the best view of software delivery. We are the one that know if the application is going to work, how it is going to work, and looking at a possible issue.

2- Second, we deliver value, we define and determine the quality of the software, such as how many bugs coming through, and the severity of the bug.

We understand how the software is going to work first hand because one thing is to say have a requirement defined, but by the time you get to QA, you know for sure that the software is going to be working and it’s going to meet the requirements that you expect. You also know in the delivery how long everything will take, because we spend a lot of time estimating during sprint planning. By the time you get to QA, you know if the developer tells you it’s going to take you 5 hours for a user story, and it took him twenty-five hours.

3- Last, we are also change agents. I have been fortunate to be involved in two agile transformations. They are not always successful, but they are a transformation because the organization is trying to move from a waterfall or whatever methodology to an agile framework. In both transformations, I didn’t come in as a coach or a consultant. First, I was a QA lead. I was a QA team member in the scrum team, and I was able to influence my team into adopting some agile best practices based on issues that we were seeing and that we needed to improve upon. We were able to adapt as we went for what was needed for our team.

For the second time, I came in as a QA manager, leading a large QA team. Our inside joke was that my team members were QA FBI agents that would go into the different projects and impact the change that was needed based on issues the team was facing in their software delivery. Therefore, they were acting as a change agent. As a QA professional, you have to be a leader without a title because you don’t have the authority as a consultant that is higher up to impact and demand change. But, you have the first-hand and the first view, the best view of what is happening, and you can affect change right there and then if you can find your voice.

The takeaway and call to action that I gave the group in my talk with a room filled with agile practitioners, agile coaches, scrum masters, and agile consultants was to reconsider their approach to agile transformation. Don’t just come and interact with developers or scrum masters, get close to your QA professionals on the scrum teams. Make them the central part of the decision and discussion about the challenges you are here to solve. Listen to them. What are the opportunities to grow for the team? What are the areas of improvements in the software delivery? Because your QA professional has the best view, we are the first-class citizen in agile transformation.

My approach to agile transformation is to focus on solving quality challenges changing the way of working for the team. As the team grows, so does their performance, and in return solving all the quality challenges, and delighting your customers and users at the end. It is like beginning with the end in mind, my favorite of the famous seven habits. That is how we approach agile transformation at ZSI- Zsquare Solutions Inc. We are QA professionals and agile coachs, consultants with a passion for quality, purposely changing the way of working to make your team and customer happy. Book a 30 min consultation with us here to discuss your current projects and your 2020 QA initiatives to start solving your pain points right away. Everyone has pain points and your project and your team cannot wait.

I love to hear your thoughts or horror stories. Comment below about your experience with QA or QA in the software delivery in an agile or scrum team. If you have any questions or if there’s any topic that you want me to share next month, please comment below and I will be more than happy to cover them.