6 ms·

The solution you described is basically agile, and that definitely includes estimates and deadlines.

by bpt3 11mo ago

Mtinie 11mo ago
It’s Agile philosophically, and how it should be. But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.”
- bpt3 11mo ago
  Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario.
  - collingreen 11mo ago
    I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
    - bpt3 11mo ago
      Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed. There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point. One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.
      - kragen 11mo ago
        If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software? I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".
        bpt3 11mo ago
        So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel? That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.
        collingreen 11mo ago
        You just keep saying things are absurd or obvious but not putting anything behind it. I hope this isn't a semantics game where things like "1 - 6 months" counts as an estimate in this context. The point way back up this thread was accurate timelines for complicated, novel work have large error bars but those error bars aren't as bad as the equivalent error bars on estimating whatever "return" it is being pitted against.
        bpt3 11mo ago
        I wouldn't consider something like "1-6 months" as a valid estimate, as that would indicate there is too much uncertainty and it needs to be broken down into subtasks that can be estimated with much less variance. I've written what is probably several pages now in response to two individuals who are redefining terms in order to play the exact semantic games you mentioned, but in order to claim no estimation of any sort needs to be done. We seem to be done talking past each other now that I explicitly pointed out their usage of non-standard terms and my suspicions of why (having also unfortunately lived through software development managed by Gantt chart and other unpleasant experiences where someone who had no idea what they were managing was in control of a project), which is fine with me. Feel free to describe your experience in practice when working in an organization where software developers answer to no one but themselves and are never asked for any justification for their progress or any projections of when they will be finished (both of which would require estimation to provide). If you are able to tell stakeholders something like you'll be done in 1-6 months or provide no insight at all into when your tasking will be done, do no tracking of progress internally, and perform no collaboration around the completion of synchronous tasks within your team, I'll acknowledge no estimation is taking place during that process.
  - wpietri 11mo ago
    I have had many successful projects where we spent approximately zero time on estimates. The fact that a successful approach is culturally seen as illegitimate to even talk about is a great example of why I wrote that last paragraph.
    - awesome_dude 11mo ago
      Whenever there are constraints (money, time, resources) there are going to be estimates and prioritisation. You might be speaking a little more broadly than I am interpreting.
      - wpietri 11mo ago
        On the contrary, constraints often mean you don't need formal estimates. (I'll come back to prioritization in a sec.) Startups are a great example. When you raise your first chunk of money, the size of that isn't really driven by a carefully considered, detailed plan with engineering hours estimated per task. What you get is basically determined what's currently fashionable among angels and small-end VCs, plus who's doing your fundraising. (If you're Jeffery Katzenberg and Meg Whitman, you can raise $1bn. [1] https://en.wikipedia.org/wiki/Quibi https://en.wikipedia.org/wiki/Quibi But the rest of us have to make do with what we can get.) So at that point you have a strong constraint (whatever you raised) and some relatively clear goal. As I said, cost isn't nearly as relevant as ROI, and nobody can put real numbers on the R in a startup. At that point you have two choices. One is just to build to whatever the CEO (or some set of HiPPOs wants). Then you launch and find out whether or not you're fucked. The other is to take something akin to the Lean Startup approach, where you iteratively chase your goal, testing product and marketing hypotheses by shipping early and often. In that later context, are people making intuitive ROI judgments? Absolutely. Every thing you try has people doing what you could casually call estimating. But does that require an estimation practice, where engineers carefully examine the work and produce numbers? Not at all. Again, I've done it many times. Especially in a startup context, the effort required for estimation is much better put into maximizing learning per unit of spending. And how do you do that? Relentless prioritization. I was once part of a team that was so good at it that they launched with no login system. Initial users just typed their names in text fields. They wanted proper auth, and eventually they built it, but for demonstrating traction and raising money there were higher priorities. It worked out for them; they built up to have millions of users and were eventually acquired for tens of millions. On very little investor money. Being great at prioritization makes estimation way less necessary. The units of work get small enough that the law of large numbers is on your side. And the amount of learning gained from the things released change both the R and I numbers frequently enough that formal estimates don't have a long shelf life. So I get what you're saying in theory, but I'm telling you in practice it's different. [1] https://en.wikipedia.org/wiki/Quibi https://en.wikipedia.org/wiki/Quibi
wild_egg 11mo ago
I missed that part of the manifesto
- wpietri 11mo ago
  Right? For those who want to check, the four values: https://agilemanifesto.org/ https://agilemanifesto.org/ And the 12 principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html But to my dismay, the Agile world quickly got colonized by certification schemes and consultants targeting large companies, so it rapidly turned into something that a lot of the early people were very disappointed with. I wrote about the dynamic some years back: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
  - bpt3 11mo ago
    How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development.
    - wpietri 11mo ago
      I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio.
