How do you use your first 15 minutes of daily standup ?

According to the Scrum guide: 

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal.

Why do you think the daily scrum is limited to 15 minutes? Also, do you think 'leading' the call will make the team more self-organizing?

The Daily Scrum should be an inspect and adapt event. It's about looking forward. Inspect the progress so far and the amount of work that is left. If it becomes transparant that there is too much or too little work to do for the rest of the sprint, adapt the sprint backlog.

The scenario you describe seems to focus only on what was done in the past. This is a sign of a dysfunctional Daily Scrum. 

As to who gets to talk and when, that is up to the development team members to figure out by themselves. Whatever works for them. The Scrum Master should not participate in the Daily Scrum. 

The SM deciding who talks to long and interrupting is another sign of a dysfunctional Daily Scrum. It sounds like the Development Team is giving a status report to the Scrum Master.

It also gives me a feeling hat the Scrum Master is a manager who decides who does what and that the team reports to. This Scrum Master is undermining the Development Team's ability to self organise.

The scenario you describe seems to focus only on what was done in the past. This is a sign of a dysfunctional Daily Scrum. 

My simple question is - Can development team member ask question to other development team member before everyone finishes update?

That is up to the development team themselves. Let them self organise.

@Vishal, one of the key points in your scenario is how long this has been going on.   Was this observed in one Daily Scrum?   Is this a regular occurrence?

As a Scrum Master, you have two responsibilities regarding the Daily Scrum (NOT the Daily Standup):

• Ensure that the Development Team conducts it on a daily basis
• Coach the team to keep it within the 15-minute time box

My advice is to perhaps note the times when the Daily Scrum has exceeded the time box, and then introduce it as a topic for discussion in the Sprint Retrospective.   Have the Development Team discuss ways in which they can adhere to the 15-minute time box requirement.   Help them self-manage around this Scrum event that is run by them and for their benefit.

My simple question is - Can development team member ask question to other development team member before everyone finishes update?

As a result of each Daily Scrum, the Development Team should have a clear plan of what they will do, in the next 24 hours, to help meet the Sprint Goal.

Is giving "updates" an appropriate mechanism for crafting this plan?

Scrum Guide says that the Scrum can be organized in many ways as long as the focus on progress towards the Sprint Goal.  As with a lot of the components of the Scrum Framework suggestions are made on what takes place but nothing is definitive other than the purposes.  As a Scrum Master your responsibility is to ensure that the event occurs and to protect the participants (Development Team) from interference from others. 

So answer to your question is let the Development Team decide what is the best way to use their 15 minutes while coaching them that the 15 minute time-box is to be used for discussing progress made since the last time they met towards the Sprint Goal while planning the work that will be undertaken until the next time they meet.  Anything that occurs outside of that 15 minute window is technically not part of the Scrum so that would be considered work in progress for the day.  An aside, I often suggest that as part of the plan for the next day they include "Bill, Ted, Jane and Mary will get together to discuss the problem that Mary is having".  When they do that is entirely up to them. 

Thanks all.

Noted all points.

One more issue is - : One of our team member sits at different location. So we use TV screen to connect to him during daily scrum. Each one shares the work progress, impediments etc. Then in 16th minute, detail discussion happens. All smooth so far. But as Ian mentioned- the Development Team should have a clear plan at the end of daily scrum- what does this exactly mean? and as a SM how can I guide the team to create plan.

Offshore team faces TV .and not each other.. Each development team member comes forward and shares his progress. I know they should collaborate, but how shall I help them to collaborate apart from telling the importance of collaboration every now and then.

Each one shares the work progress, impediments etc. Then in 16th minute, detail discussion happens.

To me this sounds like the team members are sust saying "I am stuck doing X". It might be better to say "Could anybody help me with doing X, as I am stuck?", immediately followed by team members offering help and planning when they will sit together. This is a form of daily planning

But as Ian mentioned- the Development Team should have a clear plan at the end of daily scrum- what does this exactly mean? and as a SM how can I guide the team to create plan.

Maybe it would be an idea to ask the Scrum Team this very question during the Retrospective? Let them explain what they think is the use of the Daily Scrum? Or whether they think it is useful at all?

The Development Team that I am currently serving typically discusses topics like:

