Methods to improve daily scrum / standup

Question

My Team's Daily Scrum needs improvement and I was wondering if anyone has a workshop idea/method on how to improve.

The current issues that my team face are:

• They tend to go off topic, instead of focusing on what I did, what I am going to do and impediments
• The Product Owner talks and asks them for 'updates' during or directly after the Daily Scrum
• They often don't know what they are going to do... i.e. they can't answer the question during the Daily Scrum, so they say they are going to decide after the Daily Scrum what to do.

Answer 1

You have neglected to say whether your team are face to face or working distributed and communicating via Lync etc so for the sake of this answer I will assume distributed.

Stage 1: Basic Discipline

• Take a hard line with the Product Owner and tell him that you will facilitate the session and ensure that it is productive. Sharing the duty is confusing to the team
• If the PO requires an update he can speak to developers individually after the stand-up but the ticket tracker (Jira, physical board) should be enough of a steer
• Have the Board with the tickets visible (on screen or in person) and link the tickets back to the developer so everyone can see it and commit to their teammates
• Keep it conversational but focussed (for example)

Hi Dave, how was your day yesterday. Is there anything you can update the team on? You worked on Ticket 267 right? How did it go? Fantastic. Are you continuing with that today or are you being pulled into anything else? OK. Good stuff. Lastly; is there anything that you need from me or the rest of the team?

Although lengthy this type of interaction will flow a lot more smoothly once the team get into the habit.

Stage 2: Keeping it accessible

Remember that your aim is to create a self-organizing team not chair ceremonies.

• Have developers nominate the next developer to speak and get them to ask what they worked on yesterday
• Don't make people actually stand-up. People have back problems, injuries, hip replacements and all sorts. One of my team members for 62 and hated standing. Of course we sat down with a coffee the whole time
• Ensure the developers are calling out supportive behaviour (Oh Dave helped you on that did he Karen? Awesome. Thanks for letting us know. Great teamwork guys; thanks for doing that Gatekeeping task so quick etc etc)
• Don't be too stringent about the timebox. The 15 minute time limit was imposed to stop 40 minute meetings. It was not designed to aggressively cut people off at 16 minutes and disband. You already have everyone on the call, simply dismiss those that are not needed and continue it using your judgement
• As a ScrumMaster; confirm to your team what you will be doing that day as well
• Ensure that at the end or the beginning you open the meeting with a small rapport builder (Hey team - everyone enjoying the great weather? Anyone do anything great the weekend? No? OK let's get started)
• Make sure you update the team on comms during the stand-up (Hey team, just for everyone's awareness, the back-end guys might be upgrading XYZ today so check your inboxes or Slack for the notices
• Finish the meeting with the PO (Hi PO, any big stakeholder messages or changes to inform the team about before we break?)

The key part is always to remember that your coders manage the code pipeline; you manage the relationship pipeline. Forget Scrum and the Stand-up and just talk to your team like they are human beings working on something valuable; because that is exactly what they are.

Other hints and tips for building a team

• Genuinely care about their diaries; ask how many meetings they have that day. Are they feeling pressured or burdened. Ask if you need to get involved to push back on anything
• Every few stand-ups throw in a personal anecdote about you or a team member to build the bond. (Hey did you know Alice just completed her AWS exam? That's awesome. We should pick it up at the Review to tell stakeholders but for now; well done)
• Use humour to make meetings bearable. I see so many teams being death marched into a delivery. Agile is about flexibility but the traditional project management rapport building is not gone. Really connect with people during your sessions
• Focus on building a team identity
• If you are face to face then make the ceremony a genuine gathering; tell people to stop work 5 minutes before and go and get a drink/coffee etc ready for the standup (As an aside I also break up my Sprint planning with a 10 minute break uing this pattern as well)
• Ensure your teams have the psychological safety to speak up (I typically do this by focussing on the shyest member of the team 25% of the time using the sentence "I don't mind what you say, genuinely, just tell us what you think. Be bold." Once they have reached a level of confidence I shift focus to another team member for a few timeboxes. This has led to programmes giving me under-confident developers to bring out of their shell

Answer 2

Since you've tagged the question with scrum and scrum-master and daily-scrum, I'm going to assume that you are following Scrum as defined in the Scrum Guide.

Is the Scrum Master attending the Daily Scrum? Although not a required participant, one of the Scrum Master's services is to "facilitate Scrum events as requested or needed". I would expect that a good Scrum Master would occasionally observe the Daily Scrums and, when any of the rules of the event are broken, would speak up and get the event back on track. I would also expect that the Scrum Master would follow up with the Development Team during Sprint Retrospectives to help come up with ideas.

The Scrum Guide also says that one of the responsibilities of the Scrum Master is to ensure that anyone from outside the Development Team that attends the Daily Scrum does not disrupt the meeting. If the Scrum Master is attending the Daily Scrum as an observer or following up with the Development Team on the effectiveness of the Daily Scrum at Sprint Retrospectives, the Scrum Master should learn of any disruptions. Does the team have a 15 minute timebox within which to carry out the Daily Scrum? Does the team find the Product Owner's questions disruptive? If the team is finishing their Daily Scrum in a 15 minute timebox, there is nothing wrong with additional time spent after the event. In fact, the Scrum Guide says that it is common for team members (referring to the entire Scrum Team, not just the Development Team) to "meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint's work". If the team does not consider the Product Owner's questions disruptive, or perhaps even considers them helpful in achieving the objectives of the Daily Scrum, why should that change?

It's also important to realize that the Daily Scrum does not need to be in the "three questions" format. The Scrum Guide even says that "some Development Teams will use questions, some will be more discussion based". However, regardless of the format, the purpose is to, on short intervals, inspect how progress is competing toward achieving the Sprint Goals, adjust to increase the likelihood that the Sprint Goals will be met, and raise concerns to the Product Owner if the Sprint Goals are in danger to work to come up with any changes to ensure that a value-adding potentially releasable Increment is available at the end of the Sprint. The Scrum Master can coach the Development Team on different methods, but the Development Team should ultimately drive the execution of the Daily Scrum.

The only point that isn't addressed by the Scrum Master's facilitation of the event and the coaching of the rules of Scrum is the members of the Development Team not knowing what they are going to do next. The priorities of the work should be driven by the Sprint Goal and the attributes of value and order assigned to the Product Backlog Items brought into the Sprint. The Sprint Backlog contains decomposed Product Backlog Items, but all of the decomposed work should be tied to one or more Product Backlog Items (with a value and an order) and maybe have a technical dependency. It should be trivial for the team to determine, once they finish one item from the Sprint Backlog, what the next thing to work on should be.

Answer 3

Negative behavior generally has various reasons. While as a scrum master your job is to moderate the scrum ceremonies, your goal should be getting the team into a position where you're essentially obsolete.

1. Understand

Determine the cause for these behaviours. It can be lazyness/convenience (why set up another meeting when you can discuss your issue right now?). It could be a need that is otherwise not met (unsatisfactory progress visibility, real or perceived difficulty of discussing issues with others). It could be habit (PO used to be a PM and asking for status is what he's used to doing. Or the team used to have regular monolithic meetings where everything was hashed out together).

2. Support

See what you can do to help with problems you discovered. Maybe someone needs to get more comfortable approaching other teammembers for help/feedback. Maybe moving the standup to a later time would allow everyone to get their bearings in the morning. etc.

3. Educate

Politely ask your team mates to keep their contributions short and hash out anything beyond the essentials afterwards with whoever it concerns. Point out to the PO that he can see the progress on the board after the meeting. Try to get the team to solve the problems themselves.

4. Guide

If all this fails the scrum master should step in and direct the ceremonies more closely until the new pattern becomes ingrained. Cut off tangents by leading them more closely through the three questions. Cut off the PO if he interferes or even uninvite him if the behaviour persists. Institute small fines for team members who arrive unprepared. My scrum coach told me he once had a team with a severe mobile phone problem. So he took some painters tape and drew parking spaces on a table. Everyone could place their phones on their freely. But anyone caught using the phone or having his phone go off had to put 5 bucks into the coffee jar.

Answer 4

I'll address your concerns in order. I see several possible underlying problems here. As always, discuss with the Team in the Retrospective to determine the underlying causes and agree upon solutions!

They tend to go off topic, instead of focusing on what I did, what I am going to do and impediments

As others have said, the Daily Scrum does not have to be in the three-questions format. The purpose of the meeting is to serve the Team. If the Team doesn't feel they need that format, then don't bother with it.

However, it is a problem if the meeting goes off-topic, providing the 'off-topic' discussions are not useful to the whole Team. A common occurrence I've encountered is to have 2-4 developers engaged in a side-topic while everyone else there sits disinterested, but not wanting to interrupt. One approach I'm fond of is to have someone raise their hand when they feel a topic being discussed is not relevant to them. Once you reach 2 hands up (or 1, or 3, etc., depending on your Team), the discussion is halted and resumed after the meeting only amongst those involved.

The Product Owner talks and asks them for 'updates' during or directly after the Daily Scrum

This is not the purpose of the Daily Scrum. The Scrum Master (SM) needs to educate the Product Owner (PO) about this. However, this could have several underlying causes.

1. The PO simply is unaware that this is harmful. Solution: educate the PO.
2. The information the PO needs is not available in an information-radiator, such as the Sprint Board. Solution: Make sure you have an information-radiator, make sure the PO has access to it, and make sure it contains the info the PO needs.
3. The PO is not aware the information s/he needs is on the information-radiator. Solution: educate the PO.
4. The PO's information needs are so complex/unique that they cannot go on the information-radiator. Solution: find a less-disruptive (to the Team) means of handing that info the the PO. Maybe the PO speaks privately only with those from whom s/he needs information?

They often don't know what they are going to do... i.e. they can't answer the question during the Daily Scrum, so they say they are going to decide after the Daily Scrum what to do.

The fact that the Team doesn't know what they're going to do before the meeting but does immediately after is indicative to me of several possible problems.

1. The Team doesn't have enough time before the Daily Scrum to get their bearings. Solution: move the meeting later in the day.
2. The Team just doesn't feel like doing it. Solution: Inform the Team the risks of the rest of the Team not knowing what each Team member is doing. Note: first make sure there are risks for your situation! If there aren't, then the problem is:
3. The question itself is not useful to the Team. Solution: stop asking it!
4. The Team is afraid. They do not feel safe enough to answer the question. This is the most dangerous problem, and the hardest to get the Team to admit. Maybe they're afraid that, should they start working on task A, and something comes up with task A, they'll get penalized somehow. Better to just hide the fact that they're working on task A in the first place... Solution: find out why the Team feels unsafe, and fix it. This is a significant undertaking in itself, but crucially important.

These are just the possible causes I thought of off the top of my head. It's entirely possible the causes in your situation are different. This is why it's important to bring up your concerns in the Retrospective. That's what it's for!