11 ms·

I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrib

by yebyen 8y ago

I've been reading "It Doesn't Have to be Crazy at Work" and they have a chapter about this. Deadlines are great! Estimates are terrible, and humans are terrible at estimating. Scope needs to be elastic to accommodate this fact of life. If the project is not done in the 6 weeks you set aside for it, just ship something anyways and move on. It was only worth 6 weeks when you planned on getting it done in 6 weeks, so why spend more? Go ahead and plan another sprint if it turns out what you were able to build in the time allocated wasn't enough, and you really need more. (Put it up against the other opportunities you have, and give them all a fair chance at those finite development resources, something else might also turn out to be more important.) Just don't spend forever and drag out the deadline, throwing off the timeline for whatever you had planned to do next, because you needed more time for the thing that underestimated how big it was, so it wasn't really possible to do that whole thing in only 6 weeks. The release that is reduced in scope might be totally insufficient, or, it might be just what your users needed! The knife also cuts both ways – if you're willing to accept that project scope can change in either direction, you can occasionally deliver things early too. I really like everything about this book.

TheOtherHobbes 8y ago
If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.
- jdmichal 8y ago
  You can also use modeling, which for a bunch of STEM people seems to almost never come up. Take projects you've done, do Monte Carlo simulations, and then start giving estimates with confidence bounds. Can also use things like Little's Law to determine lead times.
  - coldtea 8y ago
    That only works if you regularly get similar projects. Throw a new type of project or a new client with special needs, and bets are off, Monte Carlo or not.
    - jdmichal 8y ago
      Yea I've been down this discussion path before. I'll just refer you there, and you can feel free to chime in with any new thoughts. My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. https://news.ycombinator.com/item?id=17765399 https://news.ycombinator.com/item?id=17765399
      - coldtea 8y ago
        >My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. I really doubt that. In construction for example, tolerances, materials, requirements, etc are know well before even a single brick has been laid, and if they are to even consider changing them mid-construction, detailed new plans about everything that changed is in process. That's almost never the case with software requirements. The same tools, processes and technologies are also used for decades or in some cases centuries totally unchanged. In software a domain (e.g. web programming) can be completely different every 5-10 years.
- yebyen 8y ago
  It's not that we estimated 6 weeks and it takes 12. It's that we get a bundle of tasks up-front and are told "it's going to take 6 weeks" for reasons that are negotiated at a higher level than our pay-grade. It's my situation anyway. The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...) What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have." Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us. And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?) T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning. Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer. We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.) The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.
deleted 8y ago
[deleted]

by yebyen 8y ago

TheOtherHobbes 8y ago

If you set aside 6 weeks and it takes 12, you suck at estimating. Not only are you likely to ship a broken product, but you also have no way of making intelligent business decisions about possible projects. Project A will bring in $X. You estimate 6 weeks. It takes 12. Project B will bring in $Y. You estimate 6 weeks. It takes 7. If X is similar to Y and you bet on the wrong horse, you've dented and/or sunk your cash flow for no reason. Saying "Humans suck at estimating" is nonsense. It's a skill that can easily be improved - usually at the cost of some up front planning - and there are plenty of resources to help you with that. The real problem with Agile is that it gives management an excuse to do no estimation at all. Some alpha-wannabe manager bangs their fist on a desk and says "I want this in three weeks". Instead of saying "You're insane" teams are pressured into trying to make up for someone else's laziness and lack of contact with reality.

jdmichal 8y ago
You can also use modeling, which for a bunch of STEM people seems to almost never come up. Take projects you've done, do Monte Carlo simulations, and then start giving estimates with confidence bounds. Can also use things like Little's Law to determine lead times.
- coldtea 8y ago
  That only works if you regularly get similar projects. Throw a new type of project or a new client with special needs, and bets are off, Monte Carlo or not.
  - jdmichal 8y ago
    Yea I've been down this discussion path before. I'll just refer you there, and you can feel free to chime in with any new thoughts. My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. https://news.ycombinator.com/item?id=17765399 https://news.ycombinator.com/item?id=17765399
    - coldtea 8y ago
      >My general thoughts is that typical software engineering does not have drastically more degrees of project uniqueness than other engineering fields. I really doubt that. In construction for example, tolerances, materials, requirements, etc are know well before even a single brick has been laid, and if they are to even consider changing them mid-construction, detailed new plans about everything that changed is in process. That's almost never the case with software requirements. The same tools, processes and technologies are also used for decades or in some cases centuries totally unchanged. In software a domain (e.g. web programming) can be completely different every 5-10 years.
yebyen 8y ago
It's not that we estimated 6 weeks and it takes 12. It's that we get a bundle of tasks up-front and are told "it's going to take 6 weeks" for reasons that are negotiated at a higher level than our pay-grade. It's my situation anyway. The core idea I took out of Agile is that once the high-level estimates are completed, the developers are meant to break them down into bite-sized tasks, put estimates on those, and prioritize them in a backlog with the project manager, customers, and any stakeholders. (In my case we're not building products to go to market with, I work in Higher Ed. We're building solutions for campus partners. So it's not really "Project B will bring in $Y," it's "Project will further our mission and better enable some common workflow." Not to go off-topic...) What's happening instead is, we get the high-level tasks and then break the projects down into bite-sized chunks, then estimate the parts, and are told "great, now make that fit into 6 weeks, because that's all you have." Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating. It's not what you pay us to do. (I mean this honestly, it's really not. This is what they pay project managers to do, and they're literally a pay-grade above us. And they don't write code, though they may be good at math and judging t-shirt sizes. The better ones also know how to keep their poker face, when meeting with the customers. But if your project is slated to last only 6 weeks, chances are you won't even have access to a PM. You wouldn't want one if you could get one, since 6 weeks is hardly enough time to plan and later change course. What would they do?) T-shirt sizes are better than estimates at a sprint level too, because all you're really doing is horse-trading. If a feature is XXL according to the devs, maybe it moves to the back of the queue in favor of something that costs less and is worth more. That's what you do at Sprint Planning. Back to devs, we're experts at writing the features, and sometimes we can tell you how long it's going to take and get that right, ... and sometimes we can harmonize in concert with the project leadership, but that's not our core competency. It's just moving faster, and doing it better. Sometimes you find out that the specs are wrong after the project has already started, and it's going to take longer. We know that some projects are going to take a year, and some are going to take two. And those projects get project managers, and they are frequently delivered on time, with all of the promised features in them! Six weeks isn't an estimate, it's a budget. (And it's not a real budget, hardly even registers on the balance sheet. It's more like an experimental timeline.) The problem is, customers prefer that we blow the budget rather than delivering part of a product on-time, even if it might have turned out to be enough. They're not willing to put things in order of priority, take an honest look at what will take 6 weeks to deliver, and settle for that. They'd rather cut corners, and then we allow them to make those concessions. Only they don't really want concessions, so we wind up having to spend extra time papering over the gaps.

deleted 8y ago

[deleted]