3 ms·

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 yo

by 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.
      - rglullis 4y ago
        Parent said "boss is happy with output", there is no underdelivering here.
        solardev 4y ago
        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.
itake 4y ago
> 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.
- vertis 4y ago
  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 https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats

by vertis 4y ago

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.
    - rglullis 4y ago
      Parent said "boss is happy with output", there is no underdelivering here.
      - solardev 4y ago
        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.

itake 4y ago

> 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.

vertis 4y ago
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 https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats