Daily Scrum Meeting

Solarion

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
28,064
Reaction score
17,833
Leading a scrum session today. Found this helpful gem and thought I might share it.

In Scrum, on each day of a sprint, the team holds a daily scrum meeting called the "daily scrum.” Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.

There is an old joke in which a chicken and a pig are talking that illustrates a key concept in the daily scrum ...

Chicken: "Let's start a restaurant."
Pig: "Good idea, but what should we call it?"
Chicken: "How about 'Ham and Eggs'"
Pig: "No thanks. I'd be committed, you'd only be involved."

The joke is meant to point out the difference between those who are committed on a project and those who are only involved. Scrum affords special status to those who are committed, and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum meeting.

All team members are required to attend scrum meetings. Since both the ScrumMaster and product owner are committed team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen. This makes scrum meetings an excellent way for a Scrum team to disseminate information -- if you're interested in hearing where things are at, attend that day's meeting.

The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions:

What did you do yesterday?
What will you do today?
Are there any impediments in your way?

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

If a programmer stands up and says, "Today, I will finish the data storage module," everyone knows that in tomorrow's meeting, he will say whether or not he finished. This has the wonderful effect of helping a team realize the significance of these commitments, and that their commitments are to one another, not to some far-off customer or salesman.

Any impediments that are raised in the scrum meeting become the ScrumMaster's responsibility to resolve as quickly as possible. Typical impediments are:

My ____ broke and I need a new one today.
I still haven't got the software I ordered a month ago.
I need help debugging a problem with ______.
I'm struggling to learn ______ and would like to pair with someone on it.
I can't get the vendor's tech support group to call me back.
Our new contractor can't start because no one is here to sign her contract.
I can't get the ____ group to give me any time and I need to meet with them.
The department VP has asked me to work on something else "for a day or two."

In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues), he still takes responsibility for making sure someone on the team does quickly resolve the issue.

The vast majority of teams conduct the daily scrum meeting by having each person answer the three questions in order. You answer all three, then the next person, the next and so on. An interesting alternative that some teams find helpful is to talk through one product backlog item before moving on to the next. In this way, an individual may give an update at multiple different times during the same meeting.
Click to expand...

Link
 
And while everyone is scrumming I have banged out 1000 lines of testable code - whilst being constantly in touch with what's going on at any time through JIRA linked to Github linked to Zendesk linked to Slack.

The constant scrum. Kanban.
 
I hate these daily scrum meetings. I find it a waste of time to be honest.
 
**** Scrum, hate it.Probably only works at game developers where you get many people working on 1 title.
 
Complete waste of time imo. Been involved in too many to count and it almost always ends up dying out over the course of a project and then kicks back into high gear around delivery time.
 
Not a big fan of Scrum, too much admin and meetings. I find that Kanban works better if you're inclined towards Agile...
 
I'm not a fan of them either....I will check out Kanban and suggest it if suitable.
 
Like most formal software engineering - it is designed for teams of new, or subpar developers. I can see its utility, but am glad i've never had to donit.
 
Ideally, a daily scrum meeting is held in the morning
Click to expand...

Oh what crap, people are much more productive in the mornings... Let them do their jobs, if you're going to waste time with this nonsense do it in the afternoon when everyone is doing nothing anyway.
 
All this negativity towards Scrum? Sheesh. I find scrum meetings in the mornings very helpful. You get to know what everyone is doing, how far they are, what's next on the agenda and keeps the team focussed and informed. We don't limit people from talking, so if someone says they're working on XYZ problem, even though you're not committed to that issue, an offer of help or even advice in the meeting itself will quickly make lightbulbs go off and push the team forward in delivering to several clients.

We also adopted a strategy where, if you're stuck on a logic issue for more than an hour, you ask someone who isn't related to the project to help go through your thought process. You'd think the interruption would be devastating to the other person and their own work, but it's not.

You also get to learn better time management as things progress. I've seen so many programmers have 0 clue about how to estimate the time it will take them (with support interruptions and dumbass users in the mix), that they keep missing their own deadlines set out. Seeing how long things take others, and having a decent Scrummaster, makes a world of difference and time management skills go up.

