The programmers write new code so fast, the testers can’t keep up. It’s like shooting a firehose into a straw. It doesn’t matter how fast the programmers shoot new code out of the firehose, because the testers have to get it all through the straw before we can say it’s Done and deploy it in production.

You have a problem
The problem is easy enough to recognize. You have a killer programmer team, but the test team can’t keep up. You have a bunch of features that were coded, so you think they are almost done, but the features haven’t been tested yet, so you can’t deploy them to production. You’re frustrated that you can’t get stuff out the door.

And it just gets worse. No matter how close the test team comes to catching up, the programmers keep adding new, untested code. It seems like you can never get Done, and you have no idea when you’ll get Done or how much more it will cost.

Your problem is you
You need to ask why. Make a list of reasons this is happening and think of ways to fix it. Here are some possible causes:

  • You have the wrong mix of players on your team: too many programmers, and not enough testers.
  • The test team is distracted. They spend too much time doing bug triage or preparing for future new features. They attend too many meetings. They spend too much time on customer or production support.
  • The test team has inadequate computing resources. Other teams borrow their test environments, totally blocking the test team. When the testers get their environment back, it takes too long to reconfigure. To make matters worse, components of the test environment are unreliable, with too little disk space or subpar network infrastructure.
  • The test team relies too heavily on manual testing.
  • Your release criteria (your Definition of Done) are so onerous that the team can’t ever be Done.

Fix it
Given that list of problems, the solutions seem obvious:

  • Stop hiring programmers–more programmers won’t help you get Done any faster. Add more testers, or make the programmers play tester.
  • Protect the test team from distractions. Your testers are the critical constraint–don’t let them do anything that doesn’t help them get Done. Other people can represent them in meetings or help with support issues.
  • Get the test team the computing resources it needs, and don’t let anyone else use those resources, for any reason. Stabilize the environment’s infrastructure. Manage the infrastructure yourself, so you can fix problems immediately instead of handing them off for another team to fix.
  • Automate!
  • Review your release criteria. Does every item add value? Does every item protect against low quality? Can you remove some criteria? Can you address the criteria earlier, as part of getting each story or sprint Done?

What are you doing about it?
Why can’t your test team keep up? What are you doing about the firehose of new code shooting into the straw of testers?