However, recently (after 6 months of implementing and using scrum), I feel like that our developers don't like scrum daily that much anymore. People just update the task board, without explaining enough and it seems that they're bored of it. I see that when for any reason, we don't hold it, they kind'of become extra-happy.

I just don't know what could be wrong with this. Are there any reasons mentioned somewhere for disadvantages the "daily scrum" can have for a team? What could be the reasons for developers getting tired of daily scrum?

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

11

My problem with daily scrum meetings is that they start out fresh and on topic and quickly turn into 45 minute gripe-fest about management, unclear requirements, technical and political barriers and the poor quality of bugs that QA are writing.
–
maple_shaft♦Sep 8 '11 at 11:00

2

@Michael, We didn't have a scrum master, that was the problem. The only reason we did daily scrum meetings was because entrenched management was running the project into the ground at mach 10 and they needed to make superficial meaningless process changes for the sole purpose of appearing like they are addressing "the elusive problem". Of course saying we need to do daily scrum meetings is a lot easier than saying, "maybe if I focus on not micromanaging developers and taking a 4 hour lunch everyday then we can finally put out quality software"
–
maple_shaft♦Sep 8 '11 at 11:29

13

Honestly, I would really hate to be asked to go to a meeting every day and tell everyone what I've done. I'm trying to do work. The "atmospherics" surrounding the meeting - the context switching, the hallway chats, the waiting for the room - are going to eat time like woah. Better - IMO - to have organic meetings as needed.
–
Paul NathanSep 8 '11 at 16:11

Daily scrum puts too much stress on a developer to produce something daily. They need freedom to experiment freely without having to justify their experiments to anyone on a daily basis. Weekly is better.
–
A-B-BJun 11 '14 at 3:03

13 Answers
13

I had experience participating in a "SCRUM" team with several employers. It appears to me that the managers take out the "daily scrum meeting" as the main point of SCRUM, and set it as the goal, instead of having it for what it is: a mean to achieve more effective development cycle.

Very quickly the 15 minutes meetings became 45 minutes meetings, the updates were ineffective because people would be busy yawning and thinking "when can we go already" instead of listening to others, and it would also break people's routines (I, for example, am an owl person, and getting to work at 9AM for this stupid meeting every day is a good enough reason for me to quit the job).

When managers take some idea which may be good if applied correctly, and take it to the extreme - they get the exact opposite of the results they expected. I personally think that the more meetings I participate in - the less work I'm doing. I have 2 regular meetings a week in my calendar and I usually skip one of them. Meetings are for managers, leave the developers to do their jobs.

I'm sure there will be plenty of SCRUM enthusiasts that will say "But it's so wonderful" - well, save it, I've heard it all.

When the 'previous day' is discussed it means since the last meeting and is held roughly 24 hours appart. No reason you couldn't have it when you start the day or a few hours later. Everyone is not forced to code at the same time.
–
JeffOSep 8 '11 at 12:34

5

@Jeff - tell it to the managers. In any case, SCRUM is good for ad-hoc development, but will not work well for a long term preplanned development process. When I have a task that lasts for a week, what should I be talking about at the daily meeting? "I finished writing another function"? Who cares?
–
littleadvSep 8 '11 at 18:34

5

@littleadv: "I am continuing to work on function X. I have no roadblocks" is sufficient for a scrum meeting. That is important information for the team. As for scrum only being good for ad-hod development, I'll have to disagree. I've seen it used for long, sustained, successful projects. It's up to the team to do it wholeheartedly, but it's not a silver bullet. It works for some teams, not for others.
–
Bryan OakleyJan 24 '12 at 12:11

2

+1 I've never met a daily scrum that took 15 minutes. Most take at least half an hour, and lose focus pretty fast :( I think there is value in a short status update, but unfortunately no shop I worked in managed to keep it short.
–
Andres F.Jan 24 '12 at 12:57

5

Another problem is when the "have the devs tell us what's going on" meeting becomes "have the devs tell us all about their thoughts on where they will go next". Very different, and takes a great deal more time. And then management thinks, oh since we're all here anyway, lets roll another meeting into this one!
–
Spencer RathbunJan 24 '12 at 14:21

But @dietbuddha, how is it scrum, if developers don't share information or parts of project?
–
Saeed NeamatiSep 8 '11 at 5:23

3

