The source of this concept comes from my experience with teams transitioning to scrum/kanban/scrumban systems as a tester. In my experience even when WIP limits are applied they are only applied to the development swim lane. Which means as work gets finished it avalanches down into the testing team. The concept that development is a more complex endeavor than testing is a potential driving force behind this fallacy. The belief being that testing is easier than development so you can heap loads of stories onto the testers and they’ll knock it out in a similar amount of time to how long it took to develop.
There are loads of issues with these assumptions. Rigorous, skilled testing can be considerably more time/effort intensive that coding the story. When testing is left until the end as a separate activity the only result of that testing is rework and therefore cards are send backwards along the kanban.
Beyond the testing example, we have different business units interested in the process. How can we have a “whole team approach” if we put walls between engineering and management, or sales and engineering? How do we engage these teams in collaboration?
I have some ideas about ways to attempt to resolve these questions. I have no answers but I look forward to having an active discussion about this important topic. I hope we’re able through this dialog to come up with some ideas to explore further, and ideally we’ll even commit to actionable goals that we can individually strive to achieve.
Here’s a mind-map of the structure of the discussion as I see it, feel free to offer feedback prior to the conference and remember it’s not too late to register and come spend some time with brilliant doers & thinkers in the space.