Why and for what reasons developers may not like “daily scrum”?

Question

There are advantages in holding daily scrum, like:

1. Team get coordinated with each other
2. Everyone knows what amount of task has been done
3. Burndown chart gets more and more complete
4. Task board is updated
5. It doesn't last that much, 15 minutes won't kill anybody

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?

Answer 1

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.

Answer 2

I would find daily stand up boring and useless if I felt there was little to no value in it. There are a few things that can reduce the utility of a daily standup.

• The information being shared never pertains or affects me in any way.
• Absence of team ownership and everyone always working on their own projects.
• Absence of team communication outside the standup.
• Lack of visible or communicated progress.
• Absence of information to share.

These are just off the top of my head, but there are always more possible reasons.

Perhaps you should just ask the developers straight out why they don't seem to be interested? If you want more/better communication it should start with you.

Answer 3

Some of the problems encountered with daily SCRUM meetings :

• 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).

Answer 4

Make sure that no-one monopolises the meeting.

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?

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

Modify the meeting to make sure it delivers benefits:

1. 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.
2. Identify problems that could have been avoided had an issue been communicated during the meeting. Everyone needs to understand what is the point.
3. 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.