5 ms·

As an EM, I use documented standups to keep track of how long and when people work on tasks. When a person is under performing, this document is invaluable refe

by itake 4y ago

As an EM, I use documented standups to keep track of how long and when people work on tasks. When a person is under performing, this document is invaluable reference. When a person is exceeding expectations, this document helps me write their promo doc. This could could be useful to manage that data better, but currently I use a Google Doc sheet. That being said, I couldn't justify the cost of this tool to my manager when Google Docs does it well enough. Perhaps, this could be sold as a cost savings strategy for finding low performers?

appletrotter 4y ago
> As an EM, I use documented standups to keep track of how long and when people work on tasks. :(
joshwillis2000 4y ago
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.
vertis 4y ago
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/ https://agilemanifesto.org/
- mikhael28 4y ago
  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.
  - stefanmichael 4y ago
    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?
    - yurishimo 4y ago
      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.
      - sahila 4y ago
        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.
yamtaddle 4y ago
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.
- deleted 4y ago
  [deleted]
- mikhael28 4y ago
  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.
  - yamtaddle 4y ago
    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.
vlod 4y ago
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.
noam_compsci 4y ago
I feel sad for your teams. I mean this with respect but you should consider management training.
- itake 4y ago
  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.
  - bigtunacan 4y ago
    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.
  - solardev 4y ago
    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.
pc86 4y ago
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.
- itake 4y ago
  I prefer to be told when blockers happen and not 12-24 hours later. There are many different types of management styles though...
  - pc86 4y ago
    They're not mutually exclusive.
solardev 4y ago
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.
respondo2134 4y ago
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.

by itake 4y ago

appletrotter 4y ago

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

joshwillis2000 4y ago

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.

vertis 4y ago

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/ https://agilemanifesto.org/

mikhael28 4y ago
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.
- stefanmichael 4y ago
  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?
  - yurishimo 4y ago
    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.
    - sahila 4y ago
      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.

yamtaddle 4y ago

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.

deleted 4y ago
[deleted]
mikhael28 4y ago
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.
- yamtaddle 4y ago
  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.

vlod 4y ago

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.

noam_compsci 4y ago

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

itake 4y ago
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.
- bigtunacan 4y ago
  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.
- solardev 4y ago
  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.

pc86 4y ago

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.

itake 4y ago
I prefer to be told when blockers happen and not 12-24 hours later. There are many different types of management styles though...
- pc86 4y ago
  They're not mutually exclusive.

solardev 4y ago

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.

respondo2134 4y ago

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.