If any issues come up, you can discuss them immediately after the standup.
Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.
>Standups are in my experience much more effective at signalling blocking issues than slack.
Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?
>Nobody is going to spend their day checking what other people are doing on Jira
Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
Here's how it works when you use your tools:
1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.
2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).
In my experience most people don’t regularly post summaries of their progress on their ticket. Even getting certain people to update their ticket descriptions at all (to add test instructions or to reflect that they decided to do something other than originally described) usually requires reminders.
This may depend on team culture but in my experience a lot of people just aren’t written communicators.
I don't like the sentiment that developers doing things out of their comfort zone (like using JIRA) is unreasonable. Just get over it and be a professional.
That said, it's on others to motivate the use of such tools. It's easier to get buy-in when everyone understands the value.
A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.
Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.
You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.
It's not just the time itself though, it's the interruption that prevents you from starting longer tasks effectively.
Can't really account for that, work is not only about summing up minutes on a time tracking tool. There is rythm, there is acceleration, there is a productive state and there is deceleration.
Standups disrupt all that without any real benefit, other than serving as a daily reminder that you better hurry up with what you are doing - which most people don't need.
This is obviously stressful, and psychologically pressures you to try to finish the task ASAP the day before, so that you can come up to the meeting and just say its done.
Which is the real actual benefit of the standup, and why managers keep doing it, despite they are obviously not needed and in most cases a waste of time.
The standup keeps everyone on their heels and feeling like their every breath is monitored and accounted for.
Its the perception of yourself and your work from the eyes of the group that is at stake here, it's important and most people usually don't just improvise it.
Many times people have notes of what they want to say, which involves preparation, attention and energy put into it that would better be directed elsewhere.
It requires very little thought.
I've prepared for standup when I was new to a team, but it should pretty quickly get to the point where you don't need that. At least for my experiences, it's not like standup is a major factor in how teammates think of you - that comes from working together with people.
If your teams have so little trust in each other that you have to do all this preparation for a standup, then there are already much larger issues.
There's just no deep work that can be done during that time, and that's every day.
That's disruptive!
> Standups are in my experience much more effective at signalling blocking issues than slack.
If you are using Slack, you have already lost the battle for productivity.
> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.
Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.
> And even then I'd guess it's useful to have a quick refresher about what you're working on.
To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.
Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.
> "To a first approximation, nobody cares what you're working on. Nobody should care what you're working on."
I care quite a lot what the people in my team are working on. Otherwise why are we even a team?
If you're not in a team, obviously things are different.
> "If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work."
It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
It's an argument for having meetings when you need them, with whoever you need them with, with no particular schedule or routine attached.
> I care quite a lot what the people in my team are working on.
Do you really? Or do you just want to signal that?
> Otherwise why are we even a team?
You are on a team because that's the unit of organization above the individual.
> It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.
If developers need to cooperate, you have a problem that you should avoid at great cost. Of course, sometimes cooperation is unavoidable, but it's not a good thing in and of itself. Don't let anyone tell you otherwise. Aim to split up your work to require minimal cooperation. This may sound like unconventional advice, but anyone with enough experience managing developers will likely agree.
Phone calls and texts? Don't let your developers do them.
> To single out 'standup' as a particularly disruptive interruption may be exaggeration.
It isn't an exaggeration, because a standup is also a pending appointment and a mini-presentation. A lot of developer types actually get stressed out about this, no matter how small.
Similar thing with responding to an e-mail. It's insane how much time some people spend on just a one line reply.
Just minimize these things, don't make them part of your routine for routine's sake.
I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.
For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.
I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).
If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.
You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.
The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.
Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).
Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.
A few elements that I think contribute to long standups:
* A very large team (I've been in a marged team of 14 people once...)
* Getting too much into technical details: don't do that; have your technical discussions after the standup with only the relevant people
* People sharing their opinion (frustration) about blocking issues and that developing into a discussion. Again, leave it until after the standup.
When standups drag on for too long, it's time for the scrum master to step in and get people to keep it short.
IMHO that would be okay, if not beneficial.
>and that developing into a discussion.
That not so much.
The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.
The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.
If the time isn’t useful, find a way to make it useful.
Walks in? Yes. That should be discouraged always.
Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.
If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).
It seems most developers aren't even comfortable with the first bit, let alone escalating things. Instead, most people just seethe and complain privately to other colleagues, and nothing changes. At the very least, the team's manager should be brought in to do a better job of protecting the everyone's time, and you'd think that would be easy for a developer to do, because it outsources any sort of confrontation. But it still often doesn't happen, for whatever reason. (Of course, if it's the manager who is the offender here, you're probably screwed if the diplomatic method fails.)
This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.
I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.
I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."
But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.
I can see two possibilities:
1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.
The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.
I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.
Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.
They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.
Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.
See:
> It's like communism; it only works if you "do it correctly."
But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.
Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.
This of course only works if you actually stick to what the stand-up is meant for.