The Right Ratio of Developers to Testers?

Typically what we see in agilesparks customers is 2:1 or 3:1. There are some exceptions of 3:2 or 5:1 but they are quite rare.

What is right? Well as u might expect it depends: - what are the skills/strength of developers and testers. Not all engineers are made equal… - how are the responsibilities spread between roles? Eg test automation etc. - what is the development life cycle style used by the group - what is the quality of the code when delivered to testers - technology and character of the system. Usually the lower the product is in the stack the more testing it needs per code developed. This is due to the amount of impacted areas, the complexity to test, and the breadth of the configuration/platform matrix. - how much test automation exists

One of the typical dynamics of a phased waterfall-like development lifecycle is that QA phase starts late and pressured and compromises in quality are part of life

This means very tough weeks/months for the poor testers which get a big blob of code to work on, they are outnumbered, usually outskilled and the following happens: - the perception is that test is the bottleneck. ( well I would say that in waterfall each phase is a bottleneck. Those that tend to be the last ones just get the short end of the straw ;-) - either test phase is prolonged or developers are asked to help do testing. Or both.

But what also happens is that organizations get used to this. It’s a fact of life. For some reason the need to strengthen the test organization is usually outweighed by ability to develop more features each version.

Another thing is that developers do end up helping testers they usually do it in crisis mode when their only option is to help do the work, not help testers have an easier job the next time

Lets see what happens when such an organization moves to agile/kanban

In kanban or any kind of lifecycle that is feature driven developers and testers are expected to have more Or less the same pace / feature velocity. So our typical outskilled outnumbered testers usually quickly appear as a bottleneck early in the transition to agile.

Limiting the WIP in test and Dev causes Dev to stall, leading to one of the classic discussions in kanban workshops and even some kanban games I wouldn’t mention to avoid spoiling the fun ( Carlos - we know you’re out there!)

In an upcoming post I will try to cover what can be done when this typical scenario happens, using practices from Agile Testing, the TOC five focusing steps, and agile engineering practices I general.

Moving from agile theater to real business agility takes more than a framework. Explore Business Agility advisory or let’s talk.