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?

Image by Helen Wilkinson [CC BY-SA 2.0], via Wikimedia Commons

Agile Development with debt ridden code

Is your code base as messy as this kitchen?

If it is, I am sure it will be slowing you down. Working on technical debt ridden code is very hard to do in an agile way.

This is because the debt: 

• Limits our ability to easily cut scope to meet our deadlines. (Caused by Coupling)
• Makes it hard to split the work into small user stories. (Caused by Coupling)
• Makes it hard to predict when we will be done. (Caused by lack of tests, coupling, defects, unexpected side effects)
• Limits our ability to work fast, while maintaining high quality (Caused by all types of debt, especially debt with the tests)

Technical Debt that impacts our ability to delivery consistently:

• Tight coupling
• Design that limits extensibility
• Inconsistent design
• Inconsistent coding style
• Existing defects, especially hidden/unknown defects.
• Lack of automated tests
• Unpredictable/ inconsistent test results 
• Slow tests 

Recommendation One: Focus on Fast, Reliable Automated Test Results

The aims are to improving the quality & scope of our test suite, along with obtaining faster feedback. Fast, reliable feedback allows the team to work towards their sprint goals in small controlled steps and this improves reliability of delivery. 

Here are my specific tips to achieve these aims:

• Run the test suite more often. Once a day is rarely fast enough, aim for at least three test suite runs during working hours, more is even better.
• Increase granularity of reporting; ensure that all tests report their results separately. Watch out for 1 test failing that stops several other tests from running; this results in secondary defects being hidden until the defect causing the first test to fail is resolved.
• Split up the test suite into separate tests or test groups; run them in parallel on separate environments. You may need to acquire more environments. This does a couple of things; it removes dependencies within the test suite which will likely identify some hidden defects. Secondly it will greatly reduce the overall duration of the test suite resulting in faster feedback.
• Get faster hardware to run the tests on, resulting in faster feedback.
• Add more environments, with at least one environment per team; giving flexibility of when/who runs the tests, resulting in faster feedback.
• Set standards of how tests and test suites are structured. Ensure all new tests are developed to the standard and any exist tests that are ‘touched’ are updated to the new standard. Over time this will improve the quality of the entire test suite.
• Improve the reliability of the test suite by identifying and removing intermittent tests. Refer to Martin Fowlers excellent article on Non Determinism in Tests for specific approaches to removing intermittent failures.  Also run the test suite on isolated hardware to remove outside influences. 
• If your tests are running over night, identify regular IT maintenance work that could be impacting on your test results. For example database backups that greatly reduce the speed of the database.
• Enforce that all new development work has automated tests that cover that work. This is not just for new features/components. Any work on existing code must have tests added, if there are no tests for that area of the code, they may have a substantial piece of work to do. However it does not take long for the extra effort to start paying dividends.

Recommendation Two: Incrementally attack the debt

Fast, reliable feedback allows the team to engage in effective refactoring.  This in time allows them to reduce coupling with their code and also reduce other types of technical debt, which further increases their reliability of delivery. 

With our Fast, Reliable Test Suite in place it is now time to start attacking the debt:

• Revise the existing Coding standards with a focus on decoupling and consistency. Ensure all new code is developed to the standard and any exist code that is ‘touched’ is updated to the new standard.
• With each new piece of work that the team is about to start, get them to think about technical debt that is related to this work. Investigate the debt, make it visible, do a cost benefit analysis for the reduction of that debt and involve the Product Owner.

Do you have any other tips for working in these difficult situations?

Photo Credit: independentman