The Quality Identity

I am going to tell you the story of an agile transformation from the Quality Assurance (QA) perspective.

Why?

Often, as Agile Coaches, we encountered situations within companies where the QA individuals feel lost or at odds within their team. I hope to share some strategies when helping QA individuals find their place with a new Agile world.

Most companies start from a place of silos and "hand-offs". A stakeholder has an idea; hands it off to a business analyst; who hands it off to a developer; who hands it off to QA; etc. In this structure, QA typically finds themselves at the end of the development process and the last stop before something is released. In being the last stop, they end up having the most pressure from stakeholders. "Why isn't this ready?" "When will this be released?". It can be very stressful, especially as work begins piling up in their silo.

Enter Agile. The leaders of the company hear about this new way of working and how it is a game changer for product development and delivery. So they decided to "Go Agile!". This will make everyone happy right? The QA's will be less stressed right?

Wrong.

Lesson #1 - Change Triggers Fear

Did you know that, as human beings, we don't like change? Change triggers fear.

Fear triggers panic. Most individuals respond to fear & panic with either fight, flight, or freeze.

Do any of these scenarios sound familiar? Employees complain about Agile and don't use it (fight); Employees start looking for new jobs (flight); employees just move to their team and sit around until they are told what to do (freeze). All of these are natural reactions to the fear that change triggers.

If you want to mitigate the fear responses in your company, you need to take any agile transformation slow. Focus on the impact to the individuals and how you can help them to adapt to the change successfully.

This is especially true for QA as they are often left out of restructuring conversations or communications. Usually business analysts are told they will become Product Owners; and developers are told that they are still going to develop, but how do you communicate with QA?

I encourage you to put yourself into your QA's shoes and really think through what the change means for them. One example is, if you have 1 QA on a team with 3 Developers, they are going to feel outnumbered. What steps can you take to ensure everyone recognizes they are on the same team?

Lesson #2 - Reaffirm the importance of quality.

Your customers still expect quality.

One common misconception that is communicated during an Agile Transformation is that Agile = Fast. Teams are now expected that they can delivery twice the work in half the time.

In reality, Agile = Inspect & Adapt. It is a mindset that allows you to ensure you are building products customers will actually want.

If you communicate to teams that Agile = Fast; quality of your products will be sacrificed for the sake of speed and QAs will feel less empowered to speak up within their team if there is a problem.

BUT if you communicate that Agile is an iterative process with feedback loops designed to ensure we are building the right things, you reaffirm the importance of quality. You reaffirm the QA's role is important in the team.

Once you have done that; the QAs have a chance to flourish.

Lesson #3 - Map out Quality Assurance

Encourage your QAs to help the team determine how they will ensure quality is hit and what that looks like, through an exercise called "Map out Quality Assurance".

Ask the team to define the appropriate level of quality they want to strive for; ex. "Doesn't have to be pixel perfect, but should be free of any bugs within the user interface."

Then look at the process the team is using and map it to ensure quality is being treated as the full responsibility of the team, not just the QAs'.

We ran this process mapping exercise on two separate teams; one running Scrum and the other running Kanban. In both instances the QAs were able to step back and see that the teams were still doing hand-offs, and quality assurance was still treated as a separate role at the end of the process. They were still doing waterfall, just in disguise.

Ex. The Scrum team's process. Still doing hand-offs, with all of the tickets hitting QA at the end of a sprint. If there were any roll-overs, the QA was often blamed. We were able to show this to the team and help them create improvements such as Developers helping with testing; Acceptance Criteria listing out the definition of done in terms of quality; QA having time to develop Automated Tests, etc.

Ex. The Kanban team's process. They were also still doing hand-offs and working within discipline silos. Waterfall in disguise. The QA asked that the team change their Kanban board to be columns by process steps instead of columns by discipline; in addition, the team created WIP limits with rules that Developers would test if a Testing WIP limit was hit; and acceptance criteria included a quality definition of done.

Encouraging your QAs to step up and map out the teams process can uncover whether you are still running "Waterfall-in-disguise". If that is the case, work with the QAs to ensure quality is being treated as a full team responsibility.

Phew, that was a lot, but hopefully you have some takeaways that can help.

Recap - The strategies to help your QA individuals flourish in an Agile world.

1. Understand that Change Triggers Fear, and how to mitigate it

2. Reaffirm the importance of Quality, empower your QAs

3. Map out Quality Assurance for the Team, quality is the responsibility of the whole team.