Columns like "In test" often lead to teams having more work in progress and less work actually being finished. Removing such columns can increase collaboration between testers and developers and enable teams to deliver faster.
Jit Gosai, principal tester for the BBC iPlayer & Sounds team, spoke at Lean Agile Exchange 2020 about how teams can deliver faster by killing the test column.
Typically, task boards have an "In testing" column for work being done by the testers and an additional "Waiting for test" column to collect work that’s "Dev done". Gosai said that testers know what they need to work on next; developers can move onto other work while waiting for testers to finish and we can keep people on teams fully utilised.
If no issues are found, then the task can move into the next column, typically "Done" or "Waiting for release". But what happens if the testers do find a problem or need more information? There are a number of choices: does it go back into the "In Dev" column, pushed back into the backlog, or do you now create a "Waiting for Dev" column as a holding area? Gosai mentioned that any of these options result in more work in progress or context switching for the developer.
Meanwhile, what are the testers to do? Move onto the next item in their column, or wait for the developer? No matter which option the team decides, testing will always appear to be the teams biggest bottleneck for getting tasks completed more often than not as there will always be more developers than testers in a team, Gosai argued.
When we remove the "In test" column, developers remain with the work while testers are testing it, and they can work together to see it through to production, Gosai said. Developers would have to collaborate with testers to understand what needs to happen next and complete it together.
With a good process improvement practice in place, testers and developers can start to see how they can work together to mitigate any risks in the work done by the team. This encourages the insights found during testing to be built into the process instead of being handed over to developers in bug reports, Gosai concluded.
InfoQ interviewed Jit Gosai after his talk.
InfoQ: What are the drawbacks of having columns for testing on the board?
Jit Gosai: The "In testing" and "Waiting for test" columns look like good ideas, but as explained they often lead to more work in progress and other problems (for more details, see my post on issues the "In test" column causes).
The usual responses to resolving it include adding more testers (usually too expensive) or automation which is typically end-to-end UI testing - which starts to encourage other bad developer habits, such as writing more integrated testing with the full stack rather than isolated tests, testing becoming someone else’s responsibility, and pushing testing towards the end of the development life cycle, to name just a few. You can find more about these issues in my post The unintended consequences of automated UI tests.
InfoQ: How can we remove the test columns but still keep insight into the testing?
Gosai: The idea of removing the testing column doesn’t mean that testing is no longer important or isn’t happening anymore. It’s actually about focusing the team on a common goal which is to focus on finishing work rather than starting more work.
Having fewer stages for the work to go through means that developers stay with the work longer, or allowing other developers to contribute. This now gives the opportunity for testers and developers to start understanding what the other has already done and what testing still needs to happen.
InfoQ: How does removing test columns enable teams to deliver faster?
Gosai: In two core ways. One is that there is less work in progress and an increased focus on finishing work. This will naturally lead to more work being completed, especially if it requires any rework due to defects or other unforeseen circumstances. The other is that now developers and testers are working together to mitigate any risks associated with the code changes.
Working together at this stage is about sharing information, such as what you already know about the changes and what else you have learned while carrying them out. This enables individuals to incorporate and build on top of others’ knowledge and create new ideas that they may not have necessarily had if they were working alone. Now is a perfect opportunity to see if these mitigations can be built into the development process, either through automation or some other process. This is also a good time to see if the task is actually rework (e.g. issues found in the live environment) and can be learned from so as to prevent this issue from happening again.
While the benefits of these improvements wouldn’t be seen immediately, the long term implications can be considerable in improving the lead times of tasks, which would help teams get more done within the same time frame and therefore deliver faster.
There are a few assumptions to note within these speed improvements, the two main ones being that developers and testers actually begin to collaborate to understand what the other has done/would be doing, and don’t just move to a hidden mini dev/test handover process; and the other being an effective continuous improvement programme to learn from the other discipline and the types of failures that get through to the live environment.
InfoQ: How can we use what’s visible on the task board to improve testing?
Gosai: If working as collaboratively as I’ve mentioned above is quite new to the team and they have yet to implement a continuous improvement strategy, then there are a few techniques they can still use to kick start this process. If testing has indeed been identified as the team’s biggest bottleneck to releasing, then they can use the "In testing" column to their advantage.
Instead of testers simply picking work out of this column and working on it till it’s done, they should work with the team to help them understand how they approach testing, the types of things they are looking for and also finding during testing. Doing this with a handful of tasks is likely to help them identify some key themes within their work. For example, are there similar root causes such as usability or accessibility issues, or some hardware/software combination that always results in a bug? Is there something the devs could look out for while making the changes? These themes can be used to create a backlog of tasks that the team can begin to tackle to see if they can be addressed earlier on in the development life cycle.
By focusing on the process and not the people, it makes it easier to talk about what testers are doing, how developers and testers could mitigate this work earlier on in the life cycle, and begins to be the seeds of the continuous improvement programme.
Leadership in this process is very important. Leaders need to help testers feel comfortable that they are not being targeted as the "problem" within the team, but are actually the solution in educating the team in what risks they are looking for when testing. Developers will also need help to work closer with other disciplines through coaching in communication and developing empathy around the fact that they are not trying to replace the other disciplines, but working to improve the process together.
One of the key tasks for leadership within teams is creating a psychologically safe environment. This enables team members to be open about the problems they face and even share thoughts, ideas and solutions that are not yet fully formed, without risk of embarrassment or being judged incomptentent. It’s all very well having a backlog of continuous improvement tasks, but if people are unwilling to work on them together, you’re only going to get mediocre results. This inevitably means they never get the attention they deserve and the innovative will fail before it’s even started. You may have heard this in teams as "We’ve tried that before" or, "That’s never going to work because of... ".