• Did things not go as planned yesterday, that the rest of the team doesn't already know about? Or do we expect things not going as hoped today?
• Ah, you are doing X? Can we pair program so I can learn? When do you have time to pair?
• What can I do today to help get the next PBI(s) to Done?
• Ah, you are doing X? Last time I had to do the same thing, can we sit together today to try and automate this? 
• Are we still on track to achieve the Sprint Goal? If not, how can we adapt?
• Etc.

Each Daily Scrum is different, as different things happen every day. Sometimes there are more topics to discuss than usual, especially when things are not going as planned at all. In those cases, the Daily Scrum may take a bit more than 15 minutes. This is fine, as long as the discussion remains focused on the goal of the Daily Scrum.

Don't be the Scrum Police that blows a whistle and disperses the crowd after 15 minutes and 1 second. Also, don't start monitoring the team and measuring how long they take. That would be undermining their self organisation, as you become their baby sitter. They are adults, treat them as such.

I quite regularly stand a few metres behind the Development Team or don't attend the Daily Scrum at all, so the team can learn how to organise the Daily Scrum in a way that suits them most. Observe without intervening and if needed ask the team how they feel they are doing during the Retrospective.

Offshore team faces TV .and not each other.. Each development team member comes forward and shares his progress. I know they should collaborate, but how shall I help them to collaborate apart from telling the importance of collaboration every now and then.

>> How many members are in your Scrum Team ?

@Henri and I are on the same wavelength.  I have gotten to the point where I very seldom attend the Daily Scrum for my teams.  The organization has become very familiar with the event and the purpose behind it so people on other teams will not interrupt.  I attend occasionally by standing off the side or behind them, just out of line of sight. I watch for things that might be worthy of a retrospective discussion but on the whole I leave it up to them to decide how to do it and why to do the things they do.  Each one is a free-form discussion instead of a regimented process like you mentioned the offshore team does.  At the end, they all come away with an understanding of what each one is working on and how it relates to what each will be doing.  It isn't a forced thing, it is an organically grown process that they value. As a Scrum Master I think your better focus would be on getting them to see it as a useful time to discuss versus a regimented, structured meeting. Help them see the benefit that can be found by a daily discussion on their work instead of a daily status report.

As for the offshore team participation.  We have offsite and offshore teams and team members.  We also use video to include them. But we also have access to Microsoft Teams on every computer.  We often will have "teams" chats among people that need to collaborate on things. It can be a video/audio call where everyone uses headsets to minimize the impact on those around you or just a text chat where the history can be accessed later. 

I'm also going to offer this suggestion to help relax the event so that it doesn't seem so regimented.  The Daily Standup is an eXtreme Programming practice. Standing was a way to help people keep their comments short.  In Scrum you have a Daily Scrum.  There is no prescribed way to do it so standing is not a necessity.  If I see a team slipping back into the standing status meeting mode, I will start moving into their line of site and sit down. I have even been known to pull a bunch of chairs into their stand up area so that the next time they come together the chairs are in their way.  Sitting helps to relax the atmosphere and often helps them to see it more as a conversation than a required meeting.

>> How many members are in your Scrum Team ?

6 in development team (1 architect + 1 tester + 4 developers) 

The Development Team that I am currently serving typically discusses topics like:

• Did things not go as planned yesterday, that the rest of the team doesn't already know about? Or do we expect things not going as hoped today?
• Ah, you are doing X? Can we pair program so I can learn? When do you have time to pair?
• What can I do today to help get the next PBI(s) to Done?
• Ah, you are doing X? Last time I had to do the same thing, can we sit together today to try and automate this? 
• Are we still on track to achieve the Sprint Goal? If not, how can we adapt?
• Etc

@Henry, Absolutely true. this is Fine-grain coordination as mentioned in book 'Training agile teams' (Team members should have quick , focused interchanges during stand-up.) "Oh, I didn't know you were planning to do that this afternoon. That means I need to change the order of things I was going to do to get you what you need. 

Now couple of points here:

1. Our team is new (Project wise and IT experience wise also)

2.  Small team.. everyone knows what other is working on even without daily scrum as they sit beside each other

3. My concern is how as a scrum master I should slowly make them understand that your responsibility is not just about your work but how as a team you are performing.

