Stop the Daily Standup Meeting
devteams.at
devteams.at
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.
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.
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.
Some folks don't think they need standups, ok. But in reality, many folks benefit from them.
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.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?'
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.
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.
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.
In this case just post the question of your team channel on slack.
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'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 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.
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.
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.
You mean the scientific method that has proven to work since the 1700's?
I think we'll have to agree to disagree that you can just riff it and still get results.
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.
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.
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.
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.
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.
Look up "multi-armed bandit"; it isn't just "riffing it" like you think it is. It is a mathematically-principled technique.
In fact, it is probably safe to say it's more mathematically-principled than the "scientific method" itself, as it is popularly understood.
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.
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.
And if they seem to be competent, you can ask them less and less. Why do you need one-size-fits-all approach? I recommend this presentation: https://www.infoq.com/presentations/Developing-Expertise-Dav...
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.
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.
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'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.
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.
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.
If your manager takes part in your daily, you're doing it wrong. The daily is for same-level coordination, not for hierarchical evaluation.
In a way, your dailies are to replace your manager, not enable him.
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.
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).
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.
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.
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.
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 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.
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.
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".
Recognising the existence of one-person teams might help a bit.
If the discussion can add more value than those costs, then go for it.
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.
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.
We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
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.
This is highly context sensitive. The models I deal with when I develop software change very seldom, if ever.
Different projects have different cadences for inputs and outputs, even within this wide domain we call "software engineering".
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.
Stand-up meetings are dispatch, not processing.
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.
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.
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
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.
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.
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.
"Yes, I said the same yesterday, it's a big job, but it's going fine."
and, this is even more defensive, you feel people will not believe you so you invite them to see some proof:
"Anyone can come over and ask me about analytics if they like!"
Maybe the biggest problem is this though:
"Yesterday, analytics. Today, analytics"
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.
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.)
IMO, only for a small minority of tasks.
The vast majority of projects I've seen and worked on are measured in dev years of effort.
My current project is well over a thousand dev years.
In comparison a few days is meaningless.
Most often it's a trust issue.
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.
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.
Kind of. It's upper-medium.
It's nothing compared to Microsoft Office, a web browser, etc.
Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.
> Typical project size is somewhere around 500 to 1000 man days.
That's roughly 2 devs for a year. That's hardly even a prototype where I work.
It is fascinating to see the difference in scale in our industry.
Tracking progress goes on a Kanban board (or digital equivalent).
www.scrumguides.org/scrum-guide.html#events-daily
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.
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.
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.
The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ...
Wait, we created "agile". Haven't we?
Overreport and micromanage to deal with issues.
"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"
(later that year)
"Why have you lost your motivation?"
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."
(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.
Do you think that before standups were common developers just spent weeks spinning their wheels?
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.
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.
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...
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.".
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!
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).
Well in that case I sure hope you're not planning on wearing one of those t-shirts...
Only to be judged by appearance by people who claim to have soft skills.
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.
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".
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.
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.
So I started calling them status meetings.
"Hey, stand-up in five minutes!"
"You mean status?"
... and kept doing that. Eventually even the PM grudgingly admitted that it was just a status meeting, and referred to it that way himself.
It was okay; agile had died (and turned into simple micro-management) a long time ago in our division.
I think "bad stand-ups" is a symptom you are using a self-organizing practice in a command-and-control team.
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).
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.
Single clear and accountable leader is much better way.
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 ;)
In any case, it takes only one team member to be aggressive micromanager in order to blow self organization in hell.
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.
(But if there isn't a compelling reason to be counting the days, it's still nice to have the option to "go dark" for a few days sometimes)
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.
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.
Sounds pretty much perfect to me (although I also know people who would go stir-crazy like this...)
Can I ask: what sort of company is this? Dedicated software operation or a tech department inside a company doing something else?
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.
I meet with my manager once per month to ensure our goals are aligned. We tend to spend 1-2 full days together so we can "go deep".
In contrast I work with other developers almost every day.
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.
> It would not be feasible to 'report to a tech lead every 2 or 3 weeks'.
Yet there is nothing in your workflow that demands a daily standup either.
So really you are saying "We find standups helpful". That's a far cry from alternatives are not feasible.
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.
So it is a trust issue.
Surely you can see how this makes people feel they are being treated like children?
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).
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 think the spirit of agile development is lost on most places and blindly sticking to process without questioning it becomes the norm.
That's simply too frequent.
People will spend all their day thinking about what they will present the next day instead of doing actual work.
Sure, but does everybody need to be updated every single day? And does that update have to take the form of an all hands meeting?
We were all shocked that a manager could justify wasting that much time every single day.
We have no standups since we all work on different projects, we don't really need to know what everyone else is doing.
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, ..... )
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.
Like a parent counting down before you're put in time out.
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.
Standup for me is making me accountable.
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.
TL;DR focus on tasks not people reporting. I ranted about this some years ago... http://blog.flurdy.com/2013/04/i-dont-care-what-you-did-yest...
- if it's a status/reporting meeting - don't do it, there are better tools.
- if it's knowledge transfer meeting and it benefits a whole team - do it.
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.
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.
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 often point people to PG's relevant essay during discussions about this: http://www.paulgraham.com/makersschedule.html
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.
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.
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.
Encouraging communication is a great goal ; but trying to force it on a regular basis might have the contrary effect.
Goals are:
1. Discussion on who's doing what ( details )
2. Discussion on who did what, since last meeting.
3. Help / suggestions based on the conversations above.
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.
And in many cases, the precise details of what someone is doing aren't really relevant to everyone, either.
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.
In my experience, the frequency seems to be more about maintaining a feeling of supervision.
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.
- 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.
I can't understand what other people are actually doing when it's provided in 1-2min snippets each day.
Even after a few months of this I will be clueless.
Maintaining discipline for daily standups is phenomenally difficult.
Without asking, standups are counter-productive.
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.
In absence of those, a 15 minute Standup seems (woefully) inadequate by comparison.
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).
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.
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.
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.
YMMV.