Scrum Teams without QA Department?

[Benjamin Martin]

Does anyone have specific information about Scrum teams that do not
have a distinct QA role, but instead, all developers are equally
responsible for testing? I have heard of companies doing this
successfully, but I don't have any documentation and can find very
little on the topic.

Can an Agile organization improve its quality by axing the QA
department? The Scrum Guide says the following about the Scrum Team:

"Everyone chips in, even if that requires learning new skills or
remembering old ones. There are no titles on Teams, and there are no
exceptions to this rule. Teams do not contain sub-Teams dedicated to
particular domains like testing or business analysis, either."

I would love to hear experience or thoughts about organizations that
do Scrum without a separate and distinct QA testing team.

Thanks!

[gamsjo]

In the best Scrum teams I have seen they do not have roles or titles.
But everybody have a "primary skill". For the team to have a firm and
strong Definition of Done they also need to have a lot of skills in
the QA area. If possible the team should also have domain experts that
can do system level tests.

[Stefan Roock]

Hi,

>Does anyone have specific information about Scrum teams that do not
>have a distinct QA role, but instead, all developers are equally
>responsible for testing? I have heard of companies doing this
>successfully, but I don't have any documentation and can find very
>little on the topic.

I have worked in Scrum teams that only had "programmers" who were responsible for delivering the product DONE incl. testing. It worked.

I would love to hear experience or thoughts about organizations that 

do Scrum without a separate and distinct QA testing team.

As far as I know Salesforce killed the QA department and integrated the testers completely into the Scrum teams. And they were successful.

I have seen that pattern at several of my clients. Killing the QA department and integrating the testers into the Scrum teams enhanced collaboration and increased quality.

Stefan

 

Thanks!

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
http://stefanroock.de

[Steven Mak]

I have visited companies where they have a separate testing
department... that really sucks... Not only they have a separate QA
department... but they also have a separate Architecture department...
so their development goes like:

Architecture -> Coding -> QA

Does that sounds like the traditional waterfall development? even
though they have "sprints" during their "coding phase"

so... at least... the advantage of having testing (and other
functions) incorporated into the team is to avoid situations like the
above.

[Benjamin Martin]

Perhaps I should state more clearly, to distinguish the difference,
that I am not talking about just integrating QA people into the scrum
team. I am talking about completely eliminating the title or role of
QA tester from the organization, so that developers themselves are
responsible for this work. My feeling is that this would make for more
efficient teams that truly owned the quality of their code.

[Tim Korson]

1. Yes, I agree that the title or role of QA tester should be eliminated from the organization, and yes there are case studies demonstrating that this works. However, in spite of the fact that no set of individuals or organization owns testing, some individuals will have more interest and expertise in testing than others, and will more often take on the independent verification tasks. Doing away with the tester role does not do away with the principle of independent verification. The person who develops a feature should not be the only one to test that feature.

2. Some agile organizations transform the old QA department into a QA facilitation center. This center can manage assets such as usability labs, server farms for testing scalability, etc. These assets are too expensive to be owned by every team, but are needed by each team. A corporate QA facilitation and resource center can work well in an aggressively agile organization.

[Rafael Sabbagh]

Hi Go See Gemba,

you said:
> - training/appointing as scrum masters people with qa experience

Why?

Best regards,

Rafael Sabbagh
Agile Trainer & Coach
Certified Scrum Trainer (CST)
________________________
Sabbagh Training & Coaching
Rio de Janeiro - Brazil
+55 (21) 9999-7895
http://rsabbagh.com
http://facebook.com/SabbaghTC
@rsabbagh

On Sep 23, 2012 9:55 AM, "Go See Gemba" <gosee...@gmail.com> wrote:

I am managing a large QA department is a sw company, and, since recently facilitating the transitionto Agile of the whole company.

I can tell you my experience.

When it was very small, did not have any QA team and was doing some kind of XP (but with very little tdd!). The amoung of bugs delivered to the customers was significant. I was one leading one of these teams.

So we decided to set-up a strong and "indipendent" department. After hired an unsuccessful qa-old-fashion gure the company appointed me: having solid dev management expertise I was in the position of creating teams with massive automated testing and strong independence. After few years (and still now) I was managing a large number of teams spread worldwide. The quality of our products is pretty good. But, recently we decided to become more and more agile and I felt in love with scrum...

Things we are doing:

- moving all the automated-testers into the scrum team (does not make sense to have two places were you create automated testing)

- have much smaller user-testing team (with no automation/regression tasks, but strong focus on customer scenarios, integration).

To encourage dev team to embrace quality more seriously, I am doing basically these main steps:

