Problem with in Scrum team - with seniors

Question

I have been working in a Scrum team for more than 1 year. As this is my first job and have no previous experience so can't compare with anything else, so thought of asking here.

We have a basic Scrum team setup. Total 7 engineers, 5 developers, 1 QA and one designer. 3 developers are seniors with +4yr experience, and 2 I and another are juniors, 1yr experience.

We do sprint planning, estimate stories. But the seniors don't much work. We juniors do at least 60+% of the work in each sprint.

I have below problems, if any body can guide with them all.

1. Seniors don't work but take all the credit.
2. People outside of team don't know who worked on what, like management and other teams. So they think all work is done by seniors.
3. They pick a story, and keep it with them for two whole weeks and just make them self look busy.
4. Scrum master praises them in meetings, I don't know why.
5. They have good communication skills, so they just communicate well and every body thinks they did all the work.

I want to know.

1. Is this common in Scrum teams?
2. What can I do in this scenario.
3. If I raise a complain to Scrum Master, he will just say that Scrum is all about team, team works not individuals.
4. Any guide you can give me if you have ever been in a situation like this.

Thanks.

Answer 1

Parts of your question smack more of a workplace issue than a Project Management issue, but I'll answer what I can.

Is this common in Scrum teams?

Doesn't really have anything to do with Scrum. What you describe above, assuming the problem actually is as you describe (neither exaggerated nor misunderstood/misrepresented), is an issue with the workplace, not the methodology.

What can I do in this scenario.

Don't just bring it up to your ScrumMaster. Bring it up in the retrospective. This is an issue that affects the whole team, and thus should be visible to the entire team.

If I raise a complain(sic) to Scrum Master, he will just say that Scrum is all about team, team works not individuals.

This applies primarily outside the team. Within the team, the team itself still has to deal with intra-team issues. To take a hypothetical, extreme example, if someone in the team is slacking off, spouting off racist/offensive remarks, and throwing garbage everywhere, it's not like the problem can just be entirely ignored just because the other team-members are cleaning up after him/her. Yes, it can be considered a problem with the team itself. The team then has to deal with it.

Worthy of note is the fact that this is actually not even being followed, anyway, as noted by how you mention the senior members take/get all the credit. If Scrum is working properly (as your ScrumMaster claims it is), then the seniors do not get credit. The team gets credit.

Any guide you can give me if you have ever been in a situation like this.

Bring up in retrospective. If that doesn't work, first examine and research to make sure you have actually, accurately assessed the problem. If yes, then escalate. If that doesn't work, polish up your resumé.

Answer 2

As a Scrum Master I always like to promote swarming:

The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

Swarming works well with another Agile practice namely Pair Programming.

When using these two practices you optimize the team for knowledge sharing, focus and giving room for seniors to teach juniors. It will make it impossible for people to hijack the fun tasks, or in your situation 'fake' to work.

There are some challenges, most importantly you need to be able to cut up a story into work items that people can work in parallel on. My current team takes the following steps:

• Hold a team-wide architecture and design session
• The team starts thinking about a test-plan and come up with test-cases
• They create sub-tasks on our Scrum-board
• They pick up sub-tasks in rotating pairs

I would ask the Scrum Master or the team in a retrospective to try swarming or pair programming for a couple of Sprints. They are classic Agile practices, so it should be very acceptable. Certainly if you feel there are issues surrounding working as a team.

Other reads:

• https://www.infoq.com/news/2013/02/swarming-agile-teams-deliver
• https://www.mountaingoatsoftware.com/blog/should-a-team-swarm-on-to-one-backlog-item-at-a-time
• Architecture, Design and testing: http://less.works/less/technical-excellence/index.html
• http://www.jamesshore.com/Agile-Book/pair_programming.html

Answer 3

Sarov hits a lot of the main points here.

This isn't healthy Scrum. I've of course seen it all to often. As Sarov points out, the team needs to self-organize.

You have another channel to go with as well. That's your manager. If you're team isn't working and that's making you not happy, your manager should know about it. The manager's job is to make sure individuals have what they need to be most productive.

Here's an idea you could try and float: If you could either get yourselves another tester or be willing to take on your own testing you could suggest splitting the team into two teams. You're already at the upper edge of what is considered healthy and recent studies have found 4-5 person teams are more productive. Then put all the new guys on one team and all the old guys on another team.

My guess is the old guys are going to push back heavily. You most likely have a situation going on that I've blogged about in the past. It's a classic anti-pattern based on the Pareto principle.