Why I Hate SCRUM Daily Stand-up Meetings
Why I Hate SCRUM Daily Stand-up Meetings
By Anonymous
I’ve been doing SCRUM stand-up meetings for 2 years before switching to a pre-sales role, and I’m going to tell you why I hated this.
Disclaimer: please keep your “you don’t understand what SCRUM is” comments for yourself. I understand the concept behind SCRUM daily stand-up meetings: it’s just that I don’t like them and I think that there are other ways to achieve the same results (it’s called “common sense”).
Let’s all happily meet in the morning ! (late people will be crucified)
First, the meeting is supposed to begin every morning at the same time. Why in the morning? Because “it helps set the context for the coming day’s work“. The issue is that developers – in France anyway – don’t like being told when to arrive in the morning: you arrive early, you leave early, you arrive late, you leave late !
But not anymore: with the SCRUM daily meetings, everyone needs to arrive more or less at the same time every morning (talk about freedom !). And if you arrive too early, you just wait for everyone while checking your favorite websites.Why? Because it takes a while for you to get “in the zone” … and you don’t want to be interrupted during that time right?
Did you clean your room honey?
Then, let’s talk about the famous 3 questions: “What did I do yesterday? What will I do today? Do I have any impediments?“
Sounds like what my mum was asking me when I was 5 years old. “Well, yesterday at school, I learned how to write my name. And today, I’m going to do some painting… but it’s hard: can you help me mommy?“.
On top of this, the need to setup a meeting to learn what my colleagues are working on feels so wrong to me. As the member of a team, I happen to know what people are working on just by talking to them during coffee/lunch breaks. Also, reading SVN commits comments is a great way to keep an eye on what people are doing.
Join up, they said! It’s a man’s life, they said!
Finally, I’ve always liked testing new software components. This is a way for me to learn new stuff, which is always exciting… and it keeps me motivated.
The problem with the daily meetings is that you cannot say things like: “well, yesterday I finished working on the billing component and today I’m going to spend a couple hours studying this new PDF rendering library because it looks very cool, even if this is something that has nothing to do with the backlog“.
So why don’t I like standup meetings?
- because I don’t want to be told exactly when to arrive in the morning.
- because I don’t want to wait for everyone to arrive before being able to really start coding.
- because I don’t need a daily meeting to know who is working on what (I’m a social guy and I use coffee breaks and lunches to talk about that !)
- because I don’t need to scream for help: I know who can help me if I’m stuck.
- because I’m big boy !
The name of the author is withheld, as it is his wish to be anonymous.
As a Project Manager / SCRUM Manager, I can completely understand your frustration and I’ve experienced it before with team members I’ve worked with. A couple of thoughts came to mind as I read your article.
1. SCRUM / Agile is a tool which doesn’t fit every situation or problem. Just as a wrench could tighten a screw, but not as well as a screwdriver, SCRUM won’t work for every team or situation. Likewise, SCRUM offers many different artifacts and processes which are designed to make shipping software easier. If an artifact (Product Backlog, Burn-down charts, etc) or process (Daily Stand-up, Product Review, etc) doesn’t work for the team, it should be replaced with something that does.
2. Not everyone works the same hours within the day, but almost all have overlapping time beginning sometime in the morning hours or early afternoon hours. The Daily Stand-up should be used as a checkpoint not for the 8-5 work day, but for all work between this meeting and the next one. If a team member goes home at the end of the daily stand-up meeting and returns in the middle of the night to work until the next meeting, that’s fine. Waiting for the daily stand-up should never be a reason to sit idle.
3. This is a team process. For SCRUM (or any process for that matter) to be successful, you need the buy-in and active participation from team members. If someone is struggling with an aspect of the process, it is incumbent upon them to raise their concern and work pro-actively to address it. Perhaps they will have to adjust their work habits to conform, or perhaps accommodations can be made to ease the difficulty. The point is that everything should be discussed openly with the team so everyone can hear and work to solve the it together.
I love it!
All of the ceremonies in Scrum, as you’ll no doubt be aware, are put in place for good reasons. They must, though, work for the Team as a formal mechanism for reporting status to each other, as well as for the Scrum Master so that he has an opportunity to formally ask whether impediments are stopping the Team from progressing their work.
Many people, when stand-ups don’t work for them, complain and don’t attend. As a Scrum Coach, though, I use a ROTI activity (return on time invested) to understand what the Team feels can be done in order to make this ceremony (and others) better. Sometimes, it’s about the timing, sometimes it’s about the frequency. So, we do what ever we can do empower the Team to make it better. In essence, this approach is designed to be faithful to the inspect/adapt approach that underpins the success of a good Scrum team.
M
You are exactly right Laurent.
Many of the aspects of Scrum are childish and degrading, as well as nonsensical.
Coupled with the fact that there is no evidence that Scrum is any more effective than placebo, it’s time for people to reclaim their lives and stop putting up with this fad nonsense.
PA
Just a few things to point out:
* Scrum does not tell you when to arrive at work or when to do your standup meetings. You as a team should decide when the meeting happens. The Daily standup is however part of Scrum framework as you noted.
• Scrum does not ask you to wait for everyone to arrive before being able to really start coding. You can start coding whenever you chose to.
• Scrum is about the team therefore for the non-social folks on the team who hate coffee breaks I can either force them to be social and have coffee breaks or create a time for them to have these conversations with the rest of the team for 15 mins. However there is more to the Daily standup than coffee break conversation. You just may not be doing it right (like sex :) )
* Scrum ask that you remove impediments to your work screaming for help is one way or going to the right folks to get it removed is another. Ensuring that they Scrum Master, Product Owner and the team is aware of the impediment and actively working to remove it is also an equally effective way to get un-stuck.
• Scrum believes that you are indeed a big boy. Scrum ask that we let you make your own sprint committments without outside interference. Scrum as that you solve your own problems as a team in your own ways. Scrum as that we trust that you will do the right and best thing given the resources available to you and your ability.
Final notes:
* Following Scrum is simply. Living the Agile/Scrum principles is not as simply as following the framework. My guess is that your team may have implemented the framework but has not yet matured to following Agile principles/values
* If the Daily stand-up is not working for your team ask them to vote it out or propose modifications to improve the value you or the team gets out of it.
* Scrum does say that Business drives development therefore while it may give you some great pleasure to go look at the next shining thingy. You should ask yourself if this delivers value to the folks who help pay to keep the lights on.
I think that some of the commenters misunderstood your reasoning for why daily morning meetings are harmful to productivity. Yes, of course you can try to work for the 1 or 2 hours before the meeting while waiting for people to show up. But, as with any meeting, a hard, known interrupt is going to prevent you from starting certain activities that will take longer and require focused effort. Let’s not pretend that working from 8am to noon without interruption is the same as working from 3-5pm the previous day and 8-10am the next. SCRUM creates overhead. That is a fact that no one disputes. The question is whether that overhead is worth what it provides. The answer is not always yes.
I was on a project where 4 of us were working very effectively together in a lab while collaborating when necessary. We were like a well oiled machine until some corporate initiative decided that everything needed to be SCRUMed. To me, it seemed like a formalization of what we were already doing very effectively on our own.
If people are already working as an effective team (especially if they are already working in a SCRUM-like manner by collaborating informally for a few minutes when they come in and remaining focused throughout the day), there is no need to formalize the process in my opinion.
I agree that SCRUM is degrading to people who already know how to work and collaborate effectively. Many people say SCRUM is not intended to be your mommy and that you are empowered to make your own commitments and solve your own problems. However, as they say those things, they want to watch you do them to make sure you are doing them right. To me, it seems very much like helicopter management.
Don’t get me wrong. SCRUM definitely has a place in certain projects. I have run into many people who become easily “stuck”, quickly lose focus or go off onto various tangents. For those people, SCRUM is probably very useful. But it’s not for every person and every project. And when SCRUM isn’t working out, it shouldn’t be considered a failure on anyone’s part. It’s just a sign that you should try something else.
This blog posting gives (yet) another good reason for a good timing of the daily stand up. I like it to held those from 11.45 to 12.00 hour.
1. Everybody is in at that time.
2. It is late enough so that everybody starts working beforehand.
3. Afterwards the whole team can continue the conversations during lunch.
4. The pressure to limit the time for the stand up is built in because of the upcoming lunch break.
Furthermore planning-sessions are held at the end of the previous sprint (while the software is built and quility tested and distributed, code freeze and all) so that we don’t have to wait in the new sprint for everybody to arrive (and if somebody wants to start during the weekend, it is possible too :-) )
With kind regards,
Fred
I can say, as someone who is forced to attend these every agile morning. These are not only a huge waste of time, but they also instill a sense of non-trust in your employees. Our meetings every morning begin promptly at 8am, and being even 1 minute late will mean you are repremanded on the spot, in front of the team. As an employee, I feel extremely micro-managed. These meetings make me feel like my employer doesn’t trust me to get my work done independently, and that they need to continuously be watching over my shoulder. As a manager, you need to allow your employees to professionally grow on their own. The daily check-in meetings I am forced to attend, are nothing more than a way for my manager to make sure we are all in at 8:00 on the dot, and a way to micro-managing us employees. Don’t get me wrong, I think it is certainly important to maintain communication between a team, but that can easily be achieved with a once a week meeting.
Point #1 strikes me as immature and irresponsible. Though it’s an emotional viewpoint and if that is how the author feels, that’s how they feel.
The rest of the points are highlighting how a particular SCRUM implementation treats people like they are all adolescents. I think they are more fundamental to not liking the way SCRUM was implemented.
The lack of forward thinking that can come out of SCRUM leading to constant refactoring would be a more generic structural reason to not like SCRUM. I know the refactoring ‘flow’ is one of SCRUMs bragging points. I simply disagree it’s always applicable.
Sometimes you DO know what you need to build and some of the units of work do not always fit into a fixed two week window. SCRUM might be decent for building UIs, but, I think underlying infrastructure often needs more forward thinking in it’s planing than just the myopic thinking that is encouraged in meeting an arbitrary two week window for development.
I also think the argument that you should not estimate time, but rather that you should estimate effort is basically silly. The only gain out of this is that you can recognize tasks that can be need to be broken up into smaller tasks. But then, doing that is a normal development task anyway.
In fact SCRUM is not really different from what we’ve been doing for years before SCRUM was developed (incremental development, testing during development, discussions with interested parties about what they really need, Business needs driving development, etc…).
SCRUM just seems to make it all very childish.
Hi.
Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to ʺautomateʺ the daily standupmeetings – with just a single email.
If you like to take a look: http://www.30secondsmail.com.
Best, Revino