Seems like a long time if it is often.

I tend to use the idea of a “parking lot” – that is if someone is going on too long or getting into the details, the team can call out “parking lot” or “ELMO” (enough, lets move on) and that conversation is parked until AFTER the daily scrum, for anyone who wants to stay around.

Some tricks to create focus (and shift from status reporting) include

– a quick fist-of-five confidence vote on “Can we reach our Sprint Goal”- if you get any votes under a 4, then ask the team what they are going to do, right now, to change their plan..

– go round the team; each person says briefly what they are doing, if they are free to offer support/help or if they need it. Save the detail for the parking lot

– go round the board, discussing each work item and what it needs to get it closer to “done”; this work better with a full Kanban board

BUT – before all of that, ask the team if the Daily Scrum is serving them and creating value; If it is, and they always reach their Sprint Goal, then it’s doing it’s job…

Hmm – sounds like a bit to unpack.

Few things to think about, but there’s a lot of ground”

a) Sprint Goals
The Sprint Goal is a stepping stone towards the Product Goal; that’s usually an outcome rather than a bunch of functionality. Ideally it’s a measurable benefit for the users. There’s only one goal, not a check list. You can’t half do a goal – the benefit is obtained, or it isn’t. Scrum Guide is pretty good on this.

b) Sprint Planning
If you are using points, then I’d suggest plan for the mean number of points you have done, minus the standard deviation. Leave a buffer. You can always pull more work, but until that is happening consistently, you are taking on too much.

Be ruthless about splitting stories; the scope for errors, delays and rework is always higher on larger stories A couple of people swarming on the work for a day is a good size. One person for a week is not. Remember the INVEST criteria.

c) Daily Scrum
You are inspecting and adapting your plan to reach the Sprint Goal daily; maybe shift the stand-up to a “fist of five” vote on if the goal can be met. If you get less than a 4 or 5, then what is the team going to do, right now, to change that. That might include renegotiating some of the stories with the PO, or even rejecting them entirely. The Sprint Goal matters, not the PBIs.

Be ruthless on work-in-progress; stop starting new stuff and start finishing things. If it’s blocked, then swarm on the issue until it’s not.

d) Sprint Review
This is figuring out with the customers what will be next, to shape the upcoming Sprint Goal. Maybe incomplete stories/features are still relevant. Maybe they are not. They go back to the backlog, to be considered next time around.

e) Retrospective
Perhaps focus on what slows the team down for a retro?
You could run a sailboat, or do an Ishikawa fishbone to try and identify the biggest constraint.
You can support that by collecting data – cycle time, story count throughput per Sprint, velocity, average story size. What are the patterns telling you?

Hope that helps…

I’d suggest there’s some core areas where an SM brings value

– knowledge of Scrum, lean, Kanban, theory of constraints, project management, and all that stuff about how work flows is delivered,

– knowledge of the software development lifecycle in terms of a waterfall process, and agile practices/approaches such as Extreme Programming, emergent design, security and so on

– marketing knowledge, in the sense of what people value, how to communicate it to the organisation, and how to measure it, product and product adoption lifecycles, customers and all of that stuff

– business knowledge; finance, legal. sale, marketing, procurement, operations, strategy and all of that

– leadership; coaching, conflict resolution, problem solving, negotiation, psychology of teams and individuals, culture and so on

The more of these you know stuff about, the more likely it is you are going to bring value to any given team or organisation. So broadly, keep learning!

I’ve been around software development for 25+ years, and working an an agile/lean space for the last 14 years. And I’m learning new stuff in one of these areas pretty much every week.

So – my current team is in Data Warehousing, where I have never worked. Two weeks ago I discovered “DataOps” is a thing, so that’s my current study!

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.