How Can I Make Stand Ups More Engaging & Collaborative

My first answer is one you may not like to hear but; You don't. 



The Daily scrum isn't for the SM, and one of the most common anti-patterns I see is SM's 'Running' the daily scrum to make it what they think it should be. 



If you believe the team could be getting more value from the DS, ask them about it. Dig into some of the challenges they are facing and see if the DS is potentially a solution. 



At the end of the day, they are a self managing team, and the DS exists for the developers to plan for the day. If you believe the DS is not as valuable as it could be, you need to find ways to coach to the team to self-solve that problem, not try to direct them. 



To give you a more direct tip that I've used; stop attending DS for a while. Or at least, attend and don't say a word. 



letting it get worse without your direction might be the thing that encourages the team to start talking about improving it. 



Whatever you do, please don't start trying to introduce 'process' or throw a ball around or any of these other weird things. It's not for you. The Developers need to decide how to make it valuable. 

No matter what team I've been in, no matter the company or maturity. Teams always have boring stand ups that take forever, and we go through each persons swimlane and have a quick status update about their jira tickets.

My advice is to drop those so-called stand-ups and status reports and have a Daily Scrum instead. The objective and criterion of success would be for the Developers to emerge with a collective plan, for the next 24 hours, which gets them closer to their Sprint Goal commitment. They may walk the board from right to left for example, and revise the Sprint Backlog accordingly.

Hi Michael,



I like the ideas you've presented a lot. I had tried being absent and the team were almost waiting for myself of the dev lead to join, and just went into the "checking jira swimlanes"  format  all over again...however in the same breath, if the team want to manage themselves like that, is that even 'wrong' ? 

I always like to gently remind people that we don't do 'stand ups' in Scrum. We do the Daily Scrum.

Obviously not everyone can stand, so it's a bit exclusionary.

And the idea of 'stand-up' is that everyone stands until it's uncomfortable, which is supposed to make the meeting shorter because it eventually becomes uncomfortable and painful.

Sometimes it's hard to motivate people, but we want to avoid 'pain' as being one of the motivating factors we use. 

:)

I think this is a really interesting thread.

I tend to agree that remote work changes the dynamic greatly.

And I also think it is very common for development teams to slouch into the low-energy orbit of turning the Daily Standup into a status report.

I'm also not overly comfortable with the advice commonly given which is that a good Scrum Master does nothing and lets the self-managing team fail until they get it right. I'm not sure that encouraging a project to fail so developers can learn a thing or two is a great strategy.

I hear this often about standups. (Ooops, sorry Darcy, I mean 'Daily Scrums') As Scrum practitioners, we are supposed to adapt. Yet the advice is often that we should not adapt and not change anything about the Daily Scrum, even in an age where the switch has been made to remote work, and demands like "The Daily Scrum must take place at the same time and place every day" become pragmatically impossible.

No, the Scrum Master shouldn't introduce a process. But they should coach. And coaching includes presenting ideas with which developers can choose to take or leave.

I think Scrum practitioners often surf on the Hawthorne Effect too much. They get things to work initially, not because the process is better, but simply because it's new. Every new framework works in the beginning. The challenge is to keep it working.

I'd really like to see more concrete suggestions to questions like this. I don't think 'let the developers figure it out until they fail' is a high water mark.

"I'm also not overly comfortable with the advice commonly given which is that a good Scrum Master does nothing and lets the self-managing team fail until they get it right. I'm not sure that encouraging a project to fail so developers can learn a thing or two is a great strategy." 



I'd suggest that if a whole 'project' can fail because the team doesn't have someone holding their hand in creating a daily plan, you have a much deeper problem than how the daily scrum is being run. 



It's about trusting the team to know how to solve problems, and offering opportunities for them to inspect and adapt their approach. 



The problem is the instinct of SM's to direct it toward something they've seen work elsewhere, but every product and every team is different, and a paint by number approach to any event is at best going to create consistent mediocrity. 



As a Scrum Master, you can offer approaches, share techniques, ask questions about what's working, offer retrospective techniques to highlight impediments, and encourage problem solving. All of those things are very active ways to contribute that don't assume you know best. 



 

Teams always have boring stand ups that take forever, and we go through each persons swimlane and have a quick status update about their jira tickets.

I can see where this Daily Scrum approach can seem stale and rote.   It sounds like a traditional status meeting, with each team member talking about their own Jira tickets displayed in their own swim lanes.   I don't see where this approach supports a collective team-based ownership of the items in their Sprint Backlog.



One technique that some of my teams have done to improve this is Walking the Board.   This approach removes the focus from individual team members, and places the focus on each work item, allowing the entire team the ability to comment on and plan for each item's progress.   It supports self-management by the team around their committed sprint work, and avoids the feel of a boring status meeting.

I'd really like to see more concrete suggestions to questions like this.

That is about as concrete as I can give you because it really isn't my place to tell others how to do their job. As an agile practitioner, I firmly believe that there are not definitive answers for situations.  Every one of the situations have different reasons and conditions for the occurrence so the solutions will vary.  The best I can do is give you some suggestions with supporting evidence on why I feel they are correct. 

..team were almost waiting for myself of the dev lead to join...

Anytime I see statements like this it throws a red flag up for me.  It indicates that the developers recognize a leader that they expect to guide them.  However, that goes against the concept of self-managing, self-organizing teams. Granted, those "self-" means that the team can decide on their own how they want to operate and they could choose to have a leader so I go along with it if the teams decides. 

The Scrum Guide has this statement in the section that describes the Daily Scrum.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

If the team chooses to turn it into a status meeting, then according to that statement it is the right thing to do.  However if they are not "producing an actionable plan for the next day" as Scrum Master I would bring up the topic in the next Retrospective and get a conversation going on why that is the case.  You can't fix it, but you can bring up the subject.

All of this comes down to the difference between coaching and managing.  To use a sports analogy, a coach can diagram a play and teach it to their team.  However, when the team is in a game and that play is called, it most likely will not go according to plan because there is an opposing team that doesn't know what they are expected to do.  So the coach also has to prepare their team to interpret the situation and adapt as necessary.  The coach can't make the game time decisions for the team so the team has to be equipped and empowered to do what they feel is best at the time. 

There are a lot of good SDO blogs and videos on ways to improve your daily scrum.  Read through a few of them and see what works.

IMHO a good scrum master would tell the team "you are saying these DS are boring.  I want you to come up with a few ideas to make it better and more useful."  And then hold them to making sure the DS is about inspecting progress toward the sprint goal.  (I'm not inferring you aren't a good scrum master here, just so you know).

Point to the purpose and hold the team accountable to making the daily scrum effective. It is, after all, for the developers.

I really like the approach of turning the challenge and responsibility back on the team.

That's a great way to coach them.