In my opinion standups are mood killers.
If you need something, you ask for it anyway. Anything else would be ridiculous, you have a job to do and you need something from somebody so you ask. This is collaboration 101.
Yeah sure, there is some tiny possibility that person A happens to mention his approach to some task and person B happens to know a better way, but really that is such a motivation killer for several psychological reasons, but even more than that: How likely is that? It never happens anyway and if you know your colleagues, you likely already know if they probably can help you with something and you ask them for some pointers. If you don't do that, a standup isn't going to help you because you don't want help.
So for who's benefit are standups and "agile" in general?
It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing.
For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers.
Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.
On the other hand, its very common for a team member to get blocked and not know how to get unblocked. A (occasional) standup can get them past that. And one blocked team member can quickly become the long pole on the tent.
Standups and agile are quite useful, especially for new teams or teams of greener developers. Which, in our growth industry, is 'most teams everywhere'.
If you're part of a team that's worked well for months or years, then the utility is greatly diminished. I think standups can gracefully fade away after some months.
> On the other hand, its very common for a team member to get blocked and not know how to get unblocked
Yes of course that can happen and I said so, which means that he should ask whoever is blocking him how to proceed. If he doesn't know who it is, he asks the manager and he will direct him to the right person. If there is literally no way to proceed, he will work on another issue in the meantime and inform the manager that he's blocked on the more important stuff. If there is some way to speed it along together with multiple other people, it will come up when he talks to that first guy. Obviously waiting for the next standup tomorrow is a ridiculous proposition, so standups solve a problem for 1 time of the day requiring by definition more people than should be required because everyone is in it instead of pulling the people in that need to be pulled in for that specific block or feature.
I don't even know how people defend standups, they usually say something like "hey yeah, I know it's mostly useless but it's just for 10min a day". Absolutely unacceptable. Now I get to the last line of your post, and it's such a relief: "I think standups can gracefully fade away after some months."
Well you should tell the other proponents of standups because I can guarantee you that this never happens.
Standups might be a good idea in the starting phase of a projects but frankly even then it's debatable and then you would just call them meetings.
Green developers can not know who to ask (they're new, right?) or not know when or how to ask. They can be quite tentative. We're talking Engineers, not Sales guys.
Some folks don't think they need standups, ok. But in reality, many folks benefit from them.
I agree, even experienced developers can get stuck barking up the wrong tree.
There are at least one or two exchanges like this every week in my team:
Dev A: - I'm working on X, and will just need to fix the code for Y to handle it. It's a bit messy but I'm probably done tomorrow.
Dev B: - Eh... I think you need to do something to the Z code, we can take a look after the meeting.
Dev A: - Sure.
> its very common for a team member to get blocked and not know how to get unblocked.
Is it? I haven't seen this very often and only with very junior engineers. Anybody with even a modicum of experience knows to ask for help when they're stuck. On the other hand, what I have seen all too often is an experienced dev blocking everybody else because of poor scheduling by the manager. Oftentimes, there's no way others can help with this. The dev knows what needs to happen, but it takes time and the dev just needs to do it. This makes every standup a humiliation. 'Is Joe still blocking Ted and Tara? Can you speed it up, Joe?'
That is exactly how I see and have experienced it as well. It's part of why I called it a motivation killer but I didn't go into more detail.
Not only because of the accusatory thing but also I actually like to surprise my colleagues with cool features and issues I solve, surprising them with my speed even. If I attend a standup, I need to report that I'm working on these things so the surprise is gone. All my motivation to get them done asap is gone. Likewise, I can't do my own "secret" time planning anymore. I like to finish some mandatory feature fast so I can squeeze in a little extra cool thing I wanted to do for a long time. If I have to explain and justify this stuff, the manager will step in and urge me to do other mandatory things instead. It's such a mindkiller.
When I manage teams, I love having productive and self-motivated people like yourself on the team. As long as you are able to complete the scheduled and required tasks, if by being light-touch with process, you are motivated to contribute above and beyond, the whole team reaps dividends. I have seen such members contribute great tooling upgrades, features to reduce administrative overhead, automation mechanisms, and even delightful user-facing features.
In my opinion, processes are designed to resolve or prevent dysfunction. An extra-productive team member that completes assigned tasks and adds in some of their own creativity on top is generally not a source of dysfunction, so I prefer to encumber such people with as little process as feasible. I for one love engaged productive developers who deliver bonus features of the sort I mentioned above and I find over-processing curtails those bonuses.
This is exactly why you should be in a standup. "Secret" time planning and developing "cool" features. Someone has taken the time to carefully plan the features required for a project and make projections of how long that will take and how much it will cost. There may have been customer feedback on what features are required, or possibly even a customer is paying the costs of certain development work. And you think it's your job to just secretly decide that you don't want to do that, you'd rather spend time working on something cooler that the customers might not even want or perhaps conflicts with other project plans.
I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation.
The last thing I want is to be surprised by a new feature just showing up unplanned in a project.
I dunno, perhaps you work on internal software for a small group of specific known users who sit a few desks away from you and that's acceptable to them, but for any team building a customer facing product that attitude would be a nightmare to manage.
> I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation.
When the managers stop doing this, we'll stop doing this. This adversity between engineers and management is one of the biggest reasons I hate the agile process as it is commonly practiced. It benefits management at the expense of engineering, thus creating animosity between two groups who are supposed to be working together.
Blocked beginners usually know how to ask their way out of blockers without standups.
Another bigger problem with beginners though is the "creative" beginner. For those a stand up is a good place to catch "I just started writing a parser for X to solve problem Y" when there already is a company standard X-parser that the beginner doesn't know about.
I'm probably biased because I have for decades simultaneously worn both IC and manager hats, but I think you are overlooking the importance of passive awareness. It's not simply a matter of everyone knowing what to do and asking for help when they get blocked, there is serendipity and ad-hoc collaboration involved too.
If you are small and everyone is sitting close together at the same times, then maybe you have enough chemistry and passive awareness already and things can just flow naturally. That's amazing when it happens.
But there's lots of reasons it doesn't happen. Could be whether there are remote team members, or some team members are shy, or there is a general vibe discouraging interruptions and creating a chilling effect. In those cases, taking a couple minutes to share can be very helpful to keep people on the same page. Granted, every single day is probably excessive for this use case. Traditionally I've had best luck with once or twice a week.
As to capital-A Agile, I think it's even worse than you say: it ends up being used by consultants to justify their bloated bills. I would encourage you to go back and re-read The Agile Manifesto though, and realize that this is just what happens when good ideas are cargo culted and productized by the snake oil salesmen.
More generally though, I want to challenge the idea that something which only benefits managers is a waste of time. Good managers spend all their time doing things to help their reports, so why wouldn't developers want to take a chunk of time to help the manager do their job? As a developer it's nice to have your task and be able to focus 100%, but that will not be possible or effective if there is no coordination with an eye towards the end result. It can definitely work, but it requires ICs taking on managerial duties (even if they don't label them that way), and it is rarely as effective as having a good project manager once you reach a certain scale.
I don't think that I'm underestimating the passive awareness effect, I think it's very negligably useful. Not only that, it should obviously be solved by a great wiki-type solution that doesn't exist yet. It would be some kind of addon to jira or maybe one of those corporate facebooks that never quite took off or solved the problem that they were supposed to solve.
Solving this problem by forcing people to talk to each other in standups is just about the least scalable, least enjoyable solution possible .. especially for people who probably became programmers not because they like talking to people.
Inter-departement standups could work in theory but then you realize not everybody can attend because it would be too big of a group.
Then you end up with 1 guy of each team having to explain what the other teams are doing to their team.
I'm also not knocking managers at all. I'm more than thankful for when they deal with clients and project management and solve inter-team issues and and and. That is real value that they are creating.
I already conceded that daily standups are probably overkill, but you are going to great lengths to overestimate the cost of a standup. It's not unreasonable to spend 20 minutes a couple times a week to let your colleagues know what you're doing.
Using some a wiki is emphatically not the right tool for the job. If the personalities are such that you really don't want to have to talk to a group, you could use something like StandupMail.
Also as a single developer, it's entirely possible that you don't know what you don't know, and thus your estimate of value is dubious. As someone who built a product from 0 to 7M users and took a team from 3 people in a room to a team of 50, I can tell you that once we passed the 7 or 8 engineer mark but before we had bi-weekly standups, there was steady drumbeat of cases where the right hand didn't know what the left hand was doing. One way to manage this would have been for the PM to micromanage everyone, but given that the team was built of entpreneurial full-stack hacker types, it worked a hell of a let better for people just sync up as a group periodically.
Obviously you are entitled to your opinion, but also consider that the corner of the dev world that you inhabit is not representative of the universe of software development, and just because sometimes there is a cargo cult mentality doesn't mean that there aren't good reasons for some overdone practices.
I came to the same conclusion - standups are placebo for managers and nocebo for (at least some) engineers. Meaning, they have no observable effect whatsoever, they only make managers feel better and engineers feel worse.
Unfortunately, SCRUM (and many other methodologies) is not based on scientific method. If it was, then all placebos and nocebos would be weeded out during empirical testing.
I'm a senior lead on a team that had massive turnover and now has all new people. We support many large and complex web stacks. As a result the guys on my team don't always know how we do things. Many will agree to commitments they can't fill.
A 15 minute standup means our team leader and I do not have to wonder what they might be doing or creating. They say what they are working on and we guide them. Daily we catch issues where they overly complicating something, or scared to ask for help, or doing any number of crazy things.
We are very laid back and don't have huge timelines. If someone doesn't show up or have much to say we don't even talk about it. We know they work hard when they do and standup is never about finding out if they are working or not. In a large enterprise the team leader has meetings all day and can't know what is going on when they have 10-15 people under them. The standup solves that issue.
It works great for us and no one has any issues. I'd much rather talk about what I work on for a few minutes each day than be micro-managed.
I don't understand why you cannot ask your newbie members casually each day, what they are doing and if they have any problems? That way you can actually dig deeper than you can in standup - because standup is not to resolve technical issues.
Aren't you basically advocating for the dreaded shoulder-tap? As bad as a standup might be, I'd still rather attend something at a scheduled time than have someone randomly hovering at my desk for "quick sync up".
Yes. If they are beginners they shouldn't mind that. You can schedule a regular 1:1 meeting with them, why not, I just think that shoulder tap (or maybe a wink in the hallway) is easier.
I should add: Maybe they will even appreciate it. Maybe they are not sure if they should talk to you because they worry they will rob you of your time.
My point was that what to do really depends on person.
There are 10 of them and some work remote often. It's easier to get everyone in one place than to try and track down 10 people. I'm very busy getting work done myself as I'm not the actual boss of anyone, just a lead.
Because it is helpful for the new members to hear about what everyone else is working on as well.
I started on a new team a couple months ago and if it wasn't for the daily stand-up I would have no idea what was going on outside of the limited scope I've had a chance to work on.
Engineers in general probably know what they're about to do when they're about to begin things. Why not just have them habitually send updates on completed work and intended direction as things change, and intervene/help immediately when appropriate?
I want to agree, but there's no way to apply the scientific method to this case. Experiments would take at least several months to run, because it's not till several months that you know whether your business is going to fail solely due to the dev team. And at that point it's hard to run another experiment.
More importantly, the scientific method relies on an oracle (nature) to tell us whether we're right or wrong. It's not so easy to apply when there's no conclusive way to know you're mistaken.
That said, I completely agree that standups are for managers. Someone once said that standups are to re-affirm that everyone reports to the manager, and pretty much nothing else.
"Experiments would take at least several months to run, because it's not till several months that you know whether your business is going to fail solely due to the dev team."
If you use the rather stodgy and formulaic scientific method, sure. But if you approach this as a multi-arm bandit problem, and instead look at the question as "how much information do I need to collect with how much statistical power before I am justified in selecting an outcome?", it becomes quite tractable for a team to just try it out.
It also helps if instead of using merely "productivity" as your one and only goal that you also consider team happiness as a real and going concern. Then "Nobody likes it and it's demoralizing the engineers" becomes a perfectly valid form of feedback to use in the decision about whether to do it.
I also tend to use the metric that the brain is really, really, really good at figuring out what's important, sometimes perhaps even too good, so if we start a stand-up meeting plan, and it just sort of peters out, then I let it go. (Seems like somebody wants to try it every 2 or 3 years or so, I generally just let it happen and then evaluate.) Everybody's brains are coming to the conclusion that it's not important. Rather than fighting it, roll with it. There are some things in life where your rational forebrain must override the deeper instinctive algorithms about what is important, but that's quite cognitively expensive, and I've never seen any reason to believe that stand-up meetings are bringing enough value to justify that.
I emphasize the "I've never seen any reason". I hypothesize that in many ways, the work the teams I've been on have been doing is almost maximally pathologically bad for a stand-up meeting. Almost everyone is working on something independent of everybody else, so blockers are only rarely even possible. If your team is, on the other hand, chock-a-block full of blocking potential it may be useful to you.
Anyways, there's more ways to find out the truth of things that trying to split the universe into two precisely equal parts, make a change in only one of them, and come back ten years later to see what happened, only for someone to complain that a sample size of one isn't enough and we really need to do this a thousand more times to have a valid result.
So what would the scientific method have you do here? Take, say, 100 projects. On half of them, do standups. On the other half, don't. Measure the outcomes. Do statistics.
The problem is, you'd have to find 100 projects where they care more about the scientific rigor of the experiment than they do about the results of the project. Good luck finding that with real-world projects.
jerf's approach gives you data that is less certain than you would get from a real scientific experiment. But it gives you data that is better than nothing, gathered in the real world. And you can actually run the experiment (at least in some environments) without getting fired, which is more than is likely true with a pure "scientific method" approach.
jerf's approach gives you data that is less certain than you would get from a real scientific experiment. But it gives you data that is better than nothing, gathered in the real world.
The "better than nothing" is precisely where this logic goes awry.
It's usually better to admit what you're actually doing: Going with your gut instincts. Pretending you're doing science adds fake legitimacy to your words and makes it easy to fool people. Unfortunately, the person you have to be concerned about fooling is yourself.
> It's usually better to admit what you're actually doing: Going with your gut instincts.
Not at all. If you're doing standups, try not doing them for the next month. If you're paying attention, you'll know if things got worse or better. Yes, that's anecdote rather than data. Yes, it's not statistically significant. Yes, it may be different outside your specific circumstances. But no, it's not just gut instincts - not if you're any good as a manager.
A gut instinct is an instinctive feeling, as opposed to an opinion based on facts.
If you're paying attention, you'll know if things got worse or better.
Define "worse." In fact, define "better."
These are not qualities that can be measured until the company is either doing better or doing worse. And then you still have to figure out if the company is doing worse solely because of no standup meetings. Hence my original argument.
I'm not saying it's worthless to do that. I'm saying at least admit that it's not evidence-based science.
You can tell (even measure) how much of the time people are waiting for stuff from other people. That's the main thing standups are supposed to fix.
Now, you can still have confounding factors, because the project didn't stand still. You could have everybody waiting on a big deliverable from another team, for instance, in which case everybody's blocked, but the lack of standups has nothing to do with it. So you have to think about the results some, rather than just blindly accepting them. Still, it's better than just gut instinct, because it actually is an opinion based on facts.
I disagree. First of all, I am sure there are scientific ways to analyze things like this, scientists deal with phenomena like this all the time.
But the main problem is - if people don't actually know if the standup meeting helps, they shouldn't recommend it as a part of SCRUM (or other methodology).
I know that in Agile, it's popular to say "if you think it doesn't work, change it". It's a first step towards scientific approach, but also very naive step - it can easily cause you to create rituals with no effects, just based on anecdotal coincidences.
It is kind of disconcerting. On one hand, I applaud the excitement of Agile fans for critical thinking and scientific method, but at least they could study it a little - to find out that there is a little more to it than just "if it doesn't work change it". And that they shouldn't propose things that are not properly justified.
Meetings are velocity roadblocks. They rob energy and momentum.
Stop the meeting and instead of asking what people are missing, watch velocity.
The test of a productive team is spontaneous meetings, whiteboard sessions, and conversations. If people on your team are not getting up and talking, you don't have a team, you have independent contractors.
>"So for who's benefit are standups and "agile" in general?"
I've worked in a couple of shops where the company hired "Agile Coaches" and then assigned teams a dedicated Agile Coach. The Agile Coaches sole responsibility seemed to be to write up the sticky notes and do the physical moving of them to different swim lanes on the board.
It really felt we were having the standups solely for that person's benefit. I couldn't figure out what that person did outside of the 15 minute morning standup.
I could bet that was one of those coaches with 5 Agile Certifications and no proven track record. Good thing is not all Coaches are like this, but the good ones are actually hard to find.
We (the developers) took control over our standups. We went back to basics and talked about _why_ are we doing kanban boards standups, and found two reasons.
1) We do need better awareness of what others around us are doing, especially across the dev/ops divide.
2) Communication, kanban is there to show interested non-devs how projects are progressing.
We update the kanban before the meeting and let one person per day read through the entire board for today/ongoing/blocked. If there are any tasks that person doesn't understand – this is the time to ask.
The process takes often less than 10 mins per day.
Any issues raised will be discussed in loosely formed groups afterwards to not waste everyone's time.
I think what I learned is that you mustn't let process be shoved on you by middle management. Take control to make these things productive for you.
We have a slack channel. You write what you did yesterday, what you are going to do today. If you are blocked, what is blocking you. When you expect to deliver what. Everyone does it. As a reader, you skip the stuff you don't care much for. Pretty interesting though. Maybe ask someone for further clarification. Works great. I like to do it just before I leave for work. The only issue is some skill-less turkey with a title 'coach' can't make a buck, but I am sure he would pipe in and tell us we are doing it all wrong.
In fact we write plan for today on Slack and later modify me message to change what actually gets done.
It is great because:
1. Most of the time you skim the list, but sometimes want to follow up and collaborate. It helps ppl keep on same page and avoid redoing the same stuff.
2. Async, written as first thing when you come to work.
3. Writing todos and sharing them helps ppl to get focused and make them productive.
In one team I was coaching, we also experienced that standups improved when we switched to a kanban board and enumerating tasks on the board: We would not ask people "What did you do today", but pick a task and ask: "Who contributed to that task? Who thinks they can contribute?"
This made a huge difference (although there still were people that did not like the daily stand up - but less than before).
This. As an agile coach it absolutely boils my blood when non-programmers take over these activities with their own agenda. Who is actually doing the work here? The programmers, let them talk about what they need to in order to get their work done best.
> The process takes often less than 10 mins per day.
Yikes. That's worth pointing out and celebrating? The most crucial part of "standups" is in the name - a meeting so short you don't need to sit down.
Here's the thing with 'agile' and stand ups. Do whatever's best for your team. Do whatever helps you be productive as possible. Don't just throw the baby out with the bathwater.
However, in my experience, the IT industry is overflowing with pointless process meetings initiated by middle management.
My point was more to give a concrete example on how some (dev driven) initiative can give productive results which was sort of in line with the OP article.
"When it gets cancelled because a certain person is not there, you are doing the meeting for that person"
This rang true with my current team. It isn't that the meeting doesn't happen but it is extremely fast. No round robin, just a simple 'has anyone got any issues'. Nope, ok carry on. We still get high value from those discussions.
My personal observation is that when this senior person is there, they are using the stand-up as a project management meeting. This should really be 'taken offline' and this person should be working with team leads away from the stand-up.
Luckily I'm working closely with one of the team leads in an isolated area and I excuse myself from the meeting and let him talk on my behalf but I shouldn't be at that point where I'm trying to avoid them.
The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
It's not necessarily a loss of time though.
The mindset "any time spent doing things other than writing code is a waste" rarely produces great products - you need to talk about things. No one knows everything about a project once it gets to a even moderately large size. Working in isolation from the rest of your team means you're not influencing, or being influenced by, the knowledge and discoveries that other people are making as they work. That means you're very likely to be working with an out-of-date model of the problem you're trying to solve.
Clearly a meeting where nothing happens is a waste of time, but the solution to that problem shouldn't be "no more meetings", but "better meetings with real outcomes".
It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.
If the discussion can add more value than those costs, then go for it.
We did stand-ups at my previous employer and for some reason they happened early in the morning. That's my most productive time. I always thought we should move them to after lunch or maybe later in the day. In that office, productivity and energy definitely dropped as the day wore on and it seemed foolish to spend some of the best time in discussions.
I had the opposite problem, but it was a morning problem also. First thing in the morning, I am very foggy, and remember very little from yesterday. It is not until I've worked for an hour or two that everything comes back. Paged in from disk, so to speak.
So I often had to make things up on the spot to sound busy when I had no idea what happened yesterday at the crack of dawn. What a waste of energy.
>It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.
Sorry - same thing. When GP is talking about "loss of time", he's not referring to "Oh, I lost X minutes of my life I'll never get back!" He's talking about lost productivity, just as you are.
And if a simple 5-15 minute meeting once a day saps your productivity so much, then what the GP is saying does apply to you: That you feel your job is just to sit on the computer and do software development.
And if you can't organize your work around that 5-15 minute meeting, you have other problems. You never take breaks during the day? This is just another "break", except it has a prescribed time. Plan around it! This isn't a "surprise interrupt" that occurs while you are working. It's not an interrupt, any more than your sleep is, or eating lunch is. It's a predefined part of your job.
Sorry, I'm not even saying standups are good. I'm not an advocate for them. But this attitude is silly.
If you are not getting value from the standup, improve the standup! Don't complain about context switching.
Context switching isn't free, so you shouldn't pretend like it is. You mention lunch, but that's a facile comparison: humans need calories, and if a person is in a flow they can take lunch solo and continue the thought process.
We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
>and if a person is in a flow they can take lunch solo and continue the thought process.
And my question is: If you know there is a scheduled meeting at a given time, why are you trying to get in flow around that time? Sorry, that's just poor planning.
>We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
No one's disagreeing with you there. No one is saying you should randomly take up lots and lots of meetings.
But I'd be worried if a developer - whether a colleague or one under me - said that a 15 minute meeting at a predefined time once a day is significantly impacting his productivity. That's usually a sign of him trying to solve the wrong problem - or a sign that he is not thinking the problem through.
I wish I could find the quote, but there's a famous quote from a SW manager saying that it's often cheaper for him to pay people not to code than it is to let them code a lot. Someone who is coding all the time (unless it is boilerplate work) is creating a lot of technical debt. Unless it is a cutthroat market, he should not be doing that.
If I were a manager, I would rather my SW developers:
1. Spend more time talking to the customer and refining their requirements (yes, I advocate more meetings than most people like) (part of solving the "right" problem).
2. Spend more time improving the infrastructure (automated builds, whatever).
3. Spend more time writing documentation.
I could keep adding to the list. If they are spending the majority of their time in "flow" mode, they are doing too little of the above, and in the long run, creating headaches for many people.
Frankly, writing code is a last resort. Almost all our code is to solve a problem, and a lot of code is an attempt to solve a social problem using technology. If my developer can solve the original problem without writing code, he deserves a bonus - not the guy who came up with a fantastic algorithm to solve it.
I'll grant there are niche roles where it is really beneficial to be in flow mode most of the day. But over 90% of the folks who want to be in that mode are not occupying one of those niche roles.
If you see flow as being time when someone is hammering away on a keyboard you completely misunderstand the concept. Flow is how developers avoid writing code.
That can be mitigated somewhat by having the stand up meeting first thing before people have started other tasks, but really that rarely works if people are interested in their work enough to get to the office early. You just have to take the hit, and readily accept that people will skip the meeting if they're deep in to something else.
The other time to hold it is just before lunchtime. This has the dual benefit of encouraging people to be brief (hunger is a powerful motivator ;-) and breaking at a time when people would have to break anyways. I also like holding it midday rather than the very start or end of the day because those times encourage staying late or coming in early to resolve an issue before standup. Lunchtime is also usually a time when everyone (apart from remote team members) is in the office no matter what schedule they keep.
Unless those eight people work on very closely related problems, there is little value in having all of them in the same room talking for half an hour. Communication doesn't have to happen with the whole team if different parts of the team work on different parts of the software.
What do you mean by "details"? The level of detail is highly context dependent. I'd argue that if there isn't a level of detail that all members of the team agree they should be interested in, then either the team is not composed properly or there is a misconception about the level of detail that is appropriate.
> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
But the whole point of a stand-up meeting is to keep it short. If you're talking for more than 5 minutes, the scrum leader or whatever you're calling them needs to reign it in. If you hit 10 minutes you're doing it wrong.
What I started doing after a couple of years of managing teams was to ask for average salaries per work function for my team, which has consistently surprised people when I ask (that this is surprising surprised and shocked me), and then send a weekly report to my boss - whether they wanted it or not - enumerating costs broken down by task.
Several times I've had managers that were confused why I'd send them this, or even insist it was a waste of time at first. Never once have I had a boss ask for this kind of breakdown themselves.
Then they'd see the result, and inevitably I'd get questions about how it could be right that e.g. (to take a number out of thin air) $5k worth of developer time every week was spent on meetings.
Or why that "tiny little change" that someone insisted on adding without proper scoping because it was so minor ended up costing $20k.
Pretty quickly those reports they initially didn't care about became mandatory, and it to some degree changed how people thought about resource allocation.
It doesn't need to be precise tracking either - you need to get the costs to about the right magnitude, and treat them accordingly depending on how you collect the data.
I agree with 'bad_user' here, to some extent. That is enough to give a manager a pause, but not to immediately dismiss it as a bad idea.
Most professionals will agree that it's unrealistic to believe that developer-typing-code-time has 100% efficiency. The time spent 'decompressing', which can sometimes manifest itself as spending time reading/doing unrelated stuff, does sometimes produce a solution faster than just banging away coding.
Management work is different from coding in that everything is hard and noisy to measure, so to some extent heuristics are relied upon, simply because it's the state of the art in this area.
So, even if half an hour meeting with 8 developers takes 4 developer-hours (which is a rather large number), it does not mean those hours are wasted. If one of those meetings a day stops someone spending one week chasing a dead-end known to others at least once in a while, on average the team moves faster, not slower.
BTW, I actually agree that 8 developers is too much, and that half an hour is too long for a daily. Just going off a tangent here.
The point is not that it is actually bad. Even 8 developers for half an hour could be justified.
The point is that it should give a manager sufficient pause to actually think through whether or not that cost is justified by what that meeting provides.
Surprisingly few teams account for the cost of the way they spend their time, and one outcome is that it's very easy for time sinks like meetings to go unchallenged because people don't think about how the costs multiply with the number of people involved. It's "only 30 minutes".
Costs which would require budget approval if it was scheduled as a project suddenly become ok because no single person spends much time on it per meeting and the time spent never gets recorded and reported on anywhere.
> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
What i see here is a team that let it happen.
A 'scum master' (or whoever) that oversaw the conversation and carried on with it. Developers (or team members) who talked for that long, and other people who _let_ it go on for that long and didn't put their foot down.
Man, where I work if a standup started going for half that time, people would just start walking away from it.
When the person who calls the meeting is sufficiently senior, walking away isn't always an option, unless you're prepared to also walk away from the job.
I'm seeing a lot of comments about how terrible different people's standup meetings are at their particular companies, and I can't help but think the problem isn't with standup itself, it's with these companies.
At my job, we meet for standup via video chat as early as we can. That's about 9am for some of us and 10am or 11am for others depending on timezones. We each say what we worked on yesterday and what we're working on now, which only takes about 5 to 10 minutes, then we enter what we call "parking lot." We call it "parking lot" because if this were an in-person meeting, this is bit where we would be talking in the parking lot on our way out to lunch. No one is expected to stick around unless there's something urgent related to what your working on that needs to be discussed. Anyone is free to hop off the call at this point.
During parking lot, we discuss impediments, anything that's going to keep someone from getting work done that day. If the problem is something complicated that's difficult to describe via text, we chat about it face to face and work out a solution together. If the problem is simple, we just agree to talk it out in either a public or private channel on Slack depending the kind of problem.
The purpose of the meeting isn't to build a big report of who's working on what or to guilt us into working harder. It's just to guarantee that we're all online at a given time each day to help each other out. Working across several timezones, we all have wildly different hours, and without standup, we would probably be waiting for days to hear back from each other about any issues we run into.
Maybe standup is a problem for other people or other companies, but for my team at least, we couldn't work without it.
Couldn't agree more with what you are saying here. Daily stand ups, if done right are very helpful especially for remote teams. I did daily stand ups at my previous company and they took on average an hour and were unfocused, meandering and generally pointless. I dreaded them and the whole team felt the same. By contrast, my current team is much larger but keeps the daily stand up to 15 minutes. It's focused and everyone is on page about tabling longer discussions for post stand up with the relevant stakeholders. While I won't ever say I'm looking forward to it, I see the tangible benefits. We are a remote team across multiple time zones and are able to effectively work together with ease. The daily stand up is a big part of that.
> I can't help but think the problem isn't with standup itself, it's with these companies.
I agree too.
Daily standup meetings help me to focus on my goals for the day. Communicating the same status in consecutive meetings makes me realize that I need to put more effort into progressing with a task so that I can report something new for the next standup. Standup meetings that go for more than 5 minutes per person are not ideal and the organizer needs to buckle up
The effort to say something about yesterday and about today is an obsolete overhead. Sometimes one is just stuck for couple of days with bloated and partially obsolete Java setup, sometimes one has done nothing and needs a break instead of daily confessions. Saying these might be perceived arrogant or disrespectful. I perceive standups as an immature way to discipline developers.
I really don't see why it has to be that way, and if people feel like that, there's something weird going on.
If you've been given a large feature that involves, say, analytics, there is surely nothing wrong with your standup contribution being:
"Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."
It tells people what you're doing and that it's broadly going ok. If you're five days into something that was supposed to take three days and you're actively embarrassed about this, then that's a problem - but it's a problem that should be discussed at the end of the third day with the stakeholders, not in the standup.
[edit] Reporting on a high level ("yesterday - analytics, today - analytics") is fine only up to a point. This statement only works when team members are 1) mature (to admit problems) and 2) very self-aware (to accurately assess if they are making progress).
Unfortunately, huge percentage of people in software houses I've seen are young and therefore both immature and not very self-aware. They have a hard time recognizing the upcoming issues, and will not admit they made a mistake or are unsure if they can succeed on time.
The results? People claim they are on track, then they fail, goals aren't achieved. This happens over and over.
Eventually Project Manager or senior developers start probing more and more, dividing the work more, creating smaller (shorter) tasks to cater for less independent employees, adding short iterations, daily checkups and ...
This is why I regularly advise new hires, both senior and right out of college, that communicating when you're blocked or stuck is not optional. The quickest way to get me to recommend a performance improvement plan isn't if you can't hack it on a particular task, it's if you aren't clear that you don't have what you need (voodoo to get tools working, training, experience) to get the job done. Being stuck and not speaking up is a cardinal sin in knowledge work.
"This task needs to be broken up into manageable pieces badly."
This seems to be a sentiment I see a lot, but I don't think it applies equally to all people.
Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work).
When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress.
However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed.
Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.
> When you break things down, you make it easier for less experienced workers to complete work.
Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand.
> However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance.
I do agree though that the right level to break down tasks is an art that ends up being team specific.
It's also so you can get the jump on risks as early as possible. Consider two projects, both roughly a week long. Project A is broken down into day-long tasks, and project B isn't. On day two, the guy doing project A reports he wasn't able to get milestone 1 completely done yesterday. Others can now step in and help if needed, after only a day. The guy doing project B, who reports "analytics yesterday, analytics today" needs to subjectively assess whether or not he's behind, and depending on how experienced he is at this, nobody will know until the sprint is blown that he was unrecoverably behind.
Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.
The goal in small tasks, to me, is to encourage collaboration more than to micromanage. Sometimes you can get three free devs working on one story and turn it around in a day or two, but if it was all one "get the feature done" task, there are no opportunities there.
Fine grained efforts to "encourage collaboration" in places where it's not clearly needed is micromanagement. In fact, from an introvert's point of view, it could be the very worst form of micromanagement.
Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.
I am ok having to talk with people for three hours or more a day. I am ok having to coordinate and having to respect other people's needs.
I am not ok with being micromanaged on hourly basis. I am not ok when I loose all autonomy and have no responsibility. The whole 10 minutes of talk you put in is nonsense - you won't be able to split large tasks into microtasks in those 10 minuteš a day.
Last point - waterfall vs agile is false dichotomy. So is the strawman of evil badgering management who stands against pack of developers who have all awesome social skills and are natural born benevolent leaders.
> The problem is you feel like you need to justify working on one thing for two days:
The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD.
The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.
It may be foreign to the "Agile Industry" but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.
Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.
> but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.
Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.
Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.
This task needs to be broken up into manageable pieces badly.
This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later".
It's hard to track progress and estimate if your tickets are huge multi-week affairs.
> It's hard to track progress and estimate if your tickets are huge multi-week affairs.
So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine.
The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.
No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people.
Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.
The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.
While I don't mind daily meeting as such, if communication between ream members works at least half well, you should not need special occasion to raise the issues. You raise them wherever you see other team members are not focused on something.
As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.
So what you are saying is that the standup really _is_ for project tracking
Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful.
The point of the meeting is often…
I maintain that is this happens, you are in a bad environment.
> Only in the sense that the team needs to know itself how work is progressing
That's what retrospectives, demos, and stories are for.
If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
You don't need whole team to see that. You need to go to that one developer and ask him why tasks are not finished. I case he has solvable problem, you get the chance to fix that solvable problem. In case he does not, you need to watch him more and maybe eventually fire him.
The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.
Right. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."
I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with.
Here’s one example:
* Moving functionality from a legacy^2 to legacy (mainframe to client-server)
* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.
* Source and target systems inherently un- unit testable
* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some
* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories
* Culture of fear reinforced by performance reviews, stack ranking and PIPs
* Locked down QA systems and silo’d resources
Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.
A thousand man-years of effort? Sounds like a very large project.
Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.
Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
Is it really important to track progress on a day to day basis?
It depends on the team.
We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed.
Tracking progress goes on a Kanban board (or digital equivalent).
> The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless.
Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team.
Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
> "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."
"You're not transparent enough. It feels you are blocked and you're not communicating. The task is too big, we will divide them more next sprint"
Basically this. If you're working on a large decoupled task, no-one else (other than team lead) has to know or care what you're doing other than that you're not waiting on anyone else. The moment your work has to interact with someone else's work, then you need to know what each other are doing.
As in a high-bus-number way? Not necessarily. We're talking about a few days here, not someone going off in a silo for months on end. If your standards for documentation, testing, etc. are reasonable then the results of their work should be maintainable by any team member after they're done.
Saying these might be perceived arrogant or disrespectful. I perceive standups as an immature way to discipline developers.
If this is what's happening in a team, then there is something more broken than unnecessary stand-ups.
It should be perfectly acceptable to talk openly an honestly about the things that you have or have not been able to do. If you're in a situation where you have to 'hide' the work you have been doing, then your team atmosphere is poisonous and avoiding stand-ups is not going to fix that.
If you're in a situation where you have to 'hide' the work you have been doing, then your team atmosphere is poisonous and avoiding stand-ups is not going to fix that.
Unfortunate office reality is that it's sometimes beneficial to withdraw by "hiding" your work or by not contributing openly to a discussion. The benefit is in avoiding (negative) spotlight, avoiding additional work or pressure, or similar consequences. This can happen even in an otherwise happy and supportive environment. If you're not pushed too hard by anyone, you can become complacent and settle on doing less. You can argue this is poisonous, but I'm not sure many people would call those "low ambition" or "low stress" or "hands off management" environments poisonous.
> Sometimes one is just stuck for couple of days with bloated and partially obsolete Java setup
That's the whole point of the standup. If I was stuck with something like some "Java setup", whatever that is, I'd let others know. Maybe someone will pipe up and say, "Oh yeah, I've seen that before, just do x", or "Let's get together after the standup and try to figure it out together."
Sometimes that's the right answer, sometimes it's better to just hit your head against it for a while.
(This can be an individual thing, I'm definitely a learn-by-doing type and need to be "spinning my wheels" sometimes. Others benefit from talking things through).
It would be nice to be trusted to make this call rather than having a ritual to force the talk-things-through option every time.
Yes. Exactly. 99% of the standup is allowing people to help each other and dynamically set their agenda for the day. If it's a status report or just a bunch of people trying to make up cool-sounding stuff they did? You're doing it wrong.
Team-oriented software development has become somewhat infantilized, and it's a worrying trend that keeps showing up in our society, in general.
We need to stop approaching team development with the expectation that one or more team members will need checking up on because they're goofing off too much or not working on what they're supposed to be working on. Professional software development is a career, and we should be able to start all employer <-> employee relationships with the expectation that a) we're all adults, and will treat each other accordingly, and b) we're all, ultimately, responsible for our own work and the work of the team. If someone repeatedly demonstrates that they can't execute in this fashion, then they're gone. There's simply too much to do, and dragging the entire team down to the level of the least-responsible member is ridiculous. You're better off just distributing the extra work among existing team members.
For example: want the team to bond and communicate ? Ditch the daily meetings, and every Friday take the team out for a meandering late work lunch where everyone talks about the week, what they're working on, the overall project, etc. Any other time, everyone knows where the other team members are working - if there's something that you need, you ask in the least-intrusive way possible, depending upon how busy the other team member is and the importance of your task.
I disagree with the basic premise of this: "When it gets cancelled because a certain person is not there, you are doing the meeting for that person".
One person being the driving force behind making something happen doesn't imply that all the benefit accrues to them at all.
"Just make sure everyone is actually recording what they are missing!"
Except they have no way of recording the opportunity cost - they don't know what they haven't been told; they could be missing something huge, but without a venue for communication they don't find out.
I have to say, I don't think this is great advice.
"Except they have no way of recording the opportunity cost"
This is a very good point. I have to think about it more.
Still, as an independent consultant, I have seen some teams who get close to 0 value from their dailies (while others got tremendous value). And just trying to change some small things about the dailies will probably lead to no results.
"One person being the driving force behind making something happen doesn't imply that all the benefit accrues to them at all."
Well, if nobody goes to the daily just because a single person is missing, you have a problem. Right? Even if that problem is only that the others do not recognize the value they are getting...
This isn't great advice because this isn't advice. It isn't advice because there's nothing actionable here. The only thing I'll say you can do if you're in a team like this is try to find your way out. Your "team" is already doomed and beyond saving.
I do some contracting from time to time with a devshop that has gone "full agile" - I love these people, and have a lot of respect for the work they do, but OH. MY. GOD. save me from the fucking standups. What a totally useless waste of everybodies' time. I refuse to attend most of them in any case, which harms my standing with the project managers, but I seriously don't care - most standups as well as the majority of other project management activities they practice appear to be designed to keep the project managers happy, and contribute little to the overall quality or speed of delivery of the project at hand, and are a massive distraction to everyone involved. Daily $project_management_ritual should die.
Daily standup is a scam just like the "open office".
Most of the time it turns into a beating stick for incompetent managers to feel good.
They are both defended by people for various superficial theoretical reasons that never come to fruition.
Like they try to defend open office because "it's good for collaboration" but in reality it's only to cut down office costs and to let employees watch each other.
If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".
This is a pattern that you can notice easily in business. Anything undesirable that is not good for you will be applied a lip-stick of colorful language in order to "sell" it to you and it goes right into the echo chamber.
You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".
Were this testable, I'd absolutely take the other side of this bet. (Some) managers get too much satisfaction out of seeing their "doers" lined up and visibly working. And/or believe that watching one another makes people work harder. Open offices would happen, even at a premium.
Edit: actually, it kind-of is testable. If office costs were the biggest factor in how workers were deployed, we'd see far more remote work.
You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
Please tell me when you open one of these, I might be after a job!
I've been at my current job for 5 years and spent my previous 15 at 7 different jobs combined. It's not an accident that I've stayed at this one but left all of the others. This is the one where people are allowed to be responsible for their own productivity without overhead like standups, project managers, status reports, task tracking software, etc. It couldn't work for all people or all companies, but it means enough to me to manage my career around finding the environments like this one that make me enjoy coming to work so much more.
In the aspect of scrum the daily is good defined, I don't think you need to experiment about what needs to be talked about.
It is a one time a day meeting where everyone gives a glimpse over what he has done and how this may affect others and what he is going to achieve until the next meeting. Committing to a goal motivates me to get things done. A third aspect is to give the scrum master feedback about impediments which do prevent me from achieving my goals.
And yes this does not mean that nobody is talking to each other through the day. But even if you are a team it is important to get everyone up to date. Most discussion through the day happen between 2 or 3 persons, and not with everyone (4-6 people).
I agree with author... instead of doing "Scrum", how about we act like adults, and speak with people when we need to, in respect to their time, schedule accordingly, and not clown and parade around with scrum and poker cards.
There are a whole bunch of legitimate reasons that aspects of Scrum are useful to some teams. Like the planning poker thing –I work with a team of talented, experienced and professional developers, and we still have misconceptions about complexity that are revealed by the planning poker approach.
The idea that 'if everyone just programmed it would be fine' is totally asinine.
that's not how I meant it. Sure, plan it, however it suits you and the team. If planning poker works for you, great. But do you need to coat it under "Scrum", having special moderators such as Scrummaster and consultations every year how you are not doing scrum "enough". I don't advocate programming anarchy, but I don't like when managers treat programmers like some woodchoppers that they need to wrap fine grained process around, instead of having the team work the way it fits them best.
I completely agree that 'agile' without being agile is just buzzword bingo, and I've been through it myself. Ultimately, plan however works for your team. But I do get the impression generally that there can be a lot of unjustified resistance to any kind of organisation among certain groups of developers; it pays to be open-minded about techniques that can work.
I think the resistance is not unjustified - mostly programmers are fed up with "these" things, since they always get misused against them (i.e. - estimations - you and me know how it works, that it's well, estimation - but in back there is manager who translates it in his excel to $$$ and time, and the second your 8point story is now day overdue you are being pushed to zones which only further damage the project down the road (costs which you will have to pay by overtimes, not the guy behind his excel). Does that mean estimation is bad? No. It's non-programmers who misuse it. Would team be better without estimation? Probably, since it wouldn't be misused by external elements, and we could just do our damn job).
Perhaps the original agile was meant correctly, but as of today most organisations just use it to justify and coat (perhaps) same things agile was to be against.
For me today Agile has so way too many faces. If it doesn't work, answer is always "you're not doing agile/scrum correctly). There are always reasons how you're not being agile enough, no matter how many times you fine-tune your "agile" on retrospectives, if there are managers and people misusing it against you, you could as well be better without it.
What an incomprehensive piece of text I wrote. Sorry. I'm not native English speaker.
If you're lucky non of this applies though, but you have to be lucky enough to work with lots of (prehaps we might say all) smart people across whole "chain of command".
Any links to those studies? Although don't think we're interested in scrum vs waterfall. We all agree that iterative development is better than waterfall.
Yes, but if everyone speaks to you whenever they need to, you might be interrupted in your work very frequently which can be stressful. If only people could communicate all of these issues say once a day or so...
Yes. And at that point, you will suggest, like an adult, to speak when it fits both time. I wonder how people who don't use Scrum solve this problem!
Here's little experiment. 10mins after standup is over, ask some people what did they learn in standup. I mean specifics. Noone will know or care or remember. Sure, people get broad picture, which they could just as well by looking onto jira or whatever.
I've worked at one of these "no software process" utopias, where programmers just sat in their own world programming away and guess what? Software barely got released, it was always late, low quality, and nobody from management to individual contributors had any big picture visibility whatsoever. It was a total circus. They didn't even use source control or have a bug tracker. Absolutely 0/12 on the Joel test. I was brought in to provide some adult supervision and you better believe I layered on the process.
We made a little progress, but unfortunately, you can add process but changing culture is much harder. At the end of the day I got quality and release cadence under control, got a roadmap and a spec together, got basic "table stakes" software infra and tools up, but boy were those first few months a nightmare. I can't imagine any business getting anything done with just "programmers programming".
I mean this in the nicest possible way. Your experience counts for nothing. It's a one-off. Literally.
> I was brought in to provide some adult supervision
> I can't imagine any business getting anything done with just "programmers programming".
Your attitude and your arrogance will definitely limit your ability to lead engineering teams. Talented developers are not going to work with someone like you as long as they have a choice. I do recommend taking a coding bootcamp type course and delivering a project to gain a better understanding of how software projects work.
This is nice in theory, but I am afraid it fails quickly in practice.
I am a leftist, but I don't believe self-organizing works in situations where there is some higher level of control. People don't have incentive to self-organize in small scale, if there is some other big beneficiary outside their control. This is very abstract, so let me give two examples of what I mean.
1. In communist countries, sometimes, self-organization was tried on the level of individual state-owned companies (basically they were supposed to run as worker-owned cooperatives). It mostly failed horribly. But all of these countries were dictatorships with top-level, directive planning of the economy. So these "cooperatives" were still subject to larger plans, and that broke the incentive (or will) to self-organize.
2. Similarly, even though many companies try to have people self-organize, it falls flat because of the basic capitalistic premise - that there is an owner (or multiple owners) to the whole enterprise. This owner takes in a large amount of economic profit, which, if the team was truly self-organizing, would stay within the team. This breaks the incentive to self-organize. Why make something more efficient (even as a group) if some other people are going to decide how much you benefit?
So I think, taken my and your conclusions together, bad stand-ups are inevitable, except maybe in worker cooperatives (which are actually very efficient in capitalist economy, that is, if they operate entirely for the benefits of their own members).
I disagree with the premise that self-organization can only work when people are motivated by money. I believe that money is only a component of motivation, and sometimes a negative one. Intrinsic motivations like mastery and a job well done are much more effective in my opinion.
You should check out the book "Reinventing Organizations" which is a case study of 12 successful self-organizing companies and how they do it.
Also I'd like to hear your feedback to my post that shows how my team has accomplished it for over a decade and counting.
It's not really that much about money, as it is about that you cannot built a non-hierarchy at the bottom of hierarchy. The non-hierarchy must come from the top. Maybe there are some outliers for which it works out, because the top level management buys into it, but I don't see it happening in most normal organizations.
Self organization means that multiple wanna be dominant devs will attempt to make themselves leads - leading to ugly politics and constant attempts to micromanage other team members.
Single clear and accountable leader is much better way.
Alternatively, you can have democracy (either direct or representative). That solves precisely this problem. No matter what politics is played, in democracy, you always have the same vote. So fighting for power becomes meaningless (actually, not quite so, but it becomes possible for you not to get hurt even if you don't do it as a full time job).
There indeed are self-managed enterprises which use democratic principles (worker cooperatives), and they work quite well. However, I understand that people who try to sell "self-management" to companies avoid mentioning democracy, because, as I said, there is an elephant in the room and that is that the capitalist organizations (capital-owned) are fundamentally not democratic from the workers perspective.
You've shown one way self-organizing teams can fail. That is not true for all teams.
I can similarly show a way a clear, accountable leader can fail: they can be good enough at politics to make a huge, micromanaged mess yet have all the blame placed on their team and get promoted. Just because sometimes it does happen, it doesn't mean it always happens ;)
Self organization witout accountability works when all of you are perfect and there is no pressure or blame game going on. It works only rarely. There are bad and good managers obviously, but most bad managers basically force team to self organize.
In any case, it takes only one team member to be aggressive micromanager in order to blow self organization in hell.
We have switched to asynchronous, slack-based standups a long time ago, moderated by a bot (we're using a modified version of https://github.com/eelzon/morgenbot). This way everyone knows what everyone else has been up to, will be up to and what blockers are, without being caught up in endless discussions, and since it's asynchronous, people can supply their standup (within limits) at their own leisure. Works well for us.
Apologies if the repo makes this obvious. I'm on my phone. Do you maintain a virtual scrum board? What software do you use and how do you like it? I am on small scrum team and we all would like to go virtual for many reasons. Mostly we are from different parts of campus and the travel time eats productivity. And many of us have families that get in the way of the morning standup. A virtual one can be done from anywhere. Thanks for any help.
As a coach here's my question about the standard standup format (what did you do yesterday, etc...)
If the reason we are all here is to get the work done why is it ok that it's a mystery what is done or not? Why is it not obvious? Why do we have to ask? Why not just keep your board or whatever up to date and talk about other things? Like surprises, blockers, questions, or concerns.
> Why not just keep your board or whatever up to date and talk about other things? Like surprises, blockers, questions, or concerns.
I could be wrong, but I think that might have been the original intent.
Enumerating everything work related you did yesterday is a waste of time. "I worked on X, Y, and Z. Y and Z are closed. I still need to finish up X," tells nothing that the board doesn't tell. If Y and Z are closed, Y and Z's status reflect that on the board.
"X is still unfinished. An external dependency from ${team} is failing, so I'm coordinating with ${point-of-contact} to resolve the issue." That is a worthwhile update that takes the same amount of time yet contains infinitely more information.
Maybe we need a new format. Everyone who speaks could start with, "Everything I did was routine except..." We know that you went to a meeting with another upstream team, because you have that same meeting at the same time every Tuesday. Therefore, we don't need you to say, "Yesterday I went to a meeting with ${team}." Give us the meeting details that's relevant to our team. You then drop the preamble after a few days or so.
I haven't done standup in 6 months and I just feel generally better. Where I work you just report to the tech lead every 2 or 3 weeks. So much nicer than daily standups. Could you imagine other professions doing what we do?
>Could you imagine other professions doing what we do?
I worked in advertising before a tech startup and the whole rigmarole of standup, agile, scrum whatever felt like being back at school to me. Couldn't really understand why as professionals people couldn't be trusted to just get on with their work and know whats going on.
Had a chat with a colleague and mentioned this is the first place I've worked where you had to do this stuff and they couldn't believe it wasn't what was done in literally every workplace (this was their first job out of uni, but they were 3 years into it).
Where I work you just report to the tech lead every 2 or 3 weeks. So much nicer than daily standups.
This might work for some organisations, products or development styles. In my team of five, over a two or three week period we might have delivered half a dozen customer-facing features or changes, and the team will generally be working quite collaboratively on those. It would not be feasible to 'report to a tech lead every 2 or 3 weeks'.
Could you imagine other professions doing what we do?
Yes, and I think in some cases they would gain a lot from it.
Are your developers children who won't work together unless they are micromanaged by a lead?
Obviously not, and as I pointed out earlier it's clear that different organisational styles can work well for different teams and that's fine – please don't lower the tone of the conversation like that. My development team are experienced professionals, and because we are organised in a different manner does not mean that we are 'children'.
I'll give you some background which will maybe clarify our particular structure (that's not to say that there are no alternatives). My current project team is five people – three developers including me, a product owner/manager, and the 'head of development' who works across multiple project teams and serves in the organisational/administrative/scrum-master role. There is no 'lead' to report to, and while our 'head of development' is nominally the line manager of the development team, she is not responsible for product delivery and is there to provide general support and problem-solving rather than take progress reports.
We have a daily stand-up which lasts around 5 minutes (the other two developers are exclusively remote); 'sprints' last two weeks; each sprint starts with an hour-long planning session in which we as a group figure out the priorities with input from the product owner, figure out what technical work is required, and break it into deliverable and testable features. Then we go away and work for two weeks, demo what we did to the wider company, and spend an hour together doing the whole retrospective thing where we review what went well/bad/needs more work.
Everything is collaborative; I don't have to 'spend 1-2 full days together so we can "go deep"' with anybody, because all interested parties are consistently involved in the process. It works well, doesn't involve micromanagement, and everybody is happy. Obviously this is not the only way to run a team, but it's also not invalid or childish.
I'm sure you can understand that I'm kind of tired of bad teams with bad process blaming it on 'Agile' when their real problem is that they have poisonous developers or other underlying issues.
> Are your developers children who won't work together unless they are micromanaged by a lead?
This is black and white thinking. It depends on the personality type, but many developers have a tendency to go down research rabbit-holes or to think only about the tech and not about the business.
Therefore, a more frequent calibration to business goals may be necessary.
Well, I saw sales and HR do stand ups and retros mustered by the agile officers. It was imperative that scrum must fit all. Scrums of scrums everywhere. The agile singularity was reached.
Please yes! Especially the more dogmatic ones (e.g. only stating what you did yesterday, what you're going to do today, what's blocking you). It's just an empty status reporting ritual that feeds some negative emotional need of a manager (either anxiousness or a need to feel directly in control).
Personally, I think a freeform dev team meeting that happens 2 or 3 times a week is much more valuable. For instance: if there's a big issue going on, lets actually talk about it rather than merely stating we're working on it (and taking "offline" the only information others might actually be curious about).
I've worked both in a standard office setting and remotely. When I was in-office, I found the daily stand-ups tedious, because everyone was telling me stuff I was already aware of. But now when I am remote I find the stand-ups much more useful, because they are telling me stuff I don't already know. It's like stand-ups are overkill when the team is already working together in close quarters.
Stand ups at an agency I am currently working for on a short term engagement just has people in the tech team listing what clients they're going to be working for today. You know, because that's very helpful for everyone to know....
I think the spirit of agile development is lost on most places and blindly sticking to process without questioning it becomes the norm.
If you're working in an interdisciplinary team you need to know what the other groups in your team are working on. Maybe if you're doing deep research or something, you can hide in your cave and focus purely on your own work, but if you're doing implementation rather than research, you have to understand all of what's going on.
But if you need to know what the others are working on, isn't it simpler to ask them at any time when the curiosity arises? Do you need to stand up and listen to what everybody is working on, every day, in order to do what you should do naturally, that is, be in touch with the members of your team?
I'm a junior developer in a "Scaled Agile Framework" (SAFe, apparently) team at a VERY big company, and although we never cancel our stand ups, the format seems to exclusively be for status updates / reporting, and not "for the team". Feels like everyone else is habituated to it though, and they don't seem to mind, but it definitely bothers me. Generally lucky if a morning stand up takes 30 minutes, let alone 15.
I found the best way to make a standup successful was to put a hard limit on how long people could talk. When my teams were working the best they had a limit of 15 seconds ( I would count down while they talked ). The stand up is situational awareness not status of ongoing projects. Once the 15 second round of updates were done, if there was someone I needed more information from I would grab them after the standup to talk to them.
I don't really understand how a team can have a 30 minute standup, to me that is a manager who is lazy or disconnected who doesn't bother to follow the teams progress on the myriad of tools they inevitably have ( Whiteboards, Jira, Github, ..... )
I would refuse to go to any meeting where I was asked to talk and then had someone counting down from 15 the second I started. I understand why you're doing it, but it comes off as rude and demeaning to me.
My stand ups are time boxes at 15 minutes total, and the person running the meeting cuts it off at 15 minutes even if people haven't had a chance to talk. If you have something to say you don't have to cram it in 15 seconds, but often people just pass. It only takes a few meetings going over 15 minutes for habits to adjust.
>I would refuse to go to any meeting where I was asked to talk and then had someone counting down from 15 the second I started. I understand why you're doing it, but it comes off as rude and demeaning to me
Like a parent counting down before you're put in time out.
the countdown is necessary because its rude and demeaning for someone to take up everyone time by talking longer then they should. In a perfect world we all agree to the rules and follow them, but like you said even at 15 minutes someone has to cut everyone else off. Its the same principle applied at a different level. You time box the whole meeting and someone is rude and disbands it before everyone has talked, or you time box each person and everyone gets a chance to talk. In an environment where you have a mix of strong personalities and more introspective people the folks who are more soft spoken will be drown out if you don't specifically allot them time to talk. At least that has been my experience
It's the counting down part I consider to be rude and demeaning. In addition to that I feel like it encourages people to cram as much as they can into as little time as possible, which kind of defeats the purpose. The goal of time boxing in my opinion is to be a signal that you're doing something wrong. Realistically, you shouldn't ever hit the limit.
The cutting off of individuals vs teams is something we could debate, and I'm not sure either of us would be right or wrong on. I see your point of strong vs soft spoken personalities, it's not something my team personally deals with so thats probably part of the reason more free form meetings work for us.
I'm in a small team. I am the lone coder and I report directly to the CEO. I asked to do a standup because it's imperative for me to gain focus on tasks and frame my work. We used to have weekly status meetings but that was too infrequent. Instead of a weekly half-hour we now do 2-5 minutes of me standing in his doorway running through the "Yesterday I worked on [tasklist]. I am [not] stuck. I [don't] have resources for my tasks. Today I commit to work on [tasklist]."
Ugh. Provocative, radical idea that is founded upon overly-simple, faulty assumptions. To think that the author's three categories for teams are the only three, and that standup communication only takes the forms he describes is just hubris, and leads to dangerous advice.
The author identified three potential pitfalls of stand ups and suggested not doing them if you fit into those three categories. Title comes off as a blanket statement, but I didn't get that feeling from the rest of the article.
Appreciate the OP is about whether the stand up is for the scrum master/project manager etc or for the team members. Hopefully it is both, and mostly the later.
Also see in the other threads (and discussion in general) that mistakes the standups as for reporting your status to managers. That may be required in some organisations or partially, but not in most.
But I would view a good stand up one that does NOT require each team member to in turn state the old: "what they did yesterday, what will do toady, any impediments".
Instead you hope project leadership trust their team members and instead focus on the tasks. In order of task priority a participant in that story can quicklyy broadcast if anything has changed with a task/story, no need for details of what happened yesterday, no need for whom did what etc. Then if any impediments for that story, escalations, anything else etc. And just quickly rattle through them to make sure focus is maintained on getting the tasks flowing through to delivered.
In my old job we used Geekbot [0], a Slack bot for async standup meetings. It's great for geographically distributed teams.
I found it made it much easier to get an idea of what people were up to, as well as providing an opening for occasional tips and suggestions. Posts typically included a mix of what you achieved, what you hope to achieve, and any blockers. Any updates or big breakthroughs were usually shared as well.
I think it's best to be flexible about how frequently status updates are shared, leaving it up to the developer's discretion.
The point of a standup is to coordinate team communication in batches and not interrupt people at random times. We always finish it up in less than 15 minutes and then small groups meet afterwards about talking points.
Whenever you decide to have a standup is a random time for some people.
For some, it will be too early, prematurely terminating their sleep cycle and rushing them in, probably leaving them below peak cognitive performance for the entire day.
For others, they are already in their awake-and-productive time, and they'll either have to stop to join, or they will simply waste time until the meeting, knowing that an interruption is on the way, and being preoccupied with those thoughts.
To work as a team, this is going to happen here and there, and that's fine. But to do it daily as a ritual is an incredible tax on your human capital for no good reason. Not only that, but you're filtering out your talent pool to folks who don't perform at their best under these constraints. From what I have seen, these can often be very high performers.
I can see the value of the standup but I find daily to be too often.
The best teams I've worked with have staggered them to either M-W-F or T-R, primarily because the work we do require more than a day. And depending how one works, a daily standup every morning makes it tough to get a good night's work in.
I used to like standup because that's the only time I have to see what my team is soingnsince most of them are remote and working in a different time-zome. It was a great way to give tips and do the "okay let's talk about this offline afterward."
But now I hated it. Not only rhe standup is mismanaged ao badly, I also don't have much to update on a daily basis which means I feel useless if I have nothing to say or have little progress on my tickets.
No way, my team gets a lot of value from our standup!
We have 5 devs. We have a scrum master, but we rotate who's facilitating from our lead down to our most junior dev. If our scrum master's out it's no problem, any one of us is able to step up. The first ~10 minutes or so are spent updating the team on the progress we made yesterday and making sure everyone knows what they're working on today. Pretty standard fair.
But we always take a full 1/2 hour. We use the rest of the time for backlog grooming. It works really well for us for 2 reasons:
1. We get a lot of reactive work, and it's really convenient to have time set aside every day to address it
2. By piggybacking backlog grooming onto time that we're already scheduled to be together as a team, we cut down on the number of other meetings we need to have (and context switching to/from coding). We all find it much more convenient to spend an extra ~20 minutes together every morning so that we can have the rest of the day to work.
People, I respectfully do not agree with this blog post.
How people can notice that work is not being done if they don't do meetings? How to assure they are communicating correctly?
How to prevent a bomb explodes a day before the deadline?
If you discover problems close to the deadline, you already have a big problem. My opinion is that these daily meeting are to prevent problems, like integration between systems.
People are comfortable on their own doings, they don't like meetings, they prefer a problem occurs and share the blame than doing daily meetings. We must do daily meetings because it's good for the project and not because we enjoy it, we do to avoid that some lazy or introvert collaborator don't share a problem that can affect everybody.
That's why we have a scrum master to do the dirty job and assure everyone is talking each other.
You can perfectly go to a daily scrum meeting and say that you are doing your job on schedule and have no problem to report and, maybe, are available to someone who need a help. These meetings must be rapid.
It's complicated. Who decides if it's necessary? Most of people prefer to stay on their comfort zone, that is why I think the team must follow some rules.
I actually like the way we do stand ups at my current job. All of us sit together, so we just stand up in place and state what we are working on and if we have any blockers that need to be taken offline with specific ppl. Whole thing will be done under 2mins.
In regular corporate settigns, I see these standup meetings are a way to simply make information flood across organisation hierarchy. A good leader can then parse and make sense of signal amongst plenty of noise. But it does rarely serves that purpose. We used to 've standup of 10 members several years ago! Since then I kind of developed disliking towards regular meetings. Currently we 've a trello-kanban updated so that we've information flowing. And a weekly mail with traffic lights, explaining current-and-next week activities - working well so far.
Worked on a team just like described, all on different projects. It was infuriating, the boss interrupted me every morning at ten, just as I was entering the "zone" for a no value (to me) standup.
Having just finished a 5 week agile project with daily stand-ups I found:
1. I'm already aware of what everyone is doing which is relevant to my own work outside the daily meeting. Everything else is just noise.
2. I don't want to know what someone else did since the last meeting unless it was relevant to my stream of work, in which case I already know about it.
3. See above.
Needless to say I found the daily stand-ups a complete waste of time.
I'm intrigued by 2 - granted, it doesn't have to be part of a daily meeting, but surely learning about other workstreams is still a net positive? In theory it's still about the direction of the same organisation which is important, no?
I absolutely agree- I should have clarified I don't want to know about it as part of a daily ritual that is the stand-up. I'd challenge anyone to summarize what other people talked about during the stand-up right after the stand-up. I bet they don't know- because they were thinking about their own work they wanted to get on with after the stand-up. The only thing I remember from the 5 weeks stand up is when the client summarized what she had been doing the previous day with 'I was just faffing about' :).
I'll agree with that as well, most update meetings I've been in are mainly spent with being half-present whilst listening, and then mentally updating my own list based on how granular other people are being.
- Other works streams might not affect yours, but don't you find that it helps you to understand aspects of the project that will affect future workstreams?
- How do you or they know that it will have no affect on your area without the daily stand up?
- If someone is experiencing a blocker, you might have come across the same issue earlier in your career or even last week. Then you can help them.
These are all very valid points but I don't feel the need for a daily stand up to achieve them! Effective communication and meetings already achieve these things.
If your team has effective enough communications to not require them, then I guess they're not for you. For me, that has never been the case in any team that I've worked in.
Provided only work that's in the issue tracker is worked on (thus avoiding work being done more than once by different people), I've never found 2. useful.
That is, the information has never been actionable for me, so it really doesn't matter what people did.
People SHOULD flag stuff they encountered that others should know about, but to me that's part of the 3. "what you need/can help on" category (essentially "anything you want to flag?" be it gotchas, blockers, offers of help etc)
Even 1. I find usually not useful, provided you do regular planning meetings (I like them to be weekly personally) where people are roughly assigned to areas and then just work off the backlog, although it can vary I suppose.
I buy into the peopleware model personally: status meetings are a distraction, other meetings need an agenda (with a clearly defined "end point") and be time boxed. Aligning people and sharing knowledge should be accomplished through informal "coffee morning" conference-breaks-hallway-conversation style events. Ideally an hour set aside once a week, purely for this. That largely covers the cases of people overhearing what you're doing and saying they can help.
In my experience, my team works so closely anyway that the standups don't add much, if anything, and the people who could benefit are not at the meeting (other teams basically). I've tried text updates in slack and that had the great side effect that other teams could see them and offer advice or help, but the downside is they're boring and people often don't read them. Informal coffee morning chats largely solve that in my opinion.
Besides peoplewares suggestions on meetings, I also really like the GROWS Method model of agile.
No, because the moment a meeting starts allowing discussion it starts taking ages, and you've got your entire team standing there waiting for it to be over and it becomes an enormous waste of time.
Maintaining discipline for daily standups is phenomenally difficult.
I am just trying to say that you do not necessarily need a daily meeting to achieve these goals. And that you might get all the value from the daily scrum with something that better suits your team.
Right now my team are trying out only doing standups if there's important stuff to share. This leads to 1-2 standups per week for the past month.
Tidbits of info which can be shared at a glance, and probably don't affect anybody's workflow, go on a whiteboard. That way we know everybody's status, and seems like we can share important info when it matters.
Not very convincing. But standups should be tailored for team needs, rather than imposing a standard. And I don't get the role of a Scrum Master. Good article overall in terms of encouraging discussion.
My company did standup for 3 years either in person or over hangouts (once we became distributed), and recently switched to an async model over slack. Much better engagement, and much better quality updates.
stand up has to be the one good thing about scrum. the rest is just boring meetings which cost too much time entirely. but 5 minutes i can spare each day. the daily accountability it brings keeps managers from firing me (i have been fired way too many times often in the first week) as they know what i'm doing and therefore dont think i lack motivation. it also motivates me to perform even better.
i dont think standup is bad at all and i think managers should be present for it. it may not be for some kind of idealistic 'for the team' thing or even the original intent, but... standups are a good thing. even if you're not doing agile, standups can still be useful to keep managers informed if you are a larger team (>3 people).
The standup meeting can burn in hell. It's a lovely bit of useless micromanagement. Consider:
If you're organized at all, there should be notifications going out when anyone on your team commits code, or comments on tickets, or whatever. If your communications are so dysfunctional that you need to have a defined point every day to apprise people of what is going on or ask questions of your teammates, focusing on that root problem would be more effective than band-aiding it with a daily standup.
There's never a good time to schedule it. No matter when you do so, it's going to frig someone up and waste one to two hours of productive flow time, at best. First thing in the morning doesn't work, because people run late. Later in the morning, and you might as well kiss the whole morning goodbye for productive work. At the end of the day, it will inevitably run over and piss off everybody who needs to get the hell out of the office and take care of their personal obligations at the end of the day.
There's always one or two people that want to ramble along and narrate every little thing they did in excruciating detail. Or that want to turn an issue that turns up relevant to two people into an interminable status/planning meeting on that issue. Mostly, I'm just not convinced that there is any way to do a standup meeting right, so that it is useful for it's stated purpose without being more costly than it is worth.
If you need this kind of fine-grained progress reporting, have everybody send an email or a group chat with the three standup kindergarten circle-time questions answered. Then if there is an actual need to meet and go over something, you can identify the relevant people and not waste everyone else's time.
We ditched standup meetings a while back. It's been glorious.
That's okay, if your team works in this fashion. You shouldn't cargo-cult stand-ups or any other aspect of Scrum.
It's important to realise that they are a tool, like any other form of meeting or organisational strategy. For example, if you find that your team are sometimes stepping on each other's toes, then a daily stand-up might be able to help with that. If you don't need them, then don't have them.
You work. You do your job. If you're unsure about what task to do, you speak to your manager. You know, how offices have worked for the previous hundred years.
My team is working on an big application with 100k+ users, worldwide, generating a couple hundred mill in revenue/year. Native apps on multiple mobile platforms, heavy enterprise stuff.
Tried it without stand-ups - doesn't work.
Once you need to coordinate heavily, care about speed and quality at the same time, working in code bases others have written you try to align with others as much as possible.
We do 2-3 stand-ups per week, depending on team preference. M-W-F or T-T.
It works, far less trial and error, far less issues found late in QA.
Daily is too much, that we learned. No structured stand-up at all doesn't work either, humans are not disciplined enough across large teams.
So for who's benefit are standups and "agile" in general? It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing. For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers. Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.