Project Management Central
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. Saving Changes...
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. Saving Changes...
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. Saving Changes...
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. Saving Changes...
"Ambition is like a frog sitting on a Venus Flytrap. The flytrap can bite and bite, but it won't bother the frog because it only has little tiny plant teeth. But some other stuff could happen and it could be like ambition."