"The information being shared never pertains or affects me in any way." made my daily scrum boring.
–
René NyffeneggerSep 8 '11 at 10:41

2

@Saeed Neamati: A Thing is not necessarily that for which it is Named. That doesn't mean you aren't doing Scrum. I don't work with you, so I can't know. There can also be a difference between how things are suppose to be done and how they actually are done.
–
dietbuddhaSep 8 '11 at 16:41

those which last too long. You don't want any manager guy in those daily because they're the root cause of this kind of problems. See how they'll usually be the ones using a chair (yes, having to stand up for those is to entice people to be fast)

having to hear about someone (or 2 or 3 devs) describing whatever isolated problem he has at length instead of him deciding to schedule another real meeting later to discuss it with the ones concerned

stupid hours. Those meetings don't have to be in the morning: you're not speaking about what you've done yesterday and deciding what you'll do today; you're speaking about what you've done between last daily and this one and deciding what you'll be doing until next one.

lack of ownership of the app for the devs. SCRUM works if devs are not treated as code monkeys. The first sign of the process going wrong is when the devs are not the ones evaluating how much time something will take to be done.

stupid hours again. If part of the team has started working on some things and are "in the zone" when the daily happens, it becomes a bother. A good time to have those daily is when no one should be working (after lunch for example, or just before to start some discussions to have during lunch).

@jhocking: Actually, it's perfectly ok for managers to be in the meetings (or stakeholders, or just about anyone who's interested). However, the rule is: Only the developers talk. Everyone else only speaks when they are asked. It's that simple... (and yes, our mangagers do attend daily scrums, and they abide by that rule).
–
sleskeSep 13 '11 at 8:30

2

If your managers can stick to the rules that's great.
–
jhockingSep 13 '11 at 11:27

I've personally encountered deficient scrum masters who abused a "flexible hours" argument to hold dailies when it was convenient for them, so that's one potential minefield. The other one is starting "after" something. That makes a daily look like something "lumped on", whereas starting "before" not only breaks this perception, but also helps keep the meeting concise. That's why mornings are often preferred - the daily occurs before "proper" work starts.
–
mikołakFeb 28 '14 at 22:11

+1 for your last point (plan when not interrupting work, i.e. the thing i couldn't quite finish the night before or had a brilliant idea about at home).
–
Cees TimmermanJan 30 at 9:52

Timing is the killer for many. Programmers like to code late, sleep late and come in after the morning rush. Having to be in office at a fixed time - way too early for them. And too late for others who may come in earlier and start working already.

Flow is another issue. A programmer in flow with some feature will work until late at night, go home and come back recharged and ready to continue. Having to sit through a meeting with mostly unrelated issues may distract him.

My observation is far too often these meetings are for the managers to look and feel like they're actually doing something rather than them being useful for the team and the project.

For example, a team is assigned to do series of short bug fixes on different projects. They're really not working as a team but as individuals. However, because company/department policy mandates it, the team lead/manager holds a daily scrum meeting anyway. All that's accomplished is taking out 15+ minutes for a useless meeting and tacking on 15-30 minutes of distraction and lack of productivity before and after the meeting.

Now, I have seen scrum done well in a project that had tight deadlines and required a lot of coordination between people working on various pieces. In that context it was a great system. But, in the context of "We're having a meeting because we're a scrum/agile shop and that's what we're suppose to do" can really suck.

If 4 of the developers get their spiel out of the way in 5 minutes, and the next 10 minutes are spent listening to the team leader detailing all of the amazing, awesome new developments he's made, most of which are neither as amazing nor as awesome as he thinks they are, people will get very bored very quickly.

Stand back a moment and think about your team:

Are they working effectively?

Are tasks completed on time?

Is the code robust and well-written?

Does the team ensure that nothing falls through the cracks?

Does the team co-ordinate itself so that they don't duplicate work or tread on each other's toes?

If your answer to all of these things is "Yes", perhaps you should consider why you want to force busywork like daily meetings, burndown charts and task boards on your team. What value does it add? Do you want to generate bureaucratic data solely for your own enjoyment or are you trying to make the team more productive?

Has there been a decline in productivity since the daily scrums stopped, or is everything ticking over the same as before? If nothing has changed, why continue the meetings?

15 minutes. Does that 15 minutes (plus the time to prepare for it) convey enough new and useful information between team members to improve the teams productivity for the coming day by more than 15 minutes worth? If there's not that amount of useful scrum content each day, the team members are probably thinking that they'd make far more progress toward the goals if they got out of this meeting ASAP and got back to work.

If you just want to update the board and chart frequently, put draft copies on a wiki.

I'd suggest if you hold the Retrospective meeting to see "What went well" and "What did not go well" and see if the developers list the daily Stand-up meeting itself as a waste of time. Then you would need to re-organise it a bit.

My personal experience:

The aim is to know what we are doing today and where we were
yesterday. Instead of sticking to the agenda, it gets down into a
technical discussion of blockers between 2 persons and the other 15
get bored. Identify the problem but discuss outside

People don't get into the meeting room on time, and this becomes a
cycle done by some on purpose. So the Scrum Master needs to have a
quiet discussion with them outside of the meeting to ensure they
start and end on time.

We already update burndown charts outside of the Scrum meeting so
that is not the main purpose of the daily stand-up.

+1+1+1 This is the answer. Places where I've worked that didn't do retrospectives, had all the problems that everyone outlines. Where I work now we have Scrum, Scrum of scrums (interteam), retrospectives and even retrospectives of them. All to assure that the things that bug you and aren't working stop or change as much as possible and things that are going well are continued. Without this scrum becomes pretty boring and off-topic easily. I also believe that the "meetings" that are denigrated by so many are great if they have really good communication, are on topic, on time and short.
–
Michael DurrantMar 1 '14 at 0:07

The resistance comes when:
1) They are used to force people to rush in for 9am. It's extra stress when the train is late.
2) Poor scrum leadership. The leader should be telling people to take stuff off line rather than have people stand around listening to something that doesn't affect them.
3) Valueless content. This is again a scrum leadership issue. It is supposed to be a forum to address bottlenecks, trajectory issues and potential collaborations. What actually happens is everyone just says what they expect to work on that day which is of no use or interest to anyone else.
4) Standing. I won't stand for standing. The logic behind standing was that it encourages people to be brief. People actually just rattle on regardless.

