Re: Parallel QA

"Matt Heusser [email protected] [SCRUMDEVELOPMENT]" <[email protected]> Thu, 31 Aug 2017 10:20:23 -0400
Newsgroups gmane.comp.programming.scrum.general
Message-ID <CAFWhbxYoxFS82ovMvZQeEKF+tOjBmJKCeU08eQcU0BS_W8Dy7g@mail.gmail.com>
"What do you say to a QA manager that thinks QA work should be done outside
(after) the sprint?"

I'd say something like it's all a tradeoff. The parellel pipeline can be a
compromise that works in some contexts. Long-living projects tend to turn
into the accordion.

First you put dev in sprint 21 and test sprint 20. Then, at the same time,
you are trying to put sprint 19 on production. And patch sprint 18 at the
same time. And BA is on sprint 22. And PM is on sprint 23. And the
executives are looking at sprint 24-30.

What this does is explode the work in progress. Instead of a team of 10x2
weeks, or 20-person-weeks of WIP, you have 10x12=120 person weeks of WIP.

Moving to delayed-work means devs have to work in more branches. When test
finds a bug, instead of working together to get code out the door, the dev
needs to STOP the sprint 21 work ("slowing down") to do the fix on sprint
20.  Instead of a bug fix to a story the dev finished YESTERDAY, the bug
needs to be triaged and assigned to a dev. That dev probably didn't work on
the original story, leading to confusion, I can't reproduce, etc.

So it's a tradeoff. Short-term, moving to test-later can feel like it is
taking some pressure off. Long-term, you go slower.

In this case, I'm more inclined for the more classic advice "if it (testing
tight schedules) hurts, do more of it."

best,


--
Matthew Heusser,
Managing Director, Excelon Development
http://www.xndev.com


Save The Scrum! http://www.leanpub.com/SaveOurScrum