Dealing with less competent agile team members

Question

The company uses JIRA for 3 week sprints.

Team members are virtual with one QA tester who does all the testing that she documents as subtasks for each story.

Developers must validate their changes by doing their own unit testing on the product and then she does the user acceptance testing with users. I know this is contrary to the agile guidelines but her limited technical acumen means she is incapable of doing anything more than user testing.

She participates in all the events -grooming, reviews and demos. But she is heavily dependent on the other team members, calling several "hand off" meetings to go over the simplest changes and sending a high number of unnecessary chat messages and emails.
These are disruptive and annoying.

The dev manager will not do anything because she reports to the director (his boss) and he is the kind of middle manager who would never complain!

What can we do as a team to manage this without this looking like a pile on?

Every time she sends me a chat message I ask her if she would like any help. Usually the answer is "No, I just wanted to update you." and my response of "Ok, next time please just update the ticket" never works!

Answer 1

A remark first: this person is not "less competent", they simply have a different job than yours.

Their job requires communication.

The question is how to get them to communicate in a way that does not disturb you.

You have told them what you prefer. They did not listen. The next step is to bring that up in whatever improvement process you have in place. A retrospective meeting for example.

Don't point fingers and stay neutral. "I get a lot of messages" is an easier problem to solve than "Alice sends me a lot of messages". One is factual, the other is accusatory. Stay factual and you should be able to solve this in your feedback process.

Answer 2

Developers must validate their changes by doing their own unit testing on the product and then she does the user acceptance testing with users. I know this is contrary to the agile guidelines but her limited technical acumen means she is incapable of doing anything more than user testing.

I don't understand this statement. If you have somebody on the team who's role is to do user testing then it makes sense that this would be their core skill. They provide the user testing capability for the team.

But she is heavily dependent on the other team members, calling several "hand off" meetings to go over the simplest changes and sending a high number of unnecessary chat messages and emails.

It is not unusual for user testing to require a lot of communication. Quality and testing is a team activity, not something that just gets instantly handed over to a tester. A great deal of interaction is common to ensure that requirements are understood and that in-sprint releases and bug reporting is done effectively.

What can we do as a team to manage this without this looking like a pile on?

Typically concerns such as this will be raised at the team's retrospective. If you are finding it difficult to cover this kind of issue without 'looking like a pile on' then it would be worth taking a step back and looking at how your retrospectives are run. For the team to be a success you need to be able to address issues without making them in to personal attacks.

Every time she sends me a chat message I ask her if she would like any help. Usually the answer is "No, I just wanted to update you." and my response of "Ok, next time please just update the ticket" never works!

One of the values in Agile is individuals and interactions over processes and tools. Typically we encourage communication and openness, rather than relying on updates on a tool such as JIRA. However, if the communication is distracting then it certainly warrants a retrospective discussion to see if there is a way to adapt the team's approach to make this less of an issue.

Answer 3

Problem Statement: If I understood your issue correctly, then it is that QA engineer not able to understand and perform testing efficiently without multiple inputs and help channels.

Analysis: Well what's missing is, How are these tasks defined and communicated? If the user stories are defined in well format explaining the tasks in functional and technical perspective with supporting documents then it can be taken to next level. It is team's responsibilities to agree upon and maintain the protocols for different functions. Like Task definition must include user story which defines what is required with all supporting valid documents:

1. Workflow document
2. UI/UX design guide
3. Sequence diagrams/Screenflow designs
4. API Signatures and methods
5. Sample working data(URL, Username/Password, inputs for initiating work)
6. Environments in scope
7. Any other input vital for task definition

Based on task definition clear and precise acceptance criteria must be defined. With all inputs Testing team must be able to come up with test plan and test cases, these test cases can be reviewed by development team members to provide confirmation or suggest modifications. Testing team can publish brief test execution plan and steps which can provide insights on how they can validate the release made to them. All this should enable testing team members easily understand the task and scope of testing. Training them with right tools to use and demonstrating how the task can be verified in any given environment once with suggested steps to reproduce the same in other environments and Expected QA test report format can be very important for everyone in the team.

Training is most commonly used but least practiced word. Publishing correct steps and document for team development is as imp as any other development task. Invest time in training by publishing correct guidelines and documents, If team member is still unable to cope up, report it in appropriate way as then you are left with no other option.

Answer 4

Since you are "stuck" with this person, your other option is to improve their skills. One possibility is to pair them with a different dev each sprint, along the lines of my answer here: https://pm.stackexchange.com/a/27497/37642. Another is to put in cross-training stories, so each sprint includes formal cross-training between one dev and this person. Look for "Cross-Training" here on the Full Stack Scrum site (free and open source).

But ultimately under the Agile philosophy, the answer best fitting a "self-organizing team" might be: Bring the issue up openly and honestly in a Retrospective and let the group figure it out. I started out in tech creating "self-directed work teams," doing science-based teambuilding, and based on your comments I do not believe you can solve this without braving some conflict. Either:

• The rest of the team confronts the individual during the Retro and works out another role for the person that fits their skills--user experience design, business analysis, technical documentation, etc.
• You confront your manager, demanding the person be transferred to a more fitting position.
• You go over your manager's head and make the same demand of the person's boss.

I don't know where you are (what culture you are in), so I realize this may seem impossible. If you cannot confront the situation, I see no other option than refusing as a team to give this person tasks they can't do. Perhaps the person will get bored and leave on their own.

In my teambuilding days, I wrote a book about creating a high-performance team, which I now give away as a free Web site. I still use it's structure with Agile teams today. You may find the Conflicts page helpful.