mpyne 11mo ago
There are agile methods that forgo estimates and deadlines though This is what "agile" is: https://agilemanifesto.org/ https://agilemanifesto.org/ More specific methodologies that say they are agile may use concepts like estimates (story points or time or whatever), but even with Scrum I've never run into a Scrum-imposed "deadline". In Scrum the sprint ends, yes, but sprints often end without hitting all the sprint goals and that, in conjunction with whatever you were able to deliver, just informs your backlog for the next sprint. Real "hard" deadlines are usually imposed by the business stakeholders. But with agile methods the thing they try to do most of all isn't manage deadlines, but maximize pace at which you can understand and solve a relevant business problem. That can often be just as well done by iteratively shipping and adjusting at high velocity, but without a lot of time spent on estimates or calendar management.
- bpt3 11mo ago
  Yes, people keep linking to the agile manifesto as if it's some sort of amulet protecting software developers from any sort of accountability or responsibility for their work product in a professional setting. It seems like you acknowledge some amount of estimating is needed and I agree that there is an overemphasis on estimation in many places, but I'll ask you the same thing I asked others, which is: How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
  - wpietri 11mo ago
    I addressed the rest elsewhere, but done well a lack of estimates makes people more accountable. If I am shipping something every week (or as is common for my teams, more often), stakeholders can directly evaluate progress. There's no snowing them with paperwork and claims of progress against semi-fictional documents. They see what they see, they try it out, they watch people use it. The reality of use is what we in software are ultimately accountable to, and that's what I am suggesting people optimize for. Closing that feedback loop early and often builds stakeholder trust such that they stop asking for elaborate fantasy plans and estimates.
wpietri 11mo ago
I can say with some confidence, having been involved in the movement since before the term "Agile" was coined, that it requires neither. I grant that both of those are common, but that's because the median "Agile" implementation quickly devolved into mini-Waterfall with more hip names.

The solution you described is basically agile, and that definitely includes estimates and deadlines.

by bpt3 11mo ago

The solution you described is basically agile, and that definitely includes estimates and deadlines.

Mtinie 11mo ago

It’s Agile philosophically, and how it should be. But that is rarely how it works. In the dozens of different projects across ten or twelve companies I’ve had insight into, “doing Agile” is analogous with “we have a scrum master, hold stand ups, and schedule iterations” while the simple reality is “Agilefall.”

bpt3 11mo ago
Agreed, but the parent poster said that estimates shouldn't be done at all, which is not a legitimate argument to make in any scenario.
- collingreen 11mo ago
  I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
  - bpt3 11mo ago
    Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed. There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point. One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.
    - kragen 11mo ago
      If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software? I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".
      - bpt3 11mo ago
        So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel? That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.
        collingreen 11mo ago
        You just keep saying things are absurd or obvious but not putting anything behind it. I hope this isn't a semantics game where things like "1 - 6 months" counts as an estimate in this context. The point way back up this thread was accurate timelines for complicated, novel work have large error bars but those error bars aren't as bad as the equivalent error bars on estimating whatever "return" it is being pitted against.
        bpt3 11mo ago
        I wouldn't consider something like "1-6 months" as a valid estimate, as that would indicate there is too much uncertainty and it needs to be broken down into subtasks that can be estimated with much less variance. I've written what is probably several pages now in response to two individuals who are redefining terms in order to play the exact semantic games you mentioned, but in order to claim no estimation of any sort needs to be done. We seem to be done talking past each other now that I explicitly pointed out their usage of non-standard terms and my suspicions of why (having also unfortunately lived through software development managed by Gantt chart and other unpleasant experiences where someone who had no idea what they were managing was in control of a project), which is fine with me. Feel free to describe your experience in practice when working in an organization where software developers answer to no one but themselves and are never asked for any justification for their progress or any projections of when they will be finished (both of which would require estimation to provide). If you are able to tell stakeholders something like you'll be done in 1-6 months or provide no insight at all into when your tasking will be done, do no tracking of progress internally, and perform no collaboration around the completion of synchronous tasks within your team, I'll acknowledge no estimation is taking place during that process.
- wpietri 11mo ago
  I have had many successful projects where we spent approximately zero time on estimates. The fact that a successful approach is culturally seen as illegitimate to even talk about is a great example of why I wrote that last paragraph.
  - awesome_dude 11mo ago
    Whenever there are constraints (money, time, resources) there are going to be estimates and prioritisation. You might be speaking a little more broadly than I am interpreting.
    - wpietri 11mo ago
      On the contrary, constraints often mean you don't need formal estimates. (I'll come back to prioritization in a sec.) Startups are a great example. When you raise your first chunk of money, the size of that isn't really driven by a carefully considered, detailed plan with engineering hours estimated per task. What you get is basically determined what's currently fashionable among angels and small-end VCs, plus who's doing your fundraising. (If you're Jeffery Katzenberg and Meg Whitman, you can raise $1bn. [1] https://en.wikipedia.org/wiki/Quibi https://en.wikipedia.org/wiki/Quibi But the rest of us have to make do with what we can get.) So at that point you have a strong constraint (whatever you raised) and some relatively clear goal. As I said, cost isn't nearly as relevant as ROI, and nobody can put real numbers on the R in a startup. At that point you have two choices. One is just to build to whatever the CEO (or some set of HiPPOs wants). Then you launch and find out whether or not you're fucked. The other is to take something akin to the Lean Startup approach, where you iteratively chase your goal, testing product and marketing hypotheses by shipping early and often. In that later context, are people making intuitive ROI judgments? Absolutely. Every thing you try has people doing what you could casually call estimating. But does that require an estimation practice, where engineers carefully examine the work and produce numbers? Not at all. Again, I've done it many times. Especially in a startup context, the effort required for estimation is much better put into maximizing learning per unit of spending. And how do you do that? Relentless prioritization. I was once part of a team that was so good at it that they launched with no login system. Initial users just typed their names in text fields. They wanted proper auth, and eventually they built it, but for demonstrating traction and raising money there were higher priorities. It worked out for them; they built up to have millions of users and were eventually acquired for tens of millions. On very little investor money. Being great at prioritization makes estimation way less necessary. The units of work get small enough that the law of large numbers is on your side. And the amount of learning gained from the things released change both the R and I numbers frequently enough that formal estimates don't have a long shelf life. So I get what you're saying in theory, but I'm telling you in practice it's different. [1] https://en.wikipedia.org/wiki/Quibi https://en.wikipedia.org/wiki/Quibi

wild_egg 11mo ago

I missed that part of the manifesto

wpietri 11mo ago
Right? For those who want to check, the four values: https://agilemanifesto.org/ https://agilemanifesto.org/ And the 12 principles: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html But to my dismay, the Agile world quickly got colonized by certification schemes and consultants targeting large companies, so it rapidly turned into something that a lot of the early people were very disappointed with. I wrote about the dynamic some years back: https://williampietri.com/writing/2011/agiles-second-chasm-and-how-we-fell-in/ https://williampietri.com/writing/2011/agiles-second-chasm-a...
- bpt3 11mo ago
  How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development.
  - wpietri 11mo ago
    I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio.

mpyne 11mo ago

There are agile methods that forgo estimates and deadlines though This is what "agile" is: https://agilemanifesto.org/ https://agilemanifesto.org/ More specific methodologies that say they are agile may use concepts like estimates (story points or time or whatever), but even with Scrum I've never run into a Scrum-imposed "deadline". In Scrum the sprint ends, yes, but sprints often end without hitting all the sprint goals and that, in conjunction with whatever you were able to deliver, just informs your backlog for the next sprint. Real "hard" deadlines are usually imposed by the business stakeholders. But with agile methods the thing they try to do most of all isn't manage deadlines, but maximize pace at which you can understand and solve a relevant business problem. That can often be just as well done by iteratively shipping and adjusting at high velocity, but without a lot of time spent on estimates or calendar management.

bpt3 11mo ago
Yes, people keep linking to the agile manifesto as if it's some sort of amulet protecting software developers from any sort of accountability or responsibility for their work product in a professional setting. It seems like you acknowledge some amount of estimating is needed and I agree that there is an overemphasis on estimation in many places, but I'll ask you the same thing I asked others, which is: How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
- wpietri 11mo ago
  I addressed the rest elsewhere, but done well a lack of estimates makes people more accountable. If I am shipping something every week (or as is common for my teams, more often), stakeholders can directly evaluate progress. There's no snowing them with paperwork and claims of progress against semi-fictional documents. They see what they see, they try it out, they watch people use it. The reality of use is what we in software are ultimately accountable to, and that's what I am suggesting people optimize for. Closing that feedback loop early and often builds stakeholder trust such that they stop asking for elaborate fantasy plans and estimates.

wpietri 11mo ago

I can say with some confidence, having been involved in the movement since before the term "Agile" was coined, that it requires neither. I grant that both of those are common, but that's because the median "Agile" implementation quickly devolved into mini-Waterfall with more hip names.