Hacker News Reader

> As an EM, I use documented standups to keep track of how long and when people work on tasks.

:(

We're actually coming at it from the other side -- we built it to take the pain out of standup and encourage more meaningful communication. It's definitely not designed as a people management tool.

It's disappointing that standups are used in this way. I don't know you and I don't know your team but this kind of approach to standups is probably wrecking your standups.

The standup has it's roots in the agile manifesto[0] (gross simplification). Specifically "Individuals and interactions over processes and tools". The coming together every day for just a few minutes is an opportunity to ask for help (blockers).

Both the standup and to an even greater extent the retrospective are exercises in trust. I agree to show weakness and tell you and the team when I'm struggling with a task, or when things aren't going well, seeking continuous improvement. You agree not to use that against me.

The sooner roadblocks and problems are discovered the less likely they are to become larger problems. This is one of the fundamental benefits of a standup. But this requires trust. Recording and documenting for the purposes of performance management is probably the number one way of destroying that trust.

All of this means they're a very fragile beast. Prone to becoming exercises is puffery, or even worse a list of cards being worked on that you could just as easily get from the wall/Jira/trello.

The team also succeeds or fails together, a much better way of dealing with employees that are struggling is to use pairing (sparingly) to ensure that anyone blocked on a task doesn't face it alone. Some things are just hard. I've got 20+ years of programming under my belt and I still manage to struggle at times.

I've got the experience to work through this and ask for help where needed, but the earlier you are in your career the more imposter syndrome makes it desirable to crawl into a hole rather than ask for help. Standup in a great team helps break down those barriers. But only if a very fragile trust is maintained.

[0]: https://agilemanifesto.org/

A large part of Agile, at least from what I remember in my ScrumMaster training, is to recognize reality.

You estimated that you would do x amount of work. You only did y. Or, you did x + z - wow, you are a great performer. You should verbalize your success more often.

A part of confronting reality, is confronting the prospect of under-performing employees.

I think your 'ideology' is blinding you a little bit OP, at least - if you want to base your concept of standups based on how they were formulated in the original Agile manifesto - 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'

Frankly, most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress and to check in on a couple of things here and there.

The selective pressures of your model reward dishonesty (under promise over deliver / make estimates as high as possible to mitigate downside and reduce pressure). Why is that making your team better?

Honest question: why is this bad?

If my estimates are padded to the point where I always complete what I commit to and my boss is happy with my output, what’s the problem? My boss gets value from being able to accurately convey estimates to clients, the client 9/10 gets the work done on time or maybe even gets a couple extra features completed in the same timeline, and I as the engineer, have a relaxed work environment, free of the stress of cramming every story point possible into 40 hours a week.

Seems like a win win win to me.

This might be okay in isolation, but eventually as the entire team of engineers start to underdeliver, the team and company does get affected in terms of feature rollouts / velocity, and it's difficult to recover from it. People won't want to suddenly correct / do more work even if it's crucial, and they can point to their previous underestimated commitments and say that is a full week's worth of work. YMMV as with anything, but not knowing a team's true velocity does affect planning and sales.

Parent said "boss is happy with output", there is no underdelivering here.

The actual work doesn't change, it just changes your point estimations. Either the boss is happy with the actual pace and quality of the work, in which case you don't need points to begin with, or the boss doesn't understand the difference between story points and actual time, in which case it's all a dog and pony show anyway.

All this teaches employees is to lie to make themselves look good. If you really want to increase development velocity, implement better coding practices and devops and tooling and training and invest in your employees instead of making jump through stupid hoops like circus animals.

> wow, you are a great performer.

No, you aren't. You just either suck at estimation, or you deliberately underestimate to shine brighter in the eyes of your slavemaster. And if the rest of your team also "overperforms" consistently, there's a conspiracy, which means I will stop making you commit on stuff and will just ram more tasks down your collective throats, abandoning another aspect of the agile way of work.

See how easily such an abuse of standups can be turned around to make the very same person look bad? If that is possible, is the approach a good one?

> most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress

This is mostly related to PMs and SMEs pushing a perverted interpretation of Agile.

> The coming together every day for just a few minutes is an opportunity to ask for help (blockers).

The rest of your message about unblocking early seems to contradict your first statement of waiting until scrum to ask for help.

I don't think I suggested that someone should wait, just that the opportunity to talk about blockers (ask for help) was important.

Each of the loops is about shortening the cycle before you discover problems. These are seen through the lens of traditional waterfall software development. The problems vary in nature, from technical blockers and dependencies, to unrealistic deadlines and expectations, to not building what the customer wants (why we involve the customer early and do showcases).

In some ways the more mature your team becomes the more you can move past some of the rules. The 'standup' was designed to avoid the meeting becoming overly long, everyone would become foot sore. Once you understand and embrace making the meeting not turn into an hour long (or even 30 min long) meeting, the standing itself becomes less important (which is good because remote teams make this harder).

Similarly, there are even shorter cycles of being able to remove blockers now. Granted Slack team channels can be a blessing and a curse, but it does make it possible to just put problems out there for consideration[0]. These sometimes go unanswered though, which means that the aforementioned standup becomes a backup.

I've been part of so many lean/agile teams that all do things slightly different. The highest preforming of those were the ones where the trust was the highest. Great teams become "a rising tide lifts all boats"[1].

I hope you don't see this (and the previous post) as an attack. It's near on impossible from a distance to really see. It felt like a red flag but that's two lines of text on a semi-anonymous message board.

[0]: draft PRs also fall into this category. Though again, devs have to find time to read them.

[1]: https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats

I guarantee you're driving some employees to worse performance because they're depressed from having a meeting every single day at which they have to justify their continued employment. This kind of thing is absolutely soul-crushing.

You're likely also straight-up killing standups as a collaboration tool for the team. They work best when the team can be very open and honest. This use of standups ruins that. You probably shouldn't be in the standups at all, in fact, unless you're also contributing code to the project(s) on a more-or-less daily basis. Further, these practices tend to turn standups into sharing way too many details about every little problem or task the previous day, which also contributes to making them worthless for the people actually doing the work (plus, even more miserable to sit/stand through every single day—see again: the first paragraph, like, the general principle here is maybe don't have a standing daily meeting that everyone completely fucking dreads)