4. To some extent I believe, development team members should be smart, talkative , confident for fine-grain coordination. If they are simply average development team members it's very difficult for scrum master or may be impossible to start fine grain coordination between. Still, would like to thoughts of experts here.

@Henri and I are on the same wavelength.  I have gotten to the point where I very seldom attend the Daily Scrum for my teams.  The organization has become very familiar with the event and the purpose behind it so people on other teams will not interrupt.  I attend occasionally by standing off the side or behind them, just out of line of sight. I watch for things that might be worthy of a retrospective discussion but on the whole I leave it up to them to decide how to do it and why to do the things they do.  Each one is a free-form discussion instead of a regimented process like you mentioned the offshore team does. 

Thanks for sharing process at your end Daniel. As always , got to learn new things from your post.

My concern is how as a scrum master I should slowly make them understand that your responsibility is not just about your work but how as a team you are performing.

I am a strong believer in letting people feel the pain of what they do in order to decide to change.  If there is no pain, then there is really no reason to change. Remember the Development Team should be self-organizing.  As long as they organize in a manner that continuously delivers incremental value then leave them alone. If they are struggling with that, then help them.  Suggest opportunities or options for change, explain to them how your ideas could offer improvement and help them come to their own solution. Get them to "experiment" with a change and then improve upon it.  I tell my teams that you can't change something that you don't do.  Try something, decide if it works and improve it as you go. Use agile practices to determine how to use agile practices. 

Small team.. everyone knows what other is working on even without daily scrum as they sit beside each other

I have worked with a lot of teams that sit next to each other, talk all day long but have no real idea what each other are doing.  They can ask each other technical questions but that doesn't mean the other people know how/why it is being asked.  Help the realize that the short Daily Scrum is to validate that everyone knows what others are doing and for all to offer help when another is having problems. Also while everyone might know was someone was working on in the last hours, it is difficult to know what they will be doing in the future.  In some cases the person doing the work won't know what they will be doing until they start doing it. 

Our team is new (Project wise and IT experience wise also)

This team needs coaching on working as a team instead of as a group of individuals more than ever.  If their IT experience is limited, they most likely come from a place where their individual efforts were rewarded more than team efforts.  Help them understand that in a team process, the individual contributes more by helping the other team members better.  Help them recognize the skills that they have and don't have.  Then have someone with strong "skill A" help someone with weak "skill A".  Best way for this is an exercise in a retrospective where each team member provides a list of their skills and them put them up in front of everyone.  Something similar to SWOT (http://www.funretrospectives.com/swot-strengths-weaknesses-opportunities-threats/).  

Good luck and thank you for the comment you gave me. It helps me improve and I am learning from your questions as well.

I am a strong believer in letting people feel the pain of what they do in order to decide to change.  If there is no pain, then there is really no reason to change.              

If they are struggling with that, then help them.  Suggest opportunities or options for change, explain to them how your ideas could offer improvement and help them come to their own solution. Get them to "experiment" with a change and then improve upon it.

Noted !

Hey!

At Netsmartz, our goal is simple, We gather in our meeting room and each one of us ask these three questions from ourselves

• What did we accomplish since the last meeting?
• What are the tasks to be worked upon until the next meeting?
• What are the obstacles and how we can overcome them, in order to enhance our productivity?

This boosts up the team's morale and gives them a clear idea about what's already done and what needs to be done.

We also, have brainstorming sessions, to work upon the problems that we are facing.

We address the problems when they are small, because if we wait, the problems might become bigger and harder to solve.

@Vishal I am sure there are discussions that Development team have in daily scrum which can take more than 15 mins. According to the Scrum Guide the Daily Scrum should be only for 15 mins. If there is any issue/discussion that is going to take more than 15 mins, team should facilitate another meeting for having that discussion, as Scrum does not stop the Scrum team to have more meetings than mentioned in Scrum Guide.   

I think it's important to remember what a Scrum Master's role is in the Daily Scrum. It is primarily to respect the 15 minute timebox.

In my experience, this has been done most efficiently by helping to keep conversations on track with progress towards the sprint goal, and knowing when to step in and suggest "rabbit trails" be taken offline. The Scrum Master is largely a facilitator to helping the team achieve its goal(s) each sprint.