With a focussed team we are usually able to deliver quicker than normal, when all of us hit our "deadlines" for the day, and there's a couple of hours left, we quickly duke it out with some SC2 or Quake

Those who claim they can write 1000 lines of testable code in the 15 minutes this should take is talking out their ass

What you need to consider is what works for you. If scrum doesn't, kanban/agile or even a mix of them works better.

This reminds me of all the linux fanbois moaning about how crappy windows is, if you don't like it, don't use it, or find a middle ground which gives you the benefit of both worlds.
 
envo said:
All this negativity towards Scrum? Sheesh. I find scrum meetings in the mornings very helpful. You get to know what everyone is doing, how far they are, what's next on the agenda and keeps the team focussed and informed. We don't limit people from talking, so if someone says they're working on XYZ problem, even though you're not committed to that issue, an offer of help or even advice in the meeting itself will quickly make lightbulbs go off and push the team forward in delivering to several clients.

We also adopted a strategy where, if you're stuck on a logic issue for more than an hour, you ask someone who isn't related to the project to help go through your thought process. You'd think the interruption would be devastating to the other person and their own work, but it's not.

You also get to learn better time management as things progress. I've seen so many programmers have 0 clue about how to estimate the time it will take them (with support interruptions and dumbass users in the mix), that they keep missing their own deadlines set out. Seeing how long things take others, and having a decent Scrummaster, makes a world of difference and time management skills go up.

With a focussed team we are usually able to deliver quicker than normal, when all of us hit our "deadlines" for the day, and there's a couple of hours left, we quickly duke it out with some SC2 or Quake

Those who claim they can write 1000 lines of testable code in the 15 minutes this should take is talking out their ass

What you need to consider is what works for you. If scrum doesn't, kanban/agile or even a mix of them works better.

This reminds me of all the linux fanbois moaning about how crappy windows is, if you don't like it, don't use it, or find a middle ground which gives you the benefit of both worlds.
Click to expand...

Scrum is agile :confused: So is Kanban.

The problem for me is I hate meetings since they disrupt my train of thought. With scrum it's not just your daily stand-up meetings, there are also meetings for backlog grooming, sprint planning and retrospective - and these aren't usually short meetings. It's just really tedious to deal with unless you're a PM sort of person, as they love running meetings...
 
I can't believe what everyone is saying. The whole scrum process done right is a killer ingredient. Well I must say I am not surprised people are bashing Scrum. We as a country all the way from private sector to public sector are not necessarily process orientated, in the sense we have more of a culture of get it done as opposed to how do you get it done.

Having worked with people who have a culture of putting the emphasis on how you get things done. I see the value of that mindset. Daily scrums are designed to give the team an indication of where everybody is at, any problems someone in the team has, and for the people in charge to pick up any bottlenecks. Suppose this does not happen how will the things meant to be addressed with daily scrums be addressed?. And is it necessary to address those things in another platform that will most likely be informal?
 
Last edited:
At Eskom we had meetings every.single.morning. With maybe 3 people out of 50 contributing. Nothing changed.

At my current company I think we've had 2 meetings in the last 14 months.
 
Mike Hoxbig said:
Scrum is agile :confused: So is Kanban.

The problem for me is I hate meetings since they disrupt my train of thought. With scrum it's not just your daily stand-up meetings, there are also meetings for backlog grooming, sprint planning and retrospective - and these aren't usually short meetings. It's just really tedious to deal with unless you're a PM sort of person, as they love running meetings...
Click to expand...

Scrum is agile yes, hope you got what I was saying. No 1 thing is the be-all-end-all of what works for people.

