How Can I Make Stand Ups More Engaging & Collaborative

Last post 07:59 pm June 22, 2022
by Darcy DeClute
10 replies
Author
Messages
08:50 am June 16, 2022

I'm a seasoned Scrum Master and I have been with several teams, this always seems to be a bit of a persistent issue and was hoping for people to share hints, tips and insights into how to making stand-ups better. 

Unfortunately all the teams I've worked with are 100% remote, so this is less than ideal and obviously less interactive because of the co-location.

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.

I HATE THIS. and so do they when asked...but nothing seems to change.

I highly believe in stand-ups focusing on a "daily goal" that will help work towards the sprint goal and then asking the team "How can we complete today's goal" - this is the dream and where I want to be able to with each team, increasing collaboration and team fluidity. Except in reality, nobody speaks, or people hide on the teams calls.

The teams always, as much as they say they hate it, seem to want to revert back to going through each individual persons swimlanes and talking about their assigned jira tickets...this creates a lot of bad anti patterns but lets leave that for a different forum.

What has helped you guys with getting profitable and really good stand ups, please share!

09:27 am June 16, 2022

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. 

09:40 am June 16, 2022

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.

09:48 am June 16, 2022

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' ? 

10:26 am June 16, 2022

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. 

:)

 

11:29 am June 16, 2022

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.

12:27 pm June 16, 2022

"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. 

 

03:37 pm June 16, 2022

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.

05:47 pm June 16, 2022

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. 

06:16 pm June 22, 2022

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.

 

07:59 pm June 22, 2022

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

That's a great way to coach them.