- training/appointing as scrum masters people with qa experience

- best individuals in qa with strong business analysis are moved to help the POs

- passed all the "qa material": i.e. test scripts, tools, artifacts to the increased dev teams.

Of course this needed a cultural preparation and a lot of study/thinking about your organisation, the people you have, etc. The preparation took about 1 year and now I have just started the above steps with a subset of my teams.

When the transition will be complete I will have perhaps 75% of my current people not reporting to me anymore and much much less power in my organisation (perhaps will have to look for another job). But definitely I consider this a healthy evolution for any sw company.

It would be nice to hear from people with similar level of responsability about their experience and how they are re-designing their organisation and their role....

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/IiWwtSt9rSkJ.

[Michael James]

Sounds like some good steps.  By giving up some power, I think you'll actually increase your influence.

Testing is front and center when doing Scrum properly.  During the Sprint Review Meetings, I encourage Product Owners not to declare a PBI "done" unless it has been properly tested during the Sprint, along with any previous work that may have been broken by the new work.  The only practical way to do this is to automate all regression testing, ideally using the same languages, tools, and technologies the product itself is built in.  Which leads to TDD....

--mj

http://ScrumTrainingSeries.com

[Go See Gemba]

I am speaking about specific people that were particualrly multi-skilled and influential too. Usually, developers you find in the industry are very good in coding, but they often lack of many skills. The people I've selected were  a mix of 33% technical, 33% business/user-facing, 33% nice-influential people). You are going to find this kind of people mostly among qa people: this works, at least in organisation that have invested in qa hiring there very excellent people (unfortunately many companies do not do this as many still think of qa as a sendonary point).

 

Regards,

Silvio

[andrej...@gmail.com]

Hi Benjamin,

we are experimenting with the approach of having no QA person in the team. We came to this idea naturally, but only after almost two years. 

Main things that i learned out of this:

1. you must have extremely high level of test automation

2. you must have automated deployment and integration testing

3. i wouldn't try this approach with teams that are working with a lot of UI and difficult workflows (the team i am talking about now is working on technical components)

4. you must have a strong QA who will show/educate the team HOW qa must be insured and implement critical parts. In our case we had QA in this team and just later he decided to switch his career and became a Product Owner of the team. So, i would say you must have a QA first and then when he educated the team he can leave, but it takes time

[RonJeffries]

Hi Anrej and all,

On Sep 25, 2012, at 6:02 AM, "andrej...@gmail.com" <andrej...@gmail.com> wrote:

we are experimenting with the approach of having no QA person in the team. We came to this idea naturally, but only after almost two years. 

Main things that i learned out of this:

1. you must have extremely high level of test automation

2. you must have automated deployment and integration testing

3. i wouldn't try this approach with teams that are working with a lot of UI and difficult workflows (the team i am talking about now is working on technical components)

4. you must have a strong QA who will show/educate the team HOW qa must be insured and implement critical parts. In our case we had QA in this team and just later he decided to switch his career and became a Product Owner of the team. So, i would say you must have a QA first and then when he educated the team he can leave, but it takes time

I would put it this way: 

The project needs tests. For rapid progress, they need to be automated. Anyone can write and run automated tests.

The project also likely needs manual exploratory testing. While this is best reduced as much as possible, it may not be able to be reduced to zero. Skilled testers are good at this exploration, often amazingly better than programmers are. (There is nothing more frustrating than exposing one's ideas or program and having them break it with a few touches. But it makes the product better.)

The project will probably benefit from the inquiring (not to say paranoid) outlook of a person with testing focus. 

For all these reasons, the project needs testing skills, and high order skills are better. Scrum does not have the role of QA. Scrum demands that we have all necessary skills on the team. 

Ron Jeffries

www.XProgramming.com

I'm really pissed off by what people are passing off as "agile" these days.

You may have a red car, but that does not make it a Ferrari.

  -- Steve Hayes

[Michael James]

On Sep 25, 2012, at 5:03 AM, RonJeffries <ronje...@acm.org> wrote:

The project also likely needs manual exploratory testing. While this is best reduced as much as possible, it may not be able to be reduced to zero. Skilled testers are good at this exploration, often amazingly better than programmers are. (There is nothing more frustrating than exposing one's ideas or program and having them break it with a few touches. But it makes the product better.)

The project will probably benefit from the inquiring (not to say paranoid) outlook of a person with testing focus. 

For all these reasons, the project needs testing skills, and high order skills are better. Scrum does not have the role of QA. Scrum demands that we have all necessary skills on the team. 

+1

--mj

(Michael)