Daily Concept - what not to do!
In company we deployed the Daily, but in the meeting don't have a scrum master and the meeting is used to talk about your project. I discord, because I think that this ritual, in this model, its not works.
I Know that in my Daily I anwser the three questions and the Scrum Master solve my impediments.
I need help, because I need to understand what I can not do in my Daily.
Check out the Scrum Guide, there is a full description of what the Daily Scrum is.
To summarize, it's for the Dev team only and although Scrum Masters typically facilitate it, only the Dev team is required to attend. It's the event that is supposed to help them plan their day rather than provide other folks project status updates.
If there are impediments, sure the Scrum Master will want to assist in helping everyone solve their impediments, but the Scrum Master shouldn't be the keeper of solutions for you. Perhaps collaborate with the Product Owner, or another teams' Scrum Master?
Tks John. I going to check the Scrum Guide, but what do you suggest that should not be done?
@wagner, there are many resources to read and watch on improving your Daily Scrum here: https://www.scrum.org/resources?field_resource_tags_target_id=144
Hi Wagner - Eric has provided some great resources. Since you don't have a Scrum Master, you have to do something to get a Scrum Master in place ASAP. Take it to your Development Team and see if they know of someone who can be the Scrum Master. Maybe even someone of the Development Team can take on the Scrum Master role, at least on a temporary basis, until one is found.
A Scrum Master's job is to teach the Development Team to keep the Daily within the timebox of 15 minutes. And to help those outside of the Development Team to understand that the Daily is for the Development Team, and that the best way to interact with the Development Team is to allow them to have their focus during this time.
I would also suggest that the Daily Scrum is for the Development Team to collaborate and talk to one another on what the focus should be for the next 24 hours to meet the Sprint Goal. Read about the Sprint Goal in the Scrum Guide. It should not be a status report meeting.
From my personal experience, here are a few bits of advice:
1) Don't call it something else. If you call it something else, for example, 'stand-up' then the different name implies that the meeting isn't an official scrum event and doesn't help people learn and understand scrum.
2) Don't time-box developers to a set time. Time-boxing each developer to, say, 2 minutes will often cause important information (and value) to be lost and encourage rushing.
3) Don't rush. Developers will miss out on important information and a meaningful discussion will be lost.
4) Don't give status updates to other people. It isn't a status meeting it is for the developers to discuss their work for the next day. The sprint backlog will provide the information on progress.
5) Don't allow other people to join the meeting until the developers are comfortable having productive daily scrums. This is especially important for inexperienced scrum teams so their meetings aren't disrupted.
6) Use a speak-ball. Passing a ball around to a speaker can help focus the discussion and avoid interruptions. This doesn't always work though.
7) Try and make it interesting.Going around the developers in the same order answering the same 3 questions can be pretty boring and I've seen many developers disengaged during the daily scrum.
8) Take big discussions out of the meeting. Other meetings are allowed outside of the scrum events so if something requires more discussion then the required developers can have that discussion after the daily scrum.
As others have said you need a scrum master as soon as possible. Most of the above points will be taken care of if you have a good one!
Tks for all!! Great informations. Amazing. I will use all information. Thansk so much.
Chris an Jon, next week I will a scrum master.
One of the things that I cringe about when people talk about the "3 questions" for stand ups is that no where have I ever read that you should go around the circle and each person responds with the answers to those 3 questions. This is from the Scrum Guide's section where the Daily Scrum is described (emphasis added by me)
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. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
Let the Development set the structure of the meeting. Teach them to keep it short and then have longer discussions following the event. The questions do not have to specifically answered (i.e. yesterday I wrote code to populate the drop-down box, today I will write code to take the provided data and push it to the db, no blockers. Next person). But in order to plan for your next 24 hours, the information that answers those questions needs to be known by everyone in some form or fashion. In some of the teams I have worked with that would do a lot of pairing, it made no sense for each person to specifically answer those questions and a discussion was much more effective.
This can be done without a Scrum Master attending the Daily Scrum. But there has to be someone to help coach the team on the benefits and purpose of the Daily Scrum. So, yeah you need someone to be a Scrum Master but not necessarily does that person need to be in attendance at the Daily Scrum. I personally stand or sit nearby while my teams do their Daily Scrums. I can still evaluate if they are accomplishing the goal of the event without actually being in the event.
Daniel, that's a good example of how Scrum can be abused and I've experienced different Scrum masters teaching that as gospel. Scrum.org certified ones too!