Why the "in test" column is actually bad for development teams, especially testers, and how adding more columns helps you get rid of it.
A lot of development teams typically have a “In Test” column on their boards to indicate when things are being tested. Some even have “Waiting for Test” columns this way the Test team know what work to pick up next and are never left idle. This also allows the Dev team to keep busy while Testers are verifying the system is fit for purpose. Which all seems like a good idea but what a lot of teams don’t realise is this is actually leading them to have more work in progress rather than focusing on finishing work. Not only that but a lot of other issues too:
- Encouraging inner team silos
- Pushing testing towards the end of development
- Testing becoming the bottleneck within the team
- Slowing down the feedback loop for the whole team
The usual solution to these problems is to add more Testers to do the work faster or to use automation in an attempt to replace the work of the testers. Both of which have their subsequent problems. But there is a simpler solution. Remove the Test column and refocus the team on finishing work rather than keeping busy by starting new work.
Now you could just simply remove the columns and let the team figure it out. This could work or you could tackle the problem systematically by using the ideas from Theory of Constraints. How? By using the 5 focusing steps to identify the bottlenecks in your testing process, focusing your efforts to eliminate them and continuing the process until you no longer need the “In Test Column”.
In this talk I’ll explain why the “In Test” column causes these problems, how to apply the Theory of Constraints to solve them and how you can use the same approach to other processes too.
- How to talk about why the in test column is a bad idea for development teams
- Why we ended up with the in test column and it’s sibling waiting for test
- How to systematically move away from the in test column iteratively as a team