RE: Re: Parallel QA

Part of the problem you face is that there is a misalignment of incentives and charter between the development org and the test org. QA typically has strong incentives against trying new things and going faster because they get blamed when there are quality issues and they don’t get rewarded for being more efficient.

So, basically you are asking the QA manager to do something that has a lot of downside and little upside.


From: [email protected] [mailto:[email protected]]
Sent: Thursday, August 31, 2017 7:42 AM
To: [email protected]
Subject: Re: [SCRUMDEVELOPMENT] Re: Parallel QA



Beautiful, everyone, and brilliant. Thank you! It’s always stronger if you check in with the hive!

The original question had a reference to my How to Talk to a Skeptical Developer talk. So the only thing I would preface to all this is:
Listen (Level II)
Recreate (They know you got their world of concerns and will be speaking into that shared understanding)
Prove it (Or it’s all noise)

Cheers.

Michael

On Aug 31, 2017, at 10:20 AM, Matt Heusser [email protected]<mailto:[email protected]> [SCRUMDEVELOPMENT] <[email protected]<mailto:[email protected]>> wrote:


"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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.xndev.com%2F&data=02%7C01%7CEric.Gunnerson%40microsoft.com%7C18ff48f7d7344988d4e608d4f07e72ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636397873266174291&sdata=f5yKFGARqF2HJtqACrFGJeDimSJN9LxRMTkCfV%2FwYiw%3D&reserved=0>


Save The Scrum! http://www.leanpub.com/SaveOurScrum<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.leanpub.com%2FSaveOurScrum&data=02%7C01%7CEric.Gunnerson%40microsoft.com%7C18ff48f7d7344988d4e608d4f07e72ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636397873266174291&sdata=Q44f7IBFLyDgo03VQEJjzpgQu2llKbzu87P1xROiVuA%3D&reserved=0>