So to reflect that back –

– you have two people on the team who lack the skills to collaborate effectively as professionals?

To some extent it boils down to that; there’s often a chronic under-investment in non-technical skills within a team, which can lead to some pretty destructive behaviours being considered okay.

There’s lot of paths forward from this, but at a point it’s about

– identifying what behaviours are not acceptable professionally
– supporting the growth of key confliction resolution skills
– not allowing unacceptable behavior to continue

I generally start off with developing a team working agreement from the outset, based on a discussion about what behaviours we see on high performance teams, with a strong focus on “above the line” behavior and psychological safety. That create a platform to build from – or indeed a gap to coach into.

In one-on-ones the discussions become about how the individuals can be more effective in meetings, so providing other approaches than a win-lose conflict when it comes to how to address issues. At a point this kind of thing will liming their career development significantly, unless they get ahead of it.

Good facilitation skills help too; when a conversation is deadlocked asking what experiment or spike we could do to determine who is correct is one approach, but so is getting to the point where you can use ELMO (Enough, lets move on)

Of course, fist make sure you actually have an issue. Perhaps this is just how these two interact, and that the level of push-and-shove is okay for them and the rest of the team.

if it’s not okay for even one person, however you need to start in on addressing it.

Well, at a point they are not really roles, just a set of accountabilities that someone in the team needs to have – at least by the 2020 Scrum Guide.

At a point there was a reason that these were split out. There’s a degree of tension between the two sets of accountabilities that can lead to a conflict of interest in one individual, and lead towards the more directive, autocratic leadership style that some project managers adopt.

Of course, there’s no obligation to do Scrum, and the Scrum Guide is licenced in a way that allows you to adapt and create your own version (as long as you attribute the authors of the original) so you can really do what you want.

That said, I think it would be quite hard to

a) take care of all of the Product Owner accountabilities for one or more teams and
b) take care of all of the Scrum Master accountabilities across the entire organisation

It’s when the PO role is “owner in name only” and the Scrum Master role is confined to working on a single team without the wider impact, that the roles might shrink enough to be a single person…

Ah – I’d tend to keep the team-level metrics away from any external group; these are things for the team to help improve throughput and delivery, not for high level discussion.

What I tend to show at a high level is a forecast for delivery based on the team’s mean 9and standard deviation) of the throughput.

We’re usually using a “feature level” upstream Kanban for large items. For the initial sizing I tend to get the team to estimate using the Fibonacci scale in sprints/iterations/weeks/months (ie a big time unit). We don’t get to a single figure always, just the range they are 85% confident in.

We then refine that work through story mapping sessions, surfacing assumptions (which can become risks to be managed), as well as unknowns (to be addressed with spikes)

That provides a pretty accurate forecast overall, with a precision that is improved as we

– story map and do spikes to refine the estimates
– do the work get feedback and discover work

It’s certainly enough for meso-scale operational planning (which quarter will X be delivered, do we need to hire more people, do we need to split a feature into parts etc.)

Once you have maybe 30-50 features completed then you’ll have enough data just to use the mean and standard deviation of the feature cycle time for forecasts.