QA separate from development?

I agree that it is not a good idea, but would also like to hear the opinions of others.

Why do they want to separate QA and Development?

The Development Team includes everyone that contributes to the product increment, which often includes "QA engineers" and "developers".

As it stands, is the Development Team able to produce a "Done" (releasable) increment at least before the end of the Sprint ?

Is this just a reporting structure change? If so, it could be good. There is a notion of independence of SQA and there are three kinds of independence - financial independence, managerial independence, and technical independence. By having quality specialists report to a different management chain, it gives the SQA team managerial independence. This is often reflected in performance reviews and compensation - a development manager has less influence to punish QA specialists if they identify issues in the development process, for example. It may also support financial independence in that the budgets for the two organizations are independent and the parent organization needs to justify the impact of the budget on the impact to product quality. I'd need to know more, but on the surface, I tend to favor a separate management chain for software quality assurance specialists to give them independence and freedom to be able to speak their minds about product quality issues without fear of impact.

However, if this is a team composition structure change, I'd be very worried. Cross-functional teams are very important. A team should be able to deliver working, tested software every Sprint. Sometimes, this requires test and quality specialists on the team. If the idea is to move these specialists off of the teams and leave the teams without sufficient knowledge and skills to perform adequate testing of the work they are doing before the end of the Sprint, that would be concerning and I'd want to understand why the organization is interested in doing this and what the intended outcome really is.

Thank you all for the answers. It will be reporting change but it will not be just that. Honestly, I'm not sure what is behind. Just worried it will affect productivity and unnecessary hands offs and communication issues.

To respond to the question above, yes team is producing releasable increment. They have slips but I think that the release plan is too aggressive for these lean teams. There are space for improvement for both sides, dev and QA. I just think they should work tight together and work on improvements together. I'm not sure that will be the case now. Well we will see. I might post the update in month or two :)

Thanks again to all

In the company that I work there is a motion to separate QA team from development and QA to report to product line manager. I think it's anti-scrum but I would like to hear what others think about this. Could anyone give me pros and cons.

Is there any indication that the company you work for actually wishes to implement Scrum?

There is nothing in the Scrum Guide about management of personnel.  I have worked with Scrum Teams where individuals on the teams reported to different managers. But that reporting was for career development and "best practices".  There were managers for all of the UX personnel, backend developers, Product Owners, Scrum Masters, QA so that all disciplines were being represented equally in the corporate activities such as budgeting, personnel forecasts, etc.  But when it came to the actual work the Scrum Teams were self-managing and worked as a complete unit. 

I do feel your concerns are warranted.  While I described the ideal situation above, it wasn't always perfect. The separation of disciplines sometimes lead to managers trying to build their own kingdom and not taking into account the effect of their actions on other disciplines.  In the situation above our Scrum Master Manager was very good as a Scrum Master and the VP over all of that division respected their skills. The VP would often ask the Scrum Master Manager to help facilitate discussions of the managers and aid in communal goals across disciplines. 

Where I work, QAs and other engineers all used to be part of the same Scrum Team. There was one QA per Development Team, and they were responsible for doing the majority of testing.

We decided collectively that engineers would test their own (or each others) code.

To support this, our QAs moved outside of the Scrum Teams, and the other engineers filled the gap, so that each Development Team remained cross-functional.

They still have the same reporting structure, but their role changed. Now they help engineers learn and improve in writing tests and documentation, they take a more overall view of quality, and are better placed to trigger initiatives that address recurring defects, and drive up quality.

Daniel, I'm afraid that's the case here. I can just express my concern and nothing else. We will see hove that will end up. Thank you all for great comments! 

In the company that I work there is a motion to separate QA team from development and QA to report to product line manager. I think it's anti-scrum but I would like to hear what others think about this. Could anyone give me pros and cons.

Thanks

• Technically, there is no such thing as a "QA Team" in Scrum. This is indicative of speciality teams over cross-functional teams.
• The Development Team should be cross-functional to possess the skillsets and knowledge to deliver the Sprint Goal increment subject to the Definition of Done.
• Any dynamics of separate bosses, separate reporting, etc. can create dysfunctions in the team, and at worst, reinforce an us-versus-them mentality. Avoid this. This will only hurt the team's empowerment to truly being self-organizing and self-managing. 

Thank you Mike Miller, I agree and really like your answer. I hope they will realize and reverse the change

Happy New Year!  I'm in search of professional advice.  My team is striving to be agile, they call themselves agile, but it's simple, they are not.  Our issue is we are short staffed, taking on project work, production break/fix and adhoc requests.  With 9 developers and 1 QA, our sprints almost always carry points because QA (or Dev) wasn't completed.  What are your thoughts on how we should handle our sprints?  

My team is striving to be agile, they call themselves agile, but it's simple, they are not.

Who actually wants your team to be agile, and is in a position to create, communicate, and reinforce the sense of urgency needed for real change to happen?

Definition of the word agile from the Merriam-Webster online dictionary

1: marked by ready ability to move with quick easy grace - an agile dancer

2: having a quick resourceful and adaptable character - an agile mind

It seems you are basing your conclusion that your team is not agile because they carry work over from sprint to sprint.  To me that indicates that they are not using Scrum effectively but doesn't mean that they aren't agile.  If they are in fact able to take on production break/fix work I would assume that they are agile based on the above definition. 

You asked for thoughts on how to handle your sprints and this was my immediate reaction.   Stop doing Sprints and shift more to a Kanban method of managing your work.  Focus on limiting the work you have in progress by completing work before taking on new work. 

Second thought was split your team into 2 teams of 5 people and let one focus more on the project work while the other focuses on the production break/fix work.  Split the adhoc requests between the two.  The team doing break/fix work will not be able to plan Sprints because they will not know what work is going to be presented to them in the coming days.  But they can manage their work with Kanban practices of limiting Work In Progress and completing work before starting something new. 

A third option is for the team to focus on the work they said they would do during the Sprint and not take on new work.  In other words hold true to their Sprint Plan and satisfy the Sprint Goals.  I know this doesn't work for break/fix work but you should be able to handle the project work and adhoc requests in this manner.  Everything goes to the Product Backlog and is taken on as the team has the capability to do so. You may want to look at the history of break/fix work and try to allow some flexibility in the Sprint Planning to allow for that work to be accommodated while still planning out a body of work that would deliver a valuable increment inside the Sprint timebox. 

One parting thought. Every one of your break/fix activities should be retrospected to find the root cause. If you are getting a lot it could indicate that you have a problem with the quality of the work being done.  You might be able to prevent them by refactoring parts of the product, modifying your validation work to include more scenarios, or including more automated testing as part of the development work.  I have worked in more than one company where focusing on the technical debt that is being encountered has been used to increase the quality of the work and practices which resulted in increased capability to produce.  Technical debt comes in a lot of ways with bugs, shortcuts taken to deliver, and code that is difficult to test being just a few. It could also lead to changes in your refinement activities if the break/fixes are centering on unexpected scenarios or events.  You may need to take more time in refinement to discover these scenarios.  It may be that they were known but the team considered them to be "edge cases".  This can be symptomatic of the team not knowing how the users work and making assumptions on how the product will be used instead of actually learning from the users the expectations of how it will be used. 

@Jaca Perc I am curious how things worked out in your organization with the change of separating QA team from development team?