How to encourage teamwork instead of individual focus?

The first thing that comes to mind is to teach the team about a Sprint Goal. The Sprint Goals helps teams work together rather than as individuals. 

The team isn't creating a done increment every sprint.

There's a lot to work through based on what you've shared. The whole point of Scrum is to have a done Increment by the end of the Sprint. It might help to have the team go through a Scrum refresher training to all get on the same page.

Thanks Chris, that's a good suggestion. A Sprint Goal is another issue in the team, we've been writing a sprint goal at the end of the sprint planning and it always contains 3-5 different unrelated points.

I've gently suggested that the sprint goal should be the single focus for the team, but it hasn't really been accepted. I suspect the team is using the sprint goal to summarise the sprint for reporting to stakeholders.

I'll teach the team about the sprint goal before our next planning.

The team isn't creating a done increment every sprint.

Scrum is a means of establishing empiricism under conditions of high uncertainty. Without a usable increment there can be no empirical feedback. Even if no-one really cares about the Scrum framework, I'd wonder about that, and why stakeholders get reports rather than value.

I would say let the change start from you. For all observations that you listed, your team is be the best validators. Use the retrospective to share these points with the team and see what is their opinion or view point. 

The division of stories by front end and back end is all depends on how your product is defined. Check the perspective of the PO about this.

You can discuss with your SM about the deviations from the Scrum guidelines.

Reading I was thinking 2 things:



The Definition of Done must not include 'releasable' and 'tested', because that is just not possible. See whether something is possible: the PBI must be tested to be "done", and if it is done, it should be releasable. This means UI, backend and testing persons need to have their work done.



The second thing are WIP limits: try experimenting with a limit of work in progress. If you keep lowering that, people will have to work on the same story together. You can also combine UI, back end and testing stories into 1 story that then 3 people work on. In that case, the WIP limit can maybe even be 1/3 of the available developers. (try 1:1 to start, and then lower it as an experiment)



Of course, you need to convince the team to do these things, and that may not be simple. But, there is no obvious problem having specialism in the team: someone can be a UI specialist and work with a back end specialist and a tester to make a feature.

Construct the PBIs as fullstack items.

Focus on getting feedback early e.g. encourage demo and feeback many times per sprint.

Reduce the WIP:

Showing something in order to obtain feedback often will help here.

Use the tools to hand too.

Encourage the team to Task out the PBIs.

At the standup walk down the board asking "is there any reason why this item will not get to Done today?" if the answer is it will take more time then ask why others are not helping. 

Without a usable increment there can be no empirical feedback. Even if no-one really cares about the Scrum framework, I'd wonder about that, and why stakeholders get reports rather than value

Ian, good point. There are a range of discussions and meetings which I believe all come from a lack of a usable increment and a sprint review. It's something I can bring up with the team.

Use the retrospective to share these points with the team and see what is their opinion or view point. 

Thanks Balaji. I can bring these points up in the Retrospective. I've brought up a couple in the past and the team has been open, so I feel it's a matter of slowly and patiently making improvements and suggestions.

See whether something is possible: the PBI must be tested to be "done", and if it is done, it should be releasable.

Good point Mario. Our DoD includes several things such as automated tests passing, and validating with Product Owner. But I don't think they are releasable because of many other steps we need to take to get it released (automated tests don't run on any environment other than the local environment, a bunch of other tests and approvals need to be done as well). A long term goal for me in this team is to help the team expand their Definition of Done to enable a story to be releasable when it's done.

The second thing are WIP limits: try experimenting with a limit of work in progress

I'd love to introduce WIP limits, it's a good theory to improve flow and teamwork. I'm not sure if the team would be open to it, as they're very focused on individual stories and full utilisation, but perhaps this is all the more reason to suggest it!

Niall - great ideas to help with teamwork and feedback. I can bring them up with the team.

Thanks everyone!

It is simply a slow process. You need the buy in of your team. A good start is to let all members of the team take part in a Scrum Master training. So they can discuss on common basis and find for themselves, that splitting the team is not the best ideas.

On the other hand: Not all team members need to do all tasks and members may specialise in my opinion.

no discussion as a team or input from the PO

That is something you could adress or discuss with the Scrum Master by simply showing the Scrum Guide. It is clear, there need to exist some kind of priotisation of the backlog.