Why and for what reasons developers may not like "daily scrum"? [closed]

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

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 5

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 6

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 7

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 8

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 9

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 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

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.

Answer 12

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.

Answer 13

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.