Also: where the hell's your project manager? And how is your issue tracker broken enough that you can't tell what people are working on or for roughly how long, without this? Between the tracker and the repo(s) and occasionally just chatting with people, you should not need this to tell how well people are working.

As a bona-fide, certified, rarified SCRUM-MASTER here (respect mah authoritay), I just have to say - does anyone really think a standup is a 'collaborative' meeting?

It's a check-in meeting! If you weren't productive yesterday, just say so - as long as you are generally keeping your commitments and shipping your features on time, it's fine. If you are behind, you can verbalize it - and if it makes sense, it makes sense. If it doesn't, well you are starting to break the bonds of trust between teammates. That's on you. And high performing teams don't have a place for that.

Now, if that's not the culture at your company, then you frankly have much bigger problems than a stand-up meeting.

A check-in meeting is still a collaboration tool (the phrase I used), so... yes? But I get the sense you're using these words differently from their normal meaning, so it's possible that in some jargon-sense they're not, because a check-in meeting can't be a collaboration tool because those have strictly exclusionary definitions, or something. But under ordinary usage of the terms, yes, sure, a check-in meeting's probably usually a collaboration tool. I don't even know how it wouldn't be, except, again, maybe under some "house" usage of the terms, or if the meeting's gone pathological and is just a zombie-meeting serving no purpose at all.

My main point is that the meeting should chiefly be for the team doing the work. They're the ones whose collaboration (yes!) should be served by the meeting. If the meeting's a bunch of people taking turns saying stuff the rest of the team already knows, or doesn't need to know, to turn it into a status report for a manager, that's a shitty standup for a bunch of reasons. If a manager's basing fire/raise/promote decisions off data gathered in standups, people are gonna avoid saying things they ought to, and say tons of shit (maybe even true shit! Not necessarily lies) that no-one but the data-collecting manager needed or wanted to hear. Those kinds of practices tend to change standups to make them far less useful to the team. The useful-to-the-team communication that the standup's supposed to encourage will instead happen elsewhere, or even not at all.

