I call them "Secret Plans". You gotta save up the emotional energy and reward. On so many projects, you get the same neuro-chemical reward by talking about your project plans and how cool the result will be, as you do by making progress. By holding out, and only allowing progress itself to be a reward, and not just the talking, I usually get much further. The project may still die, but then I have something in my hands usually, and that's more rewarding than a bunch of people who think I only talk about things and never start/do any of them. . .
I found the best response to standups in a prior job was to randomise a delay about ongoing work. Simply talk about what you did 2-5 days ago (depending on urgency of things). This obfuscates your exact productivity and takes away organisational power from micro-managing bosses.
Whenever a manager comes in or there is a meeting to check on your progress, you can slice of something from your buffer to present. For every problem you present (from few days) ago, you can already present the solution.
Or, in other words: Your productivity is some process that you don't want to be observed directly by your manager, because you will suffer negative consequences from them detecting the exact amplitudes. You simply apply non-stationary smoothing to it.
Engineering manager here. I think a lot of people miss the point of standup, or abuse it to somehow micromanage engineers.
Standup is for the team, not the manager or PM. It serves multiple functions, but the most important is the last bit: "are you blocked by something?". Most of the time, someone else on the team knows how to unblock you. Other times, your manager is better positioned to get you what you need than you are. Most of us don't care when you work, or how much progress you made today, or whatever. Our job is to keep the ball rolling, not manage your time.
The status update portion exists so that your manager doesn't randomize you in the middle of the day asking about that thing you're working on. Not because s/he thinks you're slacking, but because your work ties into a bunch of other work that's going on, and it's the manager's job to coordinate. While you may be more effective working as an information silo, your team and org are hindered by it.
> the most important is the last bit: "are you blocked by something?"
If you've waited until the next standup to raise a blocker, you've potentially wasted as much as a day of your time.
If I have a blocker that I need unblocked to get my work done, I'll immediately get in touch with the person or team that can help unblock me. If I don't know who that is, or need help coordinating, I'll go to my manager, again, immediately.
> The status update portion exists so that your manager doesn't randomize you in the middle of the day asking about that thing you're working on.
That's what the issue tracker / scrum board / kanban board / whatever you use is for. Certainly some people and teams are better and worse about keeping it up to date, but a solid incentive of "if you keep this up to date we won't have to do standups" will motivate most people. As much as I hate Jira, if you eliminate a meeting from my day that I consider a waste of time, in exchange for keeping it updated, I will definitely keep it updated.
For special cases, the manager can asynchronously ask their report on Slack (or whatever) what they're up to, and the report can answer when they're at a natural break point.
This whole "we all need to be face to face in the same place at the same time" nonsense needs to go. People are remote, people are in different time zones, and they still need to be able to participate naturally and asynchronously.
If you figured that out yesterday then yes, you should absolutely go get help immediately.
Mentioning blockers in standup is about admitting you need help. Lots of developers have trouble figuring out when they're wrapped around the axle.
And it can be a little passive aggressive, but it's also a chance to point out that you've been asking for help and getting nothing. Basically you're warning the master/manager that your story is gonna slip if they don't start managing.
> Basically you're warning the master/manager that your story is gonna slip if they don't start managing.
This. But it doesn't have to be accusatory like that. It's a way to have opportunity for feedback without having to be pressed for feedback.
The best manager I ever had was great because he totally trusted his people. Standups were a non-intrusive way to keep the overall pulse and make himself available if he was needed...that way he didn't need to vulture around to make sure he could insert himself if needed.
I'll take planned and well used 5 minutes of direct management over compulsive and nervous micromanaging anyday.
You don't need standup to have a quick private chat with your manager to tell them you've been trying to get help on something for a while but no one is giving you the time of day. Again: communication is a part of any job. If you aren't communicating, and need a daily meeting to force you to do so, you are not doing your job and need better training.
It isn't so simple. We are developers, we are used to solve problems on our own. A lot of times I spend a lot of time solving a problem that a coworker already knows. And I don't know that he already knows.
IME standups are not even effective in unblocking most people.
Why would someone want to admit they're blocked by something in front of everyone? Someone else will inevitably proclaim that they have the solution, however simple it may be, and make the asker look stupid while elevating themselves.
Most people know who to ask to be unblocked or can ask their manager.
1:1s are the time to sync with regards to status on projects not in the middle of the day.
Weekly roundtable meetings are the time to sync up with the rest of the team and learn what everyone is working on.
The only purpose of standups is to slavedrive people into "productivity", which inevitably ends up with them thinking of how to hyperbolize whatever they're working on minutes before standup begins. Its useless.
I disagree with your reading of the article. It does not say that providing status updates in 1:1s are the "worst possible use of time" anywhere.
Quoted from the article:
"The point of this discussion is not to solve my Disaster, the point is that we’re going to have a conversation where one of us is going to learn something more than just project status."
Status updates are a conducive part of 1:1s and its the perfect time to get unblocked as the quote above duly points out.
As for learning about whether "feature A will collide with feature B", weekly/biweekly roundtables are the perfect time to learn about such things. The weekly cadence allows people to find time to collaborate on the possible overlap.
Lastly, I don't think the article is even that good. It seems to make up for its lack of interesting-ness by feigning conviction and edginess. The central point of the article is highly unusual in that it lauds novelty over pragmatism.
A 1:1 should be an environment where all of what the article talks about CAN take place. But that doesn't mean it SHOULD during every meeting.
Does your team communicate outside of the stand-up?
I usually know what everyone is working on (because of ticket assignments, code reviews, some occasional side meeting, etc), as I usually work with teams of 5 (or less) people.
Nope. Never once in my career have I been at a standup that was useful to me (a contributing or leading member of the team) and that wasn't simply for the manager. Your second paragraph also contradicts the first. Is it for the manager or not? Cause it sure as hell is not for the team members who are bored out of their minds listening to the other people on their team speak about their work that 99.9% of the time is completely irrelevant to one's own. This is the reality form the IC side. Maybe managers should wise up to it and stop wasting our time.
Standups are an extreme lack of parsimony.
IMO, weekly 1:1s and biweekly roundtable meetings are the right quanta to compress work into so that its relevant to the respective audiences. Most people learn to bullshit and zone out during standups. Daily standups don't make sense in anything but a rare and specific tight deadline.
>It serves multiple functions, but the most important is the last bit: "are you blocked by something?". Most of the time, someone else on the team knows how to unblock you
To preface, I'm assuming you are talking about daily standups. How often do you see this actually working for you? In most cases, if someone is blocked, then they would communicate that, either to a manager or a coworker. If someone is blocked for days at a time and doesn't communicate anything, thats a problem in and of itself.
I'd like to get more value from them, but most times the devolve into "status updates" and then all engineers end up blocked by the standup.
People don't always realize that their tasks is blocking someone else.
Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.
Spending 10 minutes every day resolving the communication and prioritization mismatches early helps deliver software faster.
With just weekly meetings, these issues could go unresolved for days.
Yes, exactly. A lot of people don't do a good job communicating this sort of thing. It helps to have someone else ask you what's blocking your progress.
I mean, c'mon. We're not children. We're professional developers. If anyone I worked with waited even a day to raise a blocker on an urgent task, I'd think much less of their abilities.
It's another trade off, though: do you annoy your developers for what I believe is just a slight increase in velocity?
While I do know some developers who like (or at least get enough value from to tolerate) standup, I know many more who find them an annoying waste of time. For teams that do standup first thing in the morning, it even makes them want to go to work less. How's that for starting the day on the wrong foot?
that meeting is supposed to only take 5 minutes, and it is only to discover the issue, not to address it. addressing the issue happens after the meeting with only the people who are actually involved.
5 minutes or 5 hours, an interruption is an interruption. My ideal day to be fully productive would've no meetings at all. I don't need each day to be an ideal day, just once a week (or more if at all possible). However, when there is an scheduled interruption each day every day, guess what?
Also, anything that feels like micro-management will be considered micro-management. A daily meeting to give a status report looks a lot like that.
> at the beginning or end of the day? or before or after lunch break?
That could work if everyone gets at work at the same time (+/-30m) or if everyone takes lunch at the same time (+/-30m), which has not been the case in most of the companies I've worked for. It'd be better at the end of the day, assuming no one does extra hours, but then it's even less useful or at least it becomes obvious it's all about status-updates.
> micro-management is if i tell you every single step that you should do, but a daily status-update is not
It's a micro-management enabler. There's no way to know if it's used to pressure someone to deliver, or to do things a certain way, without working in that team.
The bottom line is that stand-ups are of very questionable use. There are just better, more effective ways to communicate what everyone is working on, what things are done, and when someone is blocked. i.e: ticket assignments, PRs, sporadic side meetings, asynchronous communication (Slack, emails, etc), etc.
It'd be better at the end of the day, assuming no one does extra hours, but then it's even less useful or at least it becomes obvious it's all about status-updates.
i disagree that doing it in the evening makes it less useful.
it shouldn't matter much if i report resterdays work and my plan for today, or i report todays work and my plan for tomorrow.
and sure, people doing scrum wrong can use this as a way to enable micromanagement. but as has been mentioned elsewhere, the alternative is managers running around and interrupting you at will. it's not reasonable to blame daily standups for that and reject it just because it gets abused by some.
the kitchen knife analogy comes to mind...
i have had nothing but positive experience with daily standups. they help me focus and not spend days trailing off on a tangent or failing to ask for help because i am the junior, to shy to ask questions, or worse, harbor the feeling that no-one cares about my work. in other words, for me the daily standups acted as a team-integrator.
as a team leader and manager, daily standups help me be uptodate on what's happening, and save me from having to invest time to check myself. if anything, daily standups help me avoid micromanaging, because they satisfy my anxiety about the work being done without needing to be intrusive.
5 minutes of your time, that you can prepare for, so you are not surprised by it, and you'll be left alone for the rest of the day.
> Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track.
Not in my experience. Most developers I work with will raise issues in Slack as they come up. That's part of what being an owner of your tasks is about: communicating issues early and often.
In this case I think it's the opposite: most junior developers I know are much quick (sometimes a little too quick) to ask for help when they're stuck, while a senior developer's ego might get in the way of raising a flag.
The comments in relation to the view of process and management from the general HN audience makes me feel for the challenges of being an effective engineering manager.
Perhaps you should also feel for the engineers, who constantly have to put up with managers who don't understand what motivates them, and yet has power over them with regard to firing, compensation, work assignments, etc.
My most effective managers have mostly left me alone, and have genuinely interacted me to learn what motivates me and helps me get my work done most effectively, and then has put me in the best position possible for me to be successful. An effective manager needs to do that, individually, with each member of their team.
Standups to me are just a way to ensure everyone is awake. And able to answer a simple question and make a sentence. I don’t exactly care about the contents, except from time to time when it makes us notice that a colleague is on a wrong track.
That's contrived and juvenile. Standing in a circle with my team engaging in process for the sake of process doesn't make me feel like a part of a team. Getting stuff done and working directly with teammates on a daily basis, coordinating in person, on Slack, however we choose to do it, organically, is what makes me feel closer to my team.
Aren't those contradictory? Someone talking on the phone clearly isn't standing in the circle with you.
I understand the benefit of standing together, but not if you're going to add an exception for someone talking on a phone from anywhere in the world. Physical alignment is a great metaphor for team alignment, and therefore physical absence shows me someone cares more about sitting on their porch with their dog than being part of the team at work.
Depends on the kind of person. Surely a lot of programmers do not care about that kind of contrived team building. Solving a high priority bug or patching a server during downtime typically builds closer bonds.
This is certainly a position I've found myself in, there's a temptation to talk about ideas you intend to do, but the ones I get progress on are ones where I actually execute on the concept, telling people later once I have something solid to show, or I already have someone engaged asking me about progress.
The current commentary might be a personality specific thing however, I've certainly seen people discuss ideas as a forcing mechanism to get them to work on them, and also people discussing ideas as a way to evaluate whether they're worth working on. I doubt it's very clear cut.
