RE: Re: Parallel QA

Hopefully your guy is feeling PAIN in the current (dysfunctional) process because changing (to what we know is the right) process will also be painful.

 

From: [email protected] [mailto:[email protected]] 
Sent: Thursday, August 31, 2017 8: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 <http://www.xndev.com/> 

 

 

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