Meetings schedule throughout the day is what disrupts train of thought yes, but if you get to work at 7am (or 8am, whenever you're required to start work) and the meeting happens right then and there for 15 minutes, you don't have any train of thought TO disrupt. You literally get there, grab a coffee, sit in the meeting and go work.

With regards to sprint planning/backlog grooming etc. The planning meeting happens first thing Monday mornings. Backlog and retrospective meetings happen Friday afternoons (which helps in the sprint planning Monday morning).

This way we keep on track every day with where everyone is, how long they'll take to complete, if there's any pressing issues to discuss and if the previous deadlines were met or not. Any issues that doesn't involve everyone gets discussed on a one-to-one basis after the meeting with the scrummaster so that it doesn't stop the rest of the team going forward with their day.

By the time the end of the week Friday afternoon meeting comes, there's a very solid idea of where we are with all projects included. This meeting doesn't last longer than 30 minutes and we usually go home by 4pm that day. Any changes from clients communicated to us might be discussed in the same meeting to assess impact, but this is usually discussed in the next scrum meeting the day after the request (if any scope changes happen) and a later meeting organized if the programmer doesn't understand the requirement. We also discuss any backlog or issues that happened that week which might impact deadlines and deliverabilities. That way we communicate with the client immediately and pro-actively instead of waiting till it's too late because the programmer were too busy to be bothered with an update meeting and he just did his own thing.

Monday mornings, instead of a 15 minute meeting, we have an hour meeting. Discussing what needs to be done for the week, planning the day and where we are in the sprint.

It's actually very very calming discussing all these things and having a plan in place before starting to work. It helps the newer guys focus better and it minimizes disrupting meeting after meeting to discuss these things. If an emergency meeting has to be called, it's usually for the end of the day and not the middle.

This works brilliantly for a team of up to 20 programmers in my experience. Not sure how it will scale, but I'm sure the meetings can be split up per project and have their own scrummasters to handle a smaller group instead of 50+ people.
 
Voicy said:
At Eskom we had meetings every.single.morning. With maybe 3 people out of 50 contributing. Nothing changed.

At my current company I think we've had 2 meetings in the last 14 months.
Click to expand...

Then your scrummaster failed dismally if nothing changed. like I mentioned, it doesn't work for everyone. If you're in a team that is well-focussed already and can deliver on time with a project/scope that's well laid out by the project manager, then you don't need a lot of meetings. However, in my experience the project manager is usually a n00b, the client changes their mind constantly and the scope always changes. Instead of bitching about it, we change with it as soon as it changes. That's the point of agile.

It's not a be-all-end-all solution. Companies need to apply what works for them. If 2 meetings in 14 months works for you guys and there is no impact in productivity and deliverables to the client, then sweet, you have more time to spend on twitter and mybroadband then. For others, it's not as easy, especially the types who get "imported" from Pakistan/India who needs that kind of direction to thrive.
 
Agile when applied correctly is excellent. Scrums afford teams to remain abreast of what is going on with updates from the entire team.

What I find ****ing annoying and a waste of time are when people veer off and start going into detail and using it as a meeting. In my current team, these things go on for half an hour. I feel like dying every midday....

Wait. That is now. FML
 
Oooooh, how glad I am I found this thread. Yes, SCRUM. The big revolution of fixing it all. Another swearword IMHO on managing IT projects. But...wait, why are there managers? Aren't they supposed to manage the projects? Now the team members are managing it. Why, because, I've found in my 20 years in IT that 99 % of managers can't manage a Pee up in a brewery. Thought this morning in our SCRUM(16 people, 30 minutes, gives 2 days every day wasted). These days its like the monkey is the king of the jungle while the oak who should be in charge is out somewhere else not allowed in. But yaaaa, thats life.
 
envo said:
All this negativity towards Scrum? Sheesh. I find scrum meetings in the mornings very helpful. You get to know what everyone is doing, how far they are, what's next on the agenda and keeps the team focussed and informed. We don't limit people from talking, so if someone says they're working on XYZ problem, even though you're not committed to that issue, an offer of help or even advice in the meeting itself will quickly make lightbulbs go off and push the team forward in delivering to several clients.
Click to expand...
I couldn't give a rat's behind what someone else is busy with. The manager , dev, project, should know if I'working on something affecting someone else's work...
 
Scrum does some things right and some things wrong. It does force a team to communicate and be transparent which, to me, is its biggest positive.

On the negative side I do believe that it throws out the analysis portion of the SDLC which makes life a lot more difficult for everyone. In complex domains you iterate so many times that you end up taking longer to get something done than if you do analysis up front.

You also need to have 2 or 3 week sprints or your ceremonies take too much of a percentage of available time.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X