, ,

People arriving late to Standups/Scrum Meetings?

I have seen many Scrum Teams have trouble getting to their Standup on time, and being properly prepared. My suggestion is to get hold of some kind of “cheap simple noise device” (eg bell, hooter, drum, cymbals; NOT a mouth-contacting whistle/trumpet/vuvuzela).

Step 1: Make the warning noise of your choice 1-2 minutes before the meeting starts. (and maybe another 1 when the meeting actually starts!) Many team members, especially the usual latecomers, hate this approach, but it is highly effective. Especially when you try

Step 2: After 1-2 Sprints, select 1 person (somehow) who is still late/latest to the standups, and give them the power of making the warning blast – make sure the team knows who the week’s/sprint’s “victim/cop” is, and make sure they know just how vitally important their new responsibility is. You even get to take the device over to them at the right time, just to help them if they need further motivation.

Step 3: Usually after 2-3 Sprints, everyone is at least getting to Standups on time. If all is excellent, you may wean (or not) away from using the “noise device” – depends on whatever team culture has evolved in response.

Happy Scrumming!!!!

1 reply
  1. Nining
    Nining says:

    Scrum daily stand-up done right advocates the idea of ialividunds and interaction over processes and tools.A sprint done right advocates working software over documentation.During the sprint your teams primary and only focus is delivering on the commitment they made in the sprint planning session and the scrum master is there to protect the team from distraction and keep that focus.What you write here brings distraction, context switching which breaks the team flow and impacts there velocity.The stand-up should be each committed member (the pigs) saying what they did yesterday, what they are doing today and what blockers they have and observers and non committed members (the chickens) answering the teams questions.The scrum master is the facilitator of the meeting and should take the blockers and update the team on blocker resolutions as well as keep the teams focus and nurture the team by dealing with conflict etc.The product owner is there to see how the features are coming along, answer questions and provide advise.Now regarding about future features/stories these have to be left to the planning session, and as for maintaining quality this is a retrospective item.

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *


2 + 9 =