I think it’s not unusual to find senior developers with great technical skills, but who lack the competencies’ needed to be effective leaders within a team.

I’d suggest what you are looking at is more about local optimisation – what the individual needs in order to feel effective Vs what the team needs to feel effective.

Chances are this is driven by the systems you have in place around individual performance reviews, promotion and so on., as well as what behaviours get rewarded with praise, positive feedback and so on.

That creates three areas of stress:

– people who lack the skills to be able to team effectively
– people who feel that teaming is a threat to their status
– people who feel helping others will impact in a negative way n their performance

Does your team have the psychological safety and skills to be able to discuss the behaviours in a retrospective without relationships being damaged?

If not, that might be a place to start.

I think experiments are a good thing We want teams to experiment with ways of working – that’s basically how we uncover new stuff and challenge dogma.

It’s also how we break the mould of opinion-based win-lose debates on issues and HIPPOs (Highest Paid Person’s Opinions) carry all the weight, and shift towards evidence-based win-win dialogues.

That said, when we experiment it needs to be based on empiricism; as W Edwards Deming said, we don’t collect data for “museum purposes” – we do it to guide business improvement.

It’s okay to challenge conventional wisdom on things, but do so on an evidence basis:

Key questions become:

What is the hypothesis we are testing?
What does success look like?
What does failure look like?
What will we measure?
How much data do we need to test the hypothesis?

This starts to get into how you want to measure performance as a team; there’s things like the DORA metrics, Kanban metrics and so on, but there’s also how your collective group of product owners are choosing to measure value, story-by-story or Sprint-by-Sprint.

That’s a whole different can of worms, but if they cannot define how they are measuring value delivered, then no-one can tell if this is helping or hindering your business…

I’d suggest:

– “Psychological Safety and Learning Behaviour in Work Teams”- Amy Edmondson 1999(1)
– Amy Edmondson’s TedX talk on Youtube (2)
– Amy Edmondson’s book (3)
– Google’s Re:work blog (4)

(1) https://www.researchgate.net/publication/243774322_Psychological_Safety_and_Learning_Behavior_in_Work_Teams
(2) https://www.youtube.com/watch?v=LhoLuui9gX8
(3) https://www.amazon.com/Fearless-Organization-Psychological-Workplace-Innovation/dp/1119477247
(4) https://rework.withgoogle.com/print/guides/5721312655835136/

It probably doesn’t matter very much, to be honest.

Story points were only ever “thinly obfuscated time” anyway(1) ; the aim was to stop people taking the team’s estimates, summing them, and then calling that a deadline.

If you are using Scrum, then points/velocity are just about making sure your Sprint Plan to reach a Sprint Goal is viable when you start. You’ll be inspecting and adapting that plan daily, which might mean splitting stories, pushing some items back to the backlog and pulling others in.

The Sprint Goal is a stepping stone to the Product Goal, and it’s those goals that matter.

On the other hand, if you are really focussing on delivering a backlog, then I’d advocate looking at the Kanban Method; without a Sprint Goal that might serve you better. I the Kanban Method there’s no estimation by the team. You make forecasts based on statistical estimation, using the cycle time or throughput (stories/week)

So – probably not a hill that is worth dying on, IMHO. There are probably other things that are holding the team back more….

But if you really want to unpack things, go with empiricism.

Collect data. Count the number of stories each Sprint, along with the total number of points from the completed stories. Use this in the retrospectives. Look for patterns. Would counting stories serve you just as well?

I’ve used a bubble plot with the total points (Y), number of stories (X) and the bubble size as the average story size. What does the team notice?

Start to build the idea that the team should shift from opinion-based debates to data-driven dialogues……

(1) https://twitter.com/ronjeffries/status/307469737305186304?lang=en