@andrewrusling Working as an Agile Coach allows me to learn and grow on a daily basis. This is my chance to share some of that new found knowledge

Saturday, September 23, 2017

Breaking down the Coder vs. QA divide

The Coders vs. QA divide is prevalent in almost all
companies that are new to an agile way of working. The Coders camp out on one
side of the wall, throwing work over to the testers. Creating cross functional
teams does not automatically resolve the ingrained ‘over the wall’ mental model
of development. Often two mini teams form within the agile team, with the wall
still very much intact. This mental wall perpetuates ‘Us vs. Them’ adversarial
behaviour; which generally leads to late delivery, reduced quality, stressed
testers, limited collaboration and frustration on both sides. Thankfully this
issue can be addressed in a reasonable time-frame when the appropriate actions
are applied as a cohesive approach.

The long term goal regarding Coders vs. QA is usually to
blur the line between Coders and QA to the point that they are all
‘Developers’. Some of the Developers have more of a QA focus; however all of
the Developers are actively involved in testing and quality throughout the life-cycle of the product. These Developers create and maintain a test suite
that adheres to the agile QA pyramid. This is a long and rewarding journey to
take; with breaking down the Coder vs. QA wall as the first major step.

How to identify that
the Coder vs. QA wall exists

When you notice two or more of the following situations, it
is likely that there is a divide between the coders and the QA.

QA/Testers are the only people who test the software. No one
else helps even when it appears likely the team will not complete a user story
within the iteration.

Reviews and showcases where teams discuss user stories that
have been built, yet the user story has not been tested.

Reviews and showcases where teams show user stories that
have not been tested.

Inconsistent velocity from teams.

The testers are stressed at the end of iterations while the coders
are idle looking for work, or worse still working on user stories from future
sprints.

All of the testing occurs in the last 10% of the sprint.

Request to extend sprint duration because it takes too long
to test the delivered features.

Use of phrases such as “It is done, I have coded it, it just needs to be tested.”

How to remove the
Coder vs. QA wall

My favored approach to removing the wall involves some
carefully executed company level actions, supported by team level coaching.
While it can be addressed just via team coaching; that does not scale well,
produces inconsistent results and takes a lot longer. I recommend considering the following actions, remembering that these actions need to work together to change the hearts of minds of many different people.

Company-wide minimum DOD includes “User Stories must be
Tested”. All teams must have a DOD that includes the ‘minimum DOD’; they are
free to build upon if they wish.

Company-wide training which emphasizes

Teams succeed or fail as a whole

The whole team is responsible for quality, not just the testers.

QA provide Test Thinking, however everyone in the team
contributes to testing.

Value of completed stories over partially complete stories

WIP is waste

WIP reduces our ability to change direction

ATDD/BDD

Company-wide support for ATDD/BDD with

Tooling and environments

Expertise and coaching for the implementation

Specific training for QA to develop their automation skills

Coach Product Owners to

Value only completed stories.

Demand to see only completed stories in reviews/showcases

Demand to only see working software in reviews/showcases

Support team coaches/scrum masters to:

Re-enforce the messages from the Companywide training

Establish Coder/QA pairing

Establish ATDD / BDD

Work with QA to create a prioritise automation testing
backlog. This backlog can be worked on by Coders/QA during slack time. Over
time it will reduce the demand for manual testing, freeing up the QA to focus
on automation, exploratory testing and building quality in.

Run team exercises where team members learn more of the
details of what each other does and how they can help each other.

Provide training to the coders on basic of effective manual
testing; so that they are better able to step in when needed.

Questions for you

What has your experience been with Coder vs. QA divides?

Have I missed any signs of the divide?

Have you taken different actions that worked well or taught
you what not to do?