[SCRUMDEVELOPMENT] Parallel QA

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Got this from a colleague. Curious what you all think I might tell him:

Hi Michael,

I had a question come up from a potential client and was wondering what your response to this would be, since you've led sessions about what to say to a reluctant developer: What do you say to a QA manager that thinks QA work should be done outside (after) the sprint? This individual maintains that there is not enough time in a two-week sprint to do both the development and QA work, unless the stories are made so small there is little to test, and that they should be done sequentially (they obviously have a very waterfall-like process of dev completing their work and then handing a story off in its entirety to QA.) What would you tell this person to bring them on-board with the idea of the whole team completing their work within the time box of the sprint?

Thanks!

[srinivas chillara [e-mail] [SCRUMDEVELOPMENT]]

Hallo All,(I'm taking the liberty to answer)Oh what a knotty problem this is!    
   Trite, even in 2017!

It will be critical that the client is in a 'listening' mode for the answer to be effective.
The explication I'd make is:0. This is waterfall.
1. W/F is a singularly poor approach to s/w development, amongst many reasons, a critical one is the fact that, we are trying to find "all/most" the issues at the worst possible time (at the end) of the project; by testing at the END.
2. So pushing testing activities to the future is reducing recovery (from mistakes) time for the entire project.
3. Testers can contribute more usefully by collaborating with programmers, in finding more bugs earlier, increasing efficiencies (and also effectiveness) for the entire group.

Potentially political hot-potato + a mild tirade

Ofcourse there are a couple of another aspects, but difficult to tell, when and with whom the following can be brought up:

1. QA managers sometimes think/believe that just finding a lot of bugs (never mind the relevance/impact) and flaging them at any point in time is their job, and to some gives a sense of power, The delivery to customers can go hang. So the purpose of the project is besides the point for such people. Partly the problem is with the incentives that have been set for the last decade or so, industry wide.
2. The reluctance to automate testing, and too much specialisation.....here in India we even have several species of testers (Manual, automated, front-end, performance... etc), with a deep belief that they are completley different animals (I notice they often don't even have lunch together, they might fear being eaten by the other type of animal)
3. Automation of testing doesn't mean 100% of testing activity is automated.
Anyway, people have to read Brian Marick, James Bach, Cem Kaner and James Whittaker, to understand 'testing'. An observant reader would have noted that I've studiously avoid the term 'QA' so far. "Quality Assurance" is heavily a process ownership role; This role has effectively disappeared from the landscape of the industry, though many are the people who approriate this into their title. The so called 'agile coaches' , or even better "Scrum Masters" or EACs (Enterprise Agile Coaches) might have partly covered it, but then many of them haven't really heard of Marick, Bach and Whittaker, have they?

And the poignant aspect here is: if people understand TDD well, then many of these Qs wouldn't really be head-scratchers in 2017, would they?
cheersSrinivashttp://www.scrumcoach.co.in
www.ceezone.net


PS: BTW, what is being suggested by the orginator of this question, is not parallel 'testing', but 'sequential' testing, isn't it?









From: "Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Thursday, 31 August 2017 1:49 AM
Subject: [SCRUMDEVELOPMENT] Parallel QA

  Got this from a colleague. Curious what you all think I might tell him:

Hi Michael,

I had a question come up from a potential client and was wondering what your response to this would be, since you've led sessions about what to say to a reluctant developer: What do you say to a QA manager that thinks QA work should be done outside (after) the sprint? This individual maintains that there is not enough time in a two-week sprint to do both the development and QA work, unless the stories are made so small there is little to test, and that they should be done sequentially (they obviously have a very waterfall-like process of dev completing their work and then handing a story off in its entirety to QA.) What would you tell this person to bring them on-board with the idea of the whole team completing their work within the time box of the sprint?

Thanks!

#yiv4766132960 #yiv4766132960 -- #yiv4766132960ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4766132960 #yiv4766132960ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4766132960 #yiv4766132960ygrp-mkp #yiv4766132960hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv4766132960 #yiv4766132960ygrp-mkp #yiv4766132960ads {margin-bottom:10px;}#yiv4766132960 #yiv4766132960ygrp-mkp .yiv4766132960ad {padding:0 0;}#yiv4766132960 #yiv4766132960ygrp-mkp .yiv4766132960ad p {margin:0;}#yiv4766132960 #yiv4766132960ygrp-mkp .yiv4766132960ad a {color:#0000ff;text-decoration:none;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ygrp-lc {font-family:Arial;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ygrp-lc #yiv4766132960hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ygrp-lc .yiv4766132960ad {margin-bottom:10px;padding:0 0;}#yiv4766132960 #yiv4766132960actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4766132960 #yiv4766132960activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4766132960 #yiv4766132960activity span {font-weight:700;}#yiv4766132960 #yiv4766132960activity span:first-child {text-transform:uppercase;}#yiv4766132960 #yiv4766132960activity span a {color:#5085b6;text-decoration:none;}#yiv4766132960 #yiv4766132960activity span span {color:#ff7900;}#yiv4766132960 #yiv4766132960activity span .yiv4766132960underline {text-decoration:underline;}#yiv4766132960 .yiv4766132960attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv4766132960 .yiv4766132960attach div a {text-decoration:none;}#yiv4766132960 .yiv4766132960attach img {border:none;padding-right:5px;}#yiv4766132960 .yiv4766132960attach label {display:block;margin-bottom:5px;}#yiv4766132960 .yiv4766132960attach label a {text-decoration:none;}#yiv4766132960 blockquote {margin:0 0 0 4px;}#yiv4766132960 .yiv4766132960bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv4766132960 .yiv4766132960bold a {text-decoration:none;}#yiv4766132960 dd.yiv4766132960last p a {font-family:Verdana;font-weight:700;}#yiv4766132960 dd.yiv4766132960last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4766132960 dd.yiv4766132960last p span.yiv4766132960yshortcuts {margin-right:0;}#yiv4766132960 div.yiv4766132960attach-table div div a {text-decoration:none;}#yiv4766132960 div.yiv4766132960attach-table {width:400px;}#yiv4766132960 div.yiv4766132960file-title a, #yiv4766132960 div.yiv4766132960file-title a:active, #yiv4766132960 div.yiv4766132960file-title a:hover, #yiv4766132960 div.yiv4766132960file-title a:visited {text-decoration:none;}#yiv4766132960 div.yiv4766132960photo-title a, #yiv4766132960 div.yiv4766132960photo-title a:active, #yiv4766132960 div.yiv4766132960photo-title a:hover, #yiv4766132960 div.yiv4766132960photo-title a:visited {text-decoration:none;}#yiv4766132960 div#yiv4766132960ygrp-mlmsg #yiv4766132960ygrp-msg p a span.yiv4766132960yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4766132960 .yiv4766132960green {color:#628c2a;}#yiv4766132960 .yiv4766132960MsoNormal {margin:0 0 0 0;}#yiv4766132960 o {font-size:0;}#yiv4766132960 #yiv4766132960photos div {float:left;width:72px;}#yiv4766132960 #yiv4766132960photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv4766132960 #yiv4766132960photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4766132960 #yiv4766132960reco-category {font-size:77%;}#yiv4766132960 #yiv4766132960reco-desc {font-size:77%;}#yiv4766132960 .yiv4766132960replbq {margin:4px;}#yiv4766132960 #yiv4766132960ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv4766132960 #yiv4766132960ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv4766132960 #yiv4766132960ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv4766132960 #yiv4766132960ygrp-mlmsg select, #yiv4766132960 input, #yiv4766132960 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv4766132960 #yiv4766132960ygrp-mlmsg pre, #yiv4766132960 code {font:115% monospace;}#yiv4766132960 #yiv4766132960ygrp-mlmsg * {line-height:1.22em;}#yiv4766132960 #yiv4766132960ygrp-mlmsg #yiv4766132960logo {padding-bottom:10px;}#yiv4766132960 #yiv4766132960ygrp-msg p a {font-family:Verdana;}#yiv4766132960 #yiv4766132960ygrp-msg p#yiv4766132960attach-count span {color:#1E66AE;font-weight:700;}#yiv4766132960 #yiv4766132960ygrp-reco #yiv4766132960reco-head {color:#ff7900;font-weight:700;}#yiv4766132960 #yiv4766132960ygrp-reco {margin-bottom:20px;padding:0px;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ov li a {font-size:130%;text-decoration:none;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv4766132960 #yiv4766132960ygrp-sponsor #yiv4766132960ov ul {margin:0;padding:0 0 0 8px;}#yiv4766132960 #yiv4766132960ygrp-text {font-family:Georgia;}#yiv4766132960 #yiv4766132960ygrp-text p {margin:0 0 1em 0;}#yiv4766132960 #yiv4766132960ygrp-text tt {font-size:120%;}#yiv4766132960 #yiv4766132960ygrp-vital ul li:last-child {border-right:none !important;}#yiv4766132960

['[e-mail]' [e-mail] [SCRUMDEVELOPMENT]]

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
unless the stories are made so small there is little to test

This is a good illustration of what can cause local optimization. In the big picture, having little to test is a *good* thing!

—mj
(Michael)

[Alexander Kriegisch [e-mail] [SCRUMDEVELOPMENT]]

Miyamoto Musashi, a famous Japanese rōnin samurai and writer who lived 1584-1645, wrote in his famous "Book of the Five Rings" in a chapter about about learning how to fight with two swords at the same time (his signature technique):

"It will seem difficult at first, but everything is difficult at first."
I have coached many teams during the last 12 or so years, and almost all them thought they could not do dev and QA within one sprint. But sooner or later they all proved themselves wrong. And by the way, small stories are not the problem but part of the solution.
--
Alexander Kriegisch
https://scrum-master.de

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Hi Michael,
I had a question come up from a potential client and was wondering what your response to this would be, since you've led sessions about what to say to a reluctant developer: What do you say to a QA manager that thinks QA work should be done outside (after) the sprint? This individual maintains that there is not enough time in a two-week sprint to do both the development and QA work, unless the stories are made so small there is little to test, and that they should be done sequentially (they obviously have a very waterfall-like process of dev completing their work and then handing a story off in its entirety to QA.) What would you tell this person to bring them on-board with the idea of the whole team completing their work within the time box of the sprint?
Thanks!
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[srinivas chillara [e-mail] [SCRUMDEVELOPMENT]]

Sagacious indeed!

However, in my experience there is only a slim possibility that the audience (traditional QA manager) will recognise the depth of that comment. The traditional QA manager doesn't care too much about developing s/w. If (s)he were, then a deep dive into how/why programmers+analysts make so many mistakes/bugs would have long ago led them to the realisation that testing should be done, early and often.
In this case, I would even argue that it is actually not very difficult, in fact it is quite easy, to do testing in parallel;...people are a bit blind..., I think this is a case where we are trying to hack a tree, with a chain-saw.

cheers
SrinivasChillara Srinivas is a Scrum Coach, Scrum Trainer, XP, TDD, Test Driven Development, Scrum Training, consultant and trainer, Scrum implementation, Project Management Proficiency, PMP, Pune, India


|
|
|
| | |

|

|
|
| |
Chillara Srinivas is a Scrum Coach, Scrum Trainer, XP, TDD, Test Driven Dev...
Chillara Srinivas Srinidhi is a Scrum Coach, Scrum Trainer for Scrum, XP, TDD (Test Driven Development), consult... | |

|

|




From: "Alexander Kriegisch ***@Scrum-Master.de [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Thursday, 31 August 2017 9:15 AM
Subject: Re: [SCRUMDEVELOPMENT] Parallel QA

Miyamoto Musashi, a famous Japanese rōnin samurai and writer who lived 1584-1645, wrote in his famous "Book of the Five Rings" in a chapter about about learning how to fight with two swords at the same time (his signature technique):
    "It will seem difficult at first, but everything is difficult at first." I have coached many teams during the last 12 or so years, and almost all them thought they could not do dev and QA within one sprint. But sooner or later they all proved themselves wrong. And by the way, small stories are not the problem but part of the solution.-- Alexander Kriegischhttps://scrum-master.de


Am 31.08.2017 um 03:19 schrieb Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT] <***@yahoogroups.com>:


Got this from a colleague. Curious what you all think I might tell him:

Hi Michael,

I had a question come up from a potential client and was wondering what your response to this would be, since you've led sessions about what to say to a reluctant developer: What do you say to a QA manager that thinks QA work should be done outside (after) the sprint? This individual maintains that there is not enough time in a two-week sprint to do both the development and QA work, unless the stories are made so small there is little to test, and that they should be done sequentially (they obviously have a very waterfall-like process of dev completing their work and then handing a story off in its entirety to QA.) What would you tell this person to bring them on-board with the idea of the whole team completing their work within the time box of the sprint?

Thanks!



------------------------------------
Posted by: Michael Wollin <***@mercurysw.com>
------------------------------------

To Post a message, send it to:   ***@eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com
------------------------------------

Yahoo Groups Links

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Michael,

I think that QA work should start *prior* to development. After
development, all you can do is QC. I find that teams doing BDD often
discover problems during the Three Amigos meeting when the tester
questions the assumptions being made and brings up unforeseen scenarios.
Once anticipated, these scenarios can be covered with automated checks,
freeing the tester for less mundane testing of the functionality as it
becomes available.

That said, before I tried to convince this manager, I would want to have
some discussions about what the manager finds valuable, what they see as
the role of the QA department, and what value that role brings to the
business. This manager is trying to protect something that they find
valuable, and without knowing what that is, I don't know how to reassure
them that this valuable thing can be preserved while working in a
different way.

- George

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Hi Michael,
I had a question come up from a potential client and was wondering
what your response to this would be, since you've led sessions about
what to say to a reluctant developer: What do you say to a QA manager
that thinks QA work should be done outside (after) the sprint? This
individual maintains that there is not enough time in a two-week
sprint to do both the development and QA work, unless the stories are
made so small there is little to test, and that they should be done
sequentially (they obviously have a very waterfall-like process of
dev completing their work and then handing a story off in its
entirety to QA.) What would you tell this person to bring them
on-board with the idea of the whole team completing their work within
the time box of the sprint?

[Matt Heusser [e-mail] [SCRUMDEVELOPMENT]]

"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

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

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

"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 <http://www.leanpub.com/SaveOurScrum>

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

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: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, August 31, 2017 7:42 AM
To: ***@yahoogroups.com
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 ***@gmail.com<mailto:***@gmail.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> 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,

['Richard Hundhausen' [e-mail] [SCRUMDEVELOPMENT]]

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: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, August 31, 2017 8:42 AM
To: ***@yahoogroups.com
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 ***@gmail.com <mailto:***@gmail.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com <mailto:***@yahoogroups.com> > 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

[[e-mail] [SCRUMDEVELOPMENT]]

Hello Michael,


In line with what Srinivas and Alexander say - I would say that your colleague ought to arrange to take the QA manager to visit as many teams as possible - either within the company or outside and show him half-a-dozen teams - who can demonstrate how they do dev + test within a sprint.

Seeing it being done by multiple teams will be what will make him re-consider, IMHO. Everything else may be just pre-disposition, speculation & conjecture on the QA manager's part.


Somehow this quote by Upton Sinclair also comes to mind: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”


Am curious what happens to/for the QA manager - if dev + qa within a sprint does work? What part/s of the SCARF model does it upend for him?


Good Luck to your colleague on his quest.......


With Best Regards


Shyam