Project Management

Project Management Central

Please login or join to subscribe to this thread
Tell me about your experiences with integrating a QA resource into your Agile Scrumban team. Were you able to make it work? What are some of the lessons learned from doing this?
We've been challenged to produce Mobile Application updates frequently but, being one of the public faces of the company, they must work well with good quality. I've always believed in building Quality into the application vs finding issues after it we've finished the work. Embedding a QA resource is new to the organization so, naturally, there is resistance. It's already showing signs of success but I'd like to hear from the collective. Have you tried this? Did you make it work? What did you learn? Looking for ideas on quick victories.
Sort By:
All agile methods you use are driven by quality. So, you do not need any additional resource. Quality Control and Quality Assurance are implicit or explicit inside each agile based method.
Scott -

Someone that has been focused on QC type activities to date can be successfully integrated into an existing agile team if they are willing to move to a generalizing specialist approach and if they are willing to share their expertise in quality practices with the rest of the team. By doing so they will become more versatile and the overall quality of the deliverables produced by the team will increase.

On the other hand, if they stick to a pure specialist role, they are unlikely to fit well into the team.

A number of years ago at one employer, I ran a set of XP teams, and placed the assigned QA resource on-team, attending all the standups etc., and very closely located with the team as well. As coach, I explicitly gave her permission to decide when a user story was "done", and accepted. This worked very well, and she found it empowering.

In agile theory, the Product Owner or Customer role is supposed to accept or reject user stories as done. Sometimes though, the product owner role is not officially filled, and requirements come from a number of alternative sources. In a case like this, a QA resource can instead act as user story "doneness judge", and can at least perform user story acceptance. A business analyst or team of analysts can perform the other functions of the product owner.

This arrangement worked well for the teams I was working with at the time. It also gave the assigned QA resource a real and highly relevant role in the team, and certainly aided her assimilation into it. It also promoted QA from some sort of trailing activity into an integrated and important team member.

I'm not saying this was ideal, but it worked for us at the time. Something to consider.

Developers could easily resent a QA person being added to the team if his or her role is not clear, and if they suspect they will have someone looking over their shoulder as they develop. Having the QA person acting as the gatekeeper for formal story acceptance though keeps the roles separate. Your developers are less likely to resent this.
I agree with Kiron. It sounds as though you are wanting to develop a hybrid team of waterfall, and Agile, which depending ont he organization, may be fine.
The best QC integration I've had was when the QC analyst worked with a QC developer on developing automated functional test scripts. The coded software could be run against the automated scripts for immediate feedback and rework.
By the way, Robert, there are no quick victories. The only victories are the ones you had to work hard for.
All teams I work with are restructured to include QA resources--my reading of the formative works of various Agile methods is that all call for cross-functional teams that can deliver a fully developed and tested deliverable. The biggest challenge is timing: If the tester has to sit on their hands waiting for all of the developers to deliver, he or she will be overwhelmed at the end of the sprint and the team will only deliver a small fraction of its stories. The following techniques have proven successful at limiting this problem: test automation (per Stephan's comment), freeing the QA resource to focus on exploratory testing; acceptance-test-driven-development, with the QA person writing test cases before development begins; smaller stories, such that developers submit work for testing early and often throughout the sprint; and as Kiron mentions, cross-training such that developers can do low-level testing, and testers can do low-level development.

Please login or join to reply

Content ID:

"In three words I can sum up everything I've learned about life. It goes on."

- Robert Frost