3 ms·

> [It is a problem that y]ou approved a plan to have a refactor that lasts several weeks. I've been working at an Agile(TM) "prefer communication to processes"

> [It is a problem that y]ou approved a plan to have a refactor that lasts several weeks. I've been working at an Agile(TM) "prefer communication to processes" shop for a while now. One thing that they absolutely do _not_ understand is that sometimes the smallest unit of work cannot and can never fit into a one (or even two) week Sprint. If someone comes and says "This project will take a long time.", yeah, sure, sit down and have them explain why. Do _not_ shoot them down as a matter of course because "Well, nothing should take more than a week, and _definitely_ never than two." and tell them "Go mutilate your plan so that you have a Real Deliverable every five working days.". > You tremendously overestimated the required effort... a) Neither of us know how long the entire project ran, so "A few weeks" could be a small overestimate, and evidence that a sane amount of cushion was baked into the planning. b) It's way, way, way better to overestimate a fair bit and come in under that estimate than it is to underestimate and _require_ either rescheduling a whole bunch of shit, or mutilating a solid plan in order to shove it out in the original timeframe.

hbrn 4y ago
> Go mutilate your plan so that you have a Real Deliverable every five working days If we're talking about web development - yeah, pretty much. IME, most projects where team lead was not willing to "mutilate" were a disaster. > Neither of us know how long the entire project ran, so "A few weeks" could be a small overestimate Are you saying changing state handling (whatever this means) in a young startup could take several months? If that's the case, they definitely should not be teaching how to move fast.
- simoncion 4y ago
  > ...most projects where team lead was not willing to "mutilate" were a disaster. It seems like you agree that my core statement ("sometimes the smallest unit of work cannot and can never fit into a one (or even two) week Sprint") is correct, but are unwilling to explicitly say so. > Are you saying changing state handling... I'm saying that neither you nor I have the details required to understand the minimum time required for the project. You've said yourself that you have experience with tasks that have justifiably run longer than a work-week. So, it's clear that -given more information about the task- you could be convinced that the time estimate is a reasonable estimate of the time required.

hbrn 4y ago

> Go mutilate your plan so that you have a Real Deliverable every five working days If we're talking about web development - yeah, pretty much. IME, most projects where team lead was not willing to "mutilate" were a disaster. > Neither of us know how long the entire project ran, so "A few weeks" could be a small overestimate Are you saying changing state handling (whatever this means) in a young startup could take several months? If that's the case, they definitely should not be teaching how to move fast.

simoncion 4y ago
> ...most projects where team lead was not willing to "mutilate" were a disaster. It seems like you agree that my core statement ("sometimes the smallest unit of work cannot and can never fit into a one (or even two) week Sprint") is correct, but are unwilling to explicitly say so. > Are you saying changing state handling... I'm saying that neither you nor I have the details required to understand the minimum time required for the project. You've said yourself that you have experience with tasks that have justifiably run longer than a work-week. So, it's clear that -given more information about the task- you could be convinced that the time estimate is a reasonable estimate of the time required.