Have you ever been in a conversation like this?
Manager: “The last release is very buggy, why didn’t we spot the issues before?”
Tester: “We did all we could with the resources and the time given to us”
Manager: “What can we do so that it doesn’t happen in the future?”
Tester: “We need more testers”
Manager: “OK let’s get Michael form the 4th floor help us from Monday”
I have been hearing this conversation for more than 20 years. I have even been the tester and the manager in these conversations.
But what happened the following release? Did Michael from the 4th floor manage to help improve the situation? Not at all, and the same would have happened if also Frank and Jane from the 5th floor helped, and so on.
One day, over 10 years ago (before I even knew what agile or lean was), I thought that insisting with the same approach would have been insane, so I started to look at what different possibilities we had and I tried a crazy move.
When challenged with the same “too many bugs in this release what do we do?” I said:
Why don’t we remove a tester instead of adding one?
People laughed at me, but I had enough influence to be able to try this.
Against all odds, things got a lot better. The one tester remaining in the team was swamped with work and developers felt they needed to help to avoid getting everything on hold.
Guess what, they started to help.
Some of the activities that were “tester zone only” before, became accessible to developers. A different perspective helped identify some inefficiencies in such activities and developers adapted some of their own process to help.
All of a sudden giving developers visibility over the test activities had triggered a lot of curiosity and interesting hypothesis. Some developers, challenged with repetitive tasks, created small tools to make them faster, some other saw how sharing the test plans with the developers could help prevent issues that otherwise would have been caught much later, and so on.
This was many years ago, it wasn’t perfect, but taught me a great lesson.
If people don’t have skin in the game they won’t improve the system. If they are affected by a problem they will resolve it instead.
If you ask your developers to write code, that’s what they will do, defects and all.
If you empower them with delivering customer value they will look beyond the code and make sure that what they deliver is also useful for their customers.
This is one of the foundations in today’s agile software development teams where role silos are gone, collaboration is fundamental and team members care about customer value rather than lines of code or number of tests executed.
We’ve come a long way