The good, the bad and the ugly standup
Excluding QA wasn&#x27;t a plus. Quality works better when there&#x27;s an advocate from the beginning.<p>Problem is a lot of companies only engage QA for post-build integration testing. They try to phase it as a mini-waterfall within the agile cycles, which doesn&#x27;t play well with agile and drags the process. At that point, leaving them to their own horizontal meetings seems like a plus, but there&#x27;s a ton of opportunity cost for not having them in the primary conversation.<p>Other companies try to leverage QA for unit tests, but those really should be written by whoever wrote the interface as part of ensuring their intended contracts are fulfilled. That makes unit test writing not really a good QA role, other than making sure they&#x27;re there.<p>The exception would be if you&#x27;re going to pull QA in and pair-program&#x2F;test TDD style--which is its own potential boondoggle. But you need real SDETs at that point, as opposed to scripters. Real SDETs aren&#x27;t terribly common, and are not terribly cheap as they&#x27;re niche specialists.<p>The best solution I&#x27;ve seen is to split the advocacy&#x2F;short-term roles and the test&#x2F;architecture&#x2F;long-term development roles (even if it&#x27;s two hats on one person), have them in the meeting for the former and have the horizontal run their own projects with milestone syncs for the latter.<p>At that point you can treat the short-term role as a team member, and the long-term roles as an internal vendor or external dependency (i.e. no expectation of control). Any sort of one-size-fits-all approach won&#x27;t work.