Diversity and cross functional team issues

Hi Eesha - Are you the Scrum Master for the team?  If so are you teaching them the "why" behind the importance of a "Done" Increment at the end of the Sprint, and coaching them to become a more cross functional Development Team? 

I am wondering if there might be a way to have a conversation about Scrum Values with the Development Team, and tie this to the importance of being cross functional and how to get to "Done"?  Give them the challenge and ask them to solve it?

This might result in multiple user stories in progress and in the end nothing is done. Have you faced situation like this and if yes how did you handle it?

I think you already seem to recognize that work in progress ought to be limited, so that situations like this can be avoided. What response have you had so far when trying to get the team to define and observe WIP limits?

I ultimately get the team to focus on getting things to done so that we do not end up with multiple user stories in progress but focus on finishing work. Of course this takes a lot of explaining and pushing. But still I see them discussing the same topic again specially in the retrospective. Developers often think that testers have a different mindset and are specialized in testing and hence they can test better than developers. Hence they should be the only one testing (excluding automated testing). So when a tester is away for a day or two, they want to wait for him to come back and test the user story.

Another reason they give for the same is if we test for him now, the tester will have nothing to do when he is back. The tester can of course maybe not do development but he can always do automation etc which is the reason i give to the team to still go ahead and test.

Eesha,

This is a common situation with Scrum teams both mature and new.   I have found some success by repeatedly placing the focus on the item in play, and away from individuals within the Development Team.

A good discussion around "flow", WIP, and context-switching can provide your team with enough of a foundation that you can then press them when items seem to be idle.   Questions like "What can we do as a team to move this item forward?" may no longer be met with shrugs, but with offers to help.

Also, as a team, it is important that they understand that it is all about the baton, and not the runners.   Guide the team away from premature optimization thoughts (how can we keep everyone busy), and more towards what needs to be done to keep work items flowing towards "Done".

Is a short cycle time important to the Product Owner?

Perhaps it helps to explain to the Development Team how important it is to release quickly, and that getting a WIP item to the customers today, may be more important than getting two items to the customers next week.

If the team understand the importance of a short cycle, they could be motivated to reduce cycle time wherever possible. Not testing while testers are on holiday, may be identified as a delay that can be removed in a straight-forward way.

Thanks for the various advice. Though tried before. I will definitely try to have continuous discussions around "flow", WIP, short cycle time etc with the team and PO until the goal is met :)

Eesha,

What we do in our team is every sprint, we spare some time (20% of the sprint) to focus on cross training and enabler work. We have weekly tech forum calls where each team member present to the rest of the team on one of the items that will help cross training others and we also have 1:1 training sessions as well. 

Also, I think you do not need to create multiple user stories to track testing work. They should be a part of the development user stories. Testers can use the story to attach their test cases and test runs. 

Great post and suggestions. 

-Anuj 

Hi Eesha,

I have faced a similar issue - developers are not really inclined towards performing the QA role. First of all, try explaining to them - why we call the group "Development Team". There are no separate labels for devs, testers, etc. Each and every team member has to support the functionality throughout its lifecycle. Next step would be to encourage QA to pick up a story and start build, while in parallel developers will be testing code written by their peers. Goes without saying, QA will explain the process and have proper training sessions for rest of the team.

Yes, you will face some resistance (since it is obviously a challenge!) but a few sprints down the line, it will be worth it!

Also, as Anuj pointed out, you need not have separate stories for testing. If at all required, you can create tasks under the story only for tracking purpose.

Regards,

Adwait.