3 ms·

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 dev

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>".
    - pie420 2y ago
      There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated. Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development. Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already. Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
  - hinkley 2y ago
    You need to break work up into tasks that take less than two weeks. Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
    - prepend 2y ago
      I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference. I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies. I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
      - hinkley 2y ago
        I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow. And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story. Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please. And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that. Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
      - pyrale 2y ago
        > understanding whether something is one day of work or 10 is a big difference. A big difference for what?

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>".
  - pie420 2y ago
    There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated. Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development. Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already. Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
- hinkley 2y ago
  You need to break work up into tasks that take less than two weeks. Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
  - prepend 2y ago
    I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference. I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies. I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
    - hinkley 2y ago
      I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow. And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story. Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please. And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that. Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
    - pyrale 2y ago
      > understanding whether something is one day of work or 10 is a big difference. A big difference for what?