That is how you get standups that the ICs dread and derive no value from. It's how you get people half-sleeping the whole time except when they have to talk. It's (part of) how you get half-hour standups. It's a big step down the path to the agile-as-micromanagement thing that's much of the reason so many people hate agile, as it exists in the wild.

Oof, half hour stand-ups.

I see what you are saying though, I think my definition of 'collaboration' didn't immediately translate into your head. When I think of check-in, I just think of taking attendance. Who is at work today? In two or three sentences, what are you working on today? This way, the PM knows who has a little bit more slack in their day, and who can be assigned to triage a bug that pops out of nowhere, for example. I work at a smaller company, where product engineering goes hand in hand with fixing bugs. They aren't different teams.

'Collaboration' implies some sort of positive activity, that creates or generates something, whereas I think of a standup as simple a check-in exercise that provides a mechanism for people to notify someone 'hey, I need to discuss this with you, let's stay on after the call'.

My definitions are my own though, and probably pretty weird. I've tried to internalize the spirit of Agile, and through that internalization my main conclusion with a standup is that it's just a way to check in, and springboard into deeper triage conversations while allowing product management to understand what is being worked on.

Doesn't sound fun at all. I wonder what the employee attrition level is.

Maybe everyone is happy with this (or don't question it), I certainly wouldn't be. :shrug:

Unless it's not clear, remember people leave employment because of bosses rather than the company.

I'm an EM as well and this is horrible, both from a personnel management standpoint but also just from the "understanding what the standup is for" standpoint.

You should be using standups to hear what your teams' blockers are, then spend the rest of the day getting rid of those blockers.

I prefer to be told when blockers happen and not 12-24 hours later. There are many different types of management styles though...

They're not mutually exclusive.

I feel sad for your teams. I mean this with respect but you should consider management training.

This strategy is set by my manager.

The only feedback I am seeing in this post is how standup should be used to report blocks. I encourage my team to message me when they have questions and not to wait until a sync meeting to report issues. We rarely discuss blockers because those are address in 1:1 or project focused meetings.

Why would blockers wait for 1:1s and project meetings? Hopefully those are happening less frequently and should be addressed sooner.

But the in another of your replies you said you want people to contact you directly when there is a blocker rather than wait until the following standup? Those statements seem contradictory.

It sounds like you prefer to micromanage rather than really being Agile and allowing developer autonomy. This approach just frustrates good developers who want to learn enough about the business and the team that they can go directly to the source rather than having a micromanager as a go between too continually slow down the team.

It's not async vs sync thing, it's that you're perverting stand-up from a tedious but low-stakes collaborative process (hey, what's everyone working on, who can help me with this quick problem...) to a grueling and ruthless micromanagement process that gives you false metrics to judge your employees by. It's a sign that you don't really care about your people or your team or their morale and just want to find easy numbers to evaluate people by, the engineering equivalent of "you're fired because you clocked in three minutes late four times this year". It's totally irrelevant to the job at hand...

Yeesh, it scares me that there are people like you who actually think this is a good management style. It's not even a management style, it's just petty sadism. Please seriously consider another career, this is not good for anyone on your team. Sorry to be so harsh, but god damn, this is one of the most braindead, heartbreaking, soulsucking posts I've ever seen on HN. Your team deserves a better manager than you.

Can I ask which company you work for? I want to be sure I never work for them.

When they say "people don't quit jobs, they quit managers"... pretty sure they mean you. God, that's toxic, and I'm so sad you're in our industry.

documented stand-ups is a real red flag for me. You're forcing everyone on the team to participate in your in=person, synchronous, verbal task tracking system. It also sounds like you're making important career decisions based on the single dimension of "how many daily tasks are you crushing?". How can that work for anyone above a junior developer when the real value can't be measured in such small units? Just a guess, but I'd suspect your 1:1s (if you do them) are also msotly status updates.

I'd suggest you focus your stand-ups on blockers more than what did everyone accomplish, then review work async on your time. If it's not getting done yet no blockers are raised, that's something to investigate.