4 ms·

We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re bei

We use Agile at our company and let me tell you, it sucks. Maybe straight up scrum would be worse, but honestly agile is invasive and just feels like you’re being babysat and forcing people to give BS updates at standups because they’re afraid of sounding unproductive.

prepend 2y ago
I find Agile is like democracy. It does suck, but it’s better than everything else. What would you prefer besides agile? I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
- rightbyte 2y ago
  I'd have the straw man variant of waterfall every day in place of agile. Like, the constant micromanagement and process lawyers pushing you down makes me misarable. At least with classic project processes you'd have some oversight plan to follow.
- pyrale 2y ago
  > I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
  - prepend 2y ago
    I think estimates are wrong but useful and necessary. I don’t think it’s a strawman argument at all. For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
    - socksy 2y ago
      I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification. I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand. From The Black Swan by Nassim Taleb: [Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors. I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
      - RHSeeger 2y ago
        > It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification. It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like - Could take anywhere between 2 days and 2 weeks, depending on factors - Has an external dependency on X, and we don't have any insight into when X will be available - May have other external dependencies, but we won't know until we're a few days into the work - Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it - Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions) And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
stetrain 2y ago
There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum https://scrumguides.org/scrum-guide.html#daily-scrum
- vegetablepotpie 2y ago
  There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values. Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
  - stetrain 2y ago
    Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
    - bluGill 2y ago
      There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
      - stetrain 2y ago
        Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile. Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
Pet_Ant 2y ago
The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I got Scrum certified for resume padding, and thought it was gonna be easy, but I was blown away by the things I "knew had to be part of Scrum" that actually weren't. This is all there is to Scrum, if it's not here it's not part of it: https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html It's like calling the electoral college part of democracy. Than just a choice one place made, it's not intrinsic.
- hinkley 2y ago
  It’s an opportunity to call out things four business hours after they happened. We have Slack now. Or Teams. If you’re stuck, tell people. Don’t wait until tomorrow morning.
- RHSeeger 2y ago
  > The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy. [1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
  - JohnFen 2y ago
    > Though the standup does give a place for people that aren't comfortable calling out when they're having issues In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
    - calebio 2y ago
      And then if someone does have a blocker, talking about it needs to be "taken offline", so you already have to do an external sync-up anyway.

prepend 2y ago

I find Agile is like democracy. It does suck, but it’s better than everything else. What would you prefer besides agile? I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.

rightbyte 2y ago
I'd have the straw man variant of waterfall every day in place of agile. Like, the constant micromanagement and process lawyers pushing you down makes me misarable. At least with classic project processes you'd have some oversight plan to follow.
pyrale 2y ago
> I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
- prepend 2y ago
  I think estimates are wrong but useful and necessary. I don’t think it’s a strawman argument at all. For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
  - socksy 2y ago
    I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification. I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand. From The Black Swan by Nassim Taleb: [Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors. I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
    - RHSeeger 2y ago
      > It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification. It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like - Could take anywhere between 2 days and 2 weeks, depending on factors - Has an external dependency on X, and we don't have any insight into when X will be available - May have other external dependencies, but we won't know until we're a few days into the work - Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it - Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions) And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".

stetrain 2y ago

There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum https://scrumguides.org/scrum-guide.html#daily-scrum

vegetablepotpie 2y ago
There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values. Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
- stetrain 2y ago
  Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
  - bluGill 2y ago
    There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
    - stetrain 2y ago
      Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile. Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.

Pet_Ant 2y ago

The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I got Scrum certified for resume padding, and thought it was gonna be easy, but I was blown away by the things I "knew had to be part of Scrum" that actually weren't. This is all there is to Scrum, if it's not here it's not part of it: https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html It's like calling the electoral college part of democracy. Than just a choice one place made, it's not intrinsic.

hinkley 2y ago
It’s an opportunity to call out things four business hours after they happened. We have Slack now. Or Teams. If you’re stuck, tell people. Don’t wait until tomorrow morning.
RHSeeger 2y ago
> The stand-up is an opportunity to call out things that are blocking you, not for giving status updates. I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy. [1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
- JohnFen 2y ago
  > Though the standup does give a place for people that aren't comfortable calling out when they're having issues In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
  - calebio 2y ago
    And then if someone does have a blocker, talking about it needs to be "taken offline", so you already have to do an external sync-up anyway.