Team, team work, Sprint, Sprint Goal

With no teamwork and no Sprint Goal, there is no Scrum Team and no evident reason to Sprint at all.

What are the consequences of this in terms of value delivery and quality? Is there a sense of urgency to obtain more coherent Sprint outcomes?

You have not mentioned a Product Owner or an ordered Product Backlog. What if the Product Backlog was ordered by a cohesive set of Product Backlog items?

Does the team measure product quality, the health of the codebase, and collective code ownership within the team? If there can be room for improvement, you could ask for suggestions and even suggest teaching them about the benefits of pairing, Test Driven Development, code reviews, etc. These ideas might get the Developers working together.

All the best - not an easy challenge for you.

For @Ian

Thanks for your answer!

I do see people collaborate, which means that teamwork is there.

My point is more about "everyone works on a different subject".

For @Chris

Thank you as well for your answer!

There actually is a sort of cohesion between the topics, a sort of team/product scope as well.

We are some way measuring quality, health of the codebase (actually we are just triggered when it goes under a given threshold). 

In terms of "collective code ownership within the team", I think this is a good question, in the sense that people tend to correct the bugs related to their topics also because they have more knowledge on it. So this aspect could be improved, would you have some suggestions about it?

In general, let me reframe this topic to try to address my initial concern: how can we split a feature in a way that multiple people will work on it? And above all, how to make them understand they should work on the same topic so that it can be released before?

I am fan of the Scrum Guide Sprint Planning section when it basically say define a Sprint Goal and then let the people organize about which defining and performing the work which is needed to achieve it.

My fear is a pushback with something like "We can't split it"/"No, we can't work on that more than 1 or 2 people, what will do the others?"/"Only that? No we can do more, 1 person can do that and another one can do the other feature, the third person the third feature", so I need the experience of the on it :)

When a development task takes several days to complete, it often doesn't make sense to split it between different developers if you have two weeks sprint. If you have modules that only one team member knows how to modify, this can lead to an increase in the "bus factor" for that developer. This can become problematic if the developer leaves the company and other team members are not familiar with their code. To encourage collaboration among developers, the best approach is to incorporate a code review process. Code should not be merged into the repository without undergoing a thorough review, as this can improve code quality and facilitate knowledge sharing among team members.

Working together as a team towards a common goal is a skill that needs to be learned. A team doesn't achieve this by applying a single measure. The words split and together / collaborate contradict each other btw. 

As a coach, let me share one observation. You expressed your discontent with the way the developers are working. You did not, however, state a clear goal and a why. Of course, the team will resist if they are only told they are doing it wrong.

The discussion should rather be about being a team. As soon as they want to work as a team, they will find ways to do that. 

Another aspect is the backlog items. Are they designed in a way that makes collaboration easy and the only logical way? Refinement sessions provide a great opportunity to achieve that. A good first draft by the PO is beneficial, of course.

Have they considered having one developer test/write tests for what the other developer is creating?

That may result in "I'll write this while you do that".



Also, tools lead to 1 developer putting their name on a PBI, which leads to teams counting those items as a measurement of productivity. Please do not do that, it makes it so people want their name on as many items as possible, which means they can't help each other/work together on an item.



Which brings me to this question: do they have incentives to be observed as being productive?

Hello @Sergey, thank you for your answer!

Sure! I would say that there are different ways to perform Code Review, and some of them would really imply knowledge sharing. What I observed so far is that the link of the Pull Request is sent into a chat, and the first available member reviews it and I would say it is more a quick read to see if there were some errors/bugs, some rules respected, maybe some functional double check, but not really a knowledge about how it does work the whole thing. Probably would you have in mind some more efficient ways to perform Code Reviews?

Thank you @Oliver for your answer!

1. I kind of agree with your statement "You did not, however, state a clear goal and a why." . Which kind of goal are you meaning here? What would you suggest to do in this sense, as a Scrum Master? I would say that goal and why are given by the Product Owner. About the goal and the why in terms of framework, it is more about the Scrum Master.

2. About Product Backlog items: how would you consider that they are "designed in a way that makes collaboration easy and the only logical way"? I would appreciate if you could provede a quick example so that I can really understand what you meant here. Again, for me, it is about "splitting" those items so that more than one member can work on that topic/feature, but this is only my humble opinion and I am here for feedbacks :)

Hi @Allecio

Sending a link to a pull request in a chat and having the first available team member review the code may seem like an easy solution, but it can result in a less organized, less efficient, and less effective review process. Some disadvantages include:

-   Quality of the review may suffer. When team members are not assigned to review a specific pull request, they may not have the necessary expertise or context to provide a thorough review. This can result in important issues being overlooked, potentially leading to bugs or other problems down the line.

-   It can be difficult to track who is responsible for reviewing which pull requests. This can result in some pull requests being reviewed multiple times while others are not reviewed at all by experts.

To address these issues, it's recommended to assign team members to specific pull requests. This approach promotes knowledge sharing and can provide valuable feedback from team members who are more familiar with the codebase.

There are also other ways to improve the code review process:

Group Reviews: This involves bringing together a group of developers to review code together. This approach can help promote knowledge sharing and provide different perspectives on the code being reviewed. I would recommend using "Group Reviews" for larger pull requests.

Pair Programming: This is where two developers work together at one workstation. One person writes the code while the other person reviews it in real-time. This approach promotes collaboration and can result in a more thorough review process. I would recommend using "Pair Programming" for onboarding new members, learning new skills, or for complex or critical code.

Ok, I can see that my statement, "You did not, however, state a clear goal and a why." was ambiguous.

What I mean is that you want the team to change the way they work. You listed some implications of the current situation but did not state what goal you eventually wish the team to achieve.

The why is crucial for the team. They feel comfortable with the current situation and need a compelling reason to change. You have to appeal to their emotions. A rational explanation will not do it.

The other side of the equation is to find out why they do not want to collaborate. There could be psychological reasons. The structure and the quality of the existing code could be another one.

As for the second point: That's a bit more complex. Imagine a refinement meeting where the product owner brings a topic to the devs, and the whole team discusses it, shapes it and splits it into more digestible bits. That's teamwork. If, however, the PO comes in with pre-split items and just presents them, collaboration is unlikely to happen. And that's where it begins.

If we look at the other end, implementation, then collaboration doesn't necessarily mean coding. It can manifest itself in discussing design, pitfalls and to-dos, e.g., which can also be done during sprint planning.

Last but not least, why are there different topics in a sprint in the first place?

Thank you very much @Oliver for elaborating more!

About your first point, I see what you mean and I agree with you. Who should define the goal we have to achieve as a team? I see it as a team activity/workshop to define it together, something similar/linked to the Product Goal, what do you all think about it?

On the second point: great point!

Third point: "Last but not least, why are there different topics in a sprint in the first place?"

Linked to the second point. I believe that this it is due to the fact that there is one person in the team - the most Senior and experienced - who really influences (sometimes almost dictates) they way the work is split, up to almost who is going to take it. For him all this work can be done "in parallel", so different topics for different people. I am not saying that this is not a good approach, the problem is that this is not actually challenged/questioned all the time, it is quite the default. Reasons/goals behind this, seems to me maximizing "people utilization" and the number of features delivered.

Often it is more efficient for one developer to work on a story.

Keep a priority backlog and backlog items small and concise. Then a developer per item will not be bad.  For the sprint goal, do the stories in the sprint backlog not build up to something that can be a goal. 

My experience is that new teams have the tendency to work individually. However I would resist to try and control to much. Ask the team for ideas how collaboration can be improved. Let the team look for answers, i.e. pairing people up to work together. 

Team work takes time and trust to develop.