QA/Dev dilema or How do we hand work off from dev to QA?

[Pat O]

I am aware that in an ideal agile world our QA resources would be part
of our product development teams and this would not be an issue.
Unfortunately our QA people are more agile than that :-).

Here is the situation;
* We have three product teams that are fixing bugs and working on new
functionality. These teams are fairly static, though there is a
little churn based on company priorities.
* We have a QA team whos members move from product team to product
team on an as needed basis. We tend to push full regression tests on
one product, then move people to the next product to do regression
testing there while the dev team "catches up". This means that the QA
folks are moving pretty constantly.
* Our dev teams run in sprints of about 4 weeks. (Different product
groups have different sprint lengths)
* Our QA team runs in 1 week sprints (no gaps)

What we would like to do is have the Backlog items marked as ready for
test (probably a status), have a QA person test the functionality and
mark the item as closed, or move the status back to in progress if it
needs more work.

Issue that have been raised about this;
* The work will not showup in various reports while waiting for
testing from the QA team (remember it may take a week or two for QA to
get around to some of this testing)
* QA folks don't want to have to go looking for work in the different
projects
* QA folks want to be able to leave a backlog open if there is an
issue with the test plan


Any suggestions?
Pat O

[Skip Angel]

Hi Pat,

I need to ask why QA is a separate team if you know that would be
ideal.

In Scrum, there is an expectation that the delivery team has all of
the people responsible for getting functionality for a product to
"potentially shippable product increment" state every sprint.

In order to accomplish this goal, the team needs to do the testing
activities necessary to meet their standard of quality to have
something that is shippable.

Can QA support the product teams in this arrangement? Given my
experience with other teams, I have not seen it work well. In fact, I
have found that QA is always a sprint behind (at least) from the team.
So, it strikes me as curious that the dev team is catching up. How
is that possible if there is new work to be tested?

Also, even if things are working pretty well is that sustainable for
the people in the QA team? How often do they task switch between
projects? How many hours do they work in each week? It sounds
pretty complex and chaotic the way you are describing their agility
;-)

I think many of your issues would go away if you integrated QA into
each of the product teams.

In addition, I am wondering if throwing it over to the wall for QA has
been working well for you? I have found that handoffs between teams
(and the processes/tools to support this) take more time than if the
teams were collocated working through the tests together. As well,
the fix and build cycles would be much less because the team is on the
same page on what needs to be fixed and work correctly.

Skip Angel
Agile Coach
SolutionsIQ
www.solutionsiq.com

[Kevin S.]

The concept of "marking" items across projects with an attribute that
is easily reportable is something I'm proposing in another thread:
http://groups.google.com/group/versionone-users/browse_thread/thread/3db158e1c048eb86#

If you think it might help, feel free to weigh in.

As for your suggestion, it is a good stop-gap to helping the problem
(until you can find a way to align QA resource cycles with the dev
teams).

1- For your first question, I'm not understanding what reports these
items would disappear from. Without more background, I'm assuming it
has to do with your implementation and structure in V1.

2- QA folks SHOULD be looking for work in different projects. The dev
team works within a project and the QA resource is behaving as a team
member during that short window of time. The fact that they don't
"want to" is an adjustment they should probably make. Whatever
structure the dev team they are supporting is using, they should be
using. As a matrixed resource, they have an overhead to support and
live in the team's structure even if that is different from team to
team. Not knowing your project structure/implementation... that would
be my gut response to QA. (I used to be a matrixed UX resource, so I
understand the pain they feel).

3- This is where Skips points become a real issue. I can bend my
agile rules to support matrixed resources so that QA folks float. But
allowing them to leave a backlog item open because they aren't ready
creates an impediment for the team. They either need to add a task
stating "update test plan" and whatever else (taking responsibility of
that item's next steps), or they need to be ahead of the dev team with
test plans just like the product owner/analysts/user experience folks.

Good luck!