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
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?
Image by Helen Wilkinson [CC BY-SA 2.0], via Wikimedia Commons