I've managed and been a part of scrum teams many times. The key reason developers don't like scrum are:

Because they run by a very poor scrum master, if it turns into 45 minutes your scrum master needs to improve at controlling the scrum.

The biggest and by far THE most honest reason why they don't like it, is because it's very hard to hide in a bad work ethic, i.e., more blatantly, it shows up lazy people. Some devs I've worked with are shocking, they take days doing tasks that should be 30 minute job. A good PM should remove barriers for devs which means they should be able to plough through their tasks in a sprint. Devs don't like it because they have to stand up each day and demonstrate the progress they've made. It causes anxiety when they can't demonstrate progress for what ever reason. If it's because of a valid issue a good scrum master should resolve that issue asap.

The problem comes when scrum masters doesn't have the authority, skills or capability to resolve blocking issues. In fact I've seen some just bury issues hoping that they will go away. This is disastrous.

Frankly, in 99% of the daily scrum meetings I've gone to, pretty much all the discussion/questions/answers could have been remedied with a few emails.

I honestly think we need to show more valid reasons to NOT have meetings. Build environments where when it's time to corral everyone into a room in-person, that it had better be a good reason and be organized to maximize time efficiency.

I hate meetings in general, and would prefer to use video conferencing, phones, emails, anything that allows me to get into or stay into my work without having to get up and interrupt my productivity flow.

I personally think if you have more than four meetings in an 8-hour period then projects aren't being managed well.

this does not even attempt to answer the question asked: "Why and for what reasons developers may not like “daily scrum”?"
–
gnatFeb 28 '14 at 16:08

1

I just did. I don't like daily scrum because it's not necessary. A few emails could easily handle most of the needs.
–
Alex MFeb 28 '14 at 16:34

2

Interesting thought...and maybe it's because MY scrum experiences were not good. Perhaps "daily" should be "weekly" in certain cases. I know for me a weekly would be more effective than daily.
–
Alex MFeb 28 '14 at 17:01

There are many factors which contribute to the tension over meetings. Consider these as some of the important reasons why meetings may be costing you more than they are worth:

Focus - software versus meetings

Management - managers need measurement

Personality - Introverts vs. Extroverts

Time - interrupts, Maker and Manager time

Goals, Priorities

Each of those factors is explained below,

Focus - I enjoy developing software, and that includes thinking about the challenges (problems), creating solutions, building the software, and meetings distract from focus on the tasks that build the software. There is a state called "Flow" where a developer is immersed in the challenge (problem), has built a mental model of the solution, and has complete focus on building the solution. A developer may work until midnight, leave only to eat and sleep, then return to a state close to where they left.

Developers need to avoid distractions, and many find that there are advantages to code late into the night (they avoid the noise, phone calls, busy office, and non-developer colleagues interrupting their work). And when you have worked until 10, 11, or 12pm, it is not unreasonable to come to work later (10, 11, noon?). Is it reasonable to expect developers to work from 9am until midnight?

Scrum (and any) meetings distract the developer from their primary purpose, which is building software.

Management - Managers need to measure in order to be successful, hence the need for schedules, deliverables, timelines, priorities, and meetings to measure and report progress, and to expose dependencies, delays, and risk areas. The challenge with a Scrum is that a manager needs these things, but the developer needs focus. Meetings serve the manager, and provide a way for the manager to obtain, measure, and track status and progresss, but meetings seldom provide utility to developers. Consider that managers provide more value when they handle distractions, remove barriers, and enable developers to focus on building software.

There are solutions to the need for meetings. A manager could visit their developers, ask for status reports, adopt a protocol for when interruptions are less intrusive, or adopt a policy that the developer to notify them of progress when the developer is interruptible. See the discussion of time for why this is important.

Personality - Consider that some people are introverts and others are extroverts. Extroverts enjoy social interactions, and are recharged by them. Managers are typically extroverts (because extroverts are usually better with social interactions), though introverts can be successful as managers. Introverts can enjoy and even excel at social interactions, but are recharged by solitude. Developers are often introverts, and are successful working alone (or in small teams) because they do not "need" social interactions; they can be happy working alone on problems (although extroverts can be developers too). Daily scrum meetings can become social gatherings, good for extroverts, but not so good for introverts.

Time - Developers cannot write code while they are in meetings. Neither can they think about hard problems (unless they are brainstorming), while distracted by meetings. Developers need large blocks of uninterrupted time to focus on building software. Meetings are interruptions which distract from their efforts. When you have been immersed in solving a problem for hours, are nearly done, and someone says "time for the scrum", you are interrupted, and lose perhaps hours of work while "shifting gears". Or you have stayed at work until 11:00pm, left work, travelled home, slept on the problem, woke up, travelled back to work ready to solve the problem, and then get interrupted after an hour of working on a problem, because it is "time for the scrum".

Paul Graham has an excellent article on Maker Time vs. Manager Time, which explains this problem far better than I do. Suffice to say that a meeting interruption, whether planned or unplanned can break flow, and force a developer from Maker time onto Manager time. Believe me, you want developers on Maker time.

Goals, Priorities - Developers and managers have different goals and priorities. Managers have the onus to track schedules, minimize cost, ensure that their reports are responsible, and that they perform. Developers have the goal to build the software that addresses the challenges/problems. These goals are not in conflict, but it is the communications mechanism that creates the tension. Meetings serve the manager's needs and optimize the managers time, but they conflict with the developer's needs. Scrum meetings discard the first rule of meetings, "have an agenda", and tend to wander more. And meetings are used to optimize communication (for the manager), but they cost the developer time (interruptions, loss of flow, etc).

What is the goal? To build software that addresses the needs, quickly and with quality, while constraints are (quality, time, cost, process). Scrum and other agile methodologies recognize the process constraint, and try to minimize that factor, and have been successful because they minimize that constraint. But adding meetings does cost time, and the interruption costs the developer much more than the duration of the meeting.

Schedule it at a time that offers some convenience. Why can't it be 30 minutes after work starts so everyone can review email and organize their thoughts for the meetiing. Brevity takes planning. The unprepared can ramble on forever.

Identify problems that could have been avoided had an issue been communicated during the meeting. Everyone needs to understand what is the point.

Do whatever it takes to keep everyone's input to a minimum. It's not the place for debate. Encourge people to privately schedule meetings outside of the daily meeting focused on a topic that needs discussion. Rule: only one person talks at a time.

All the complainers need to make sure they're not contributing to the problem. If you can accomplish your goals for the daily scrum without having one in a less painful manner, we'd like to hear it.