7 ms·

> Meet sprint and release commitments consistently: Scrum blabla Aahhahha ok nonsense confirmed I've NEVER seen Scrum work, at any cadence, anywhere, ever, ev

by bedobi 5y ago

> Meet sprint and release commitments consistently: Scrum blabla Aahhahha ok nonsense confirmed I've NEVER seen Scrum work, at any cadence, anywhere, ever, even in shops with good developers, BAs and PMs The list of reasons why is endless but usually boils down to vague requirements, (or clear requirements for what turns out to be the wrong thing, which is basically the same problem) and unrealistic expectations from stakeholders. Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. There's also the fact that bundling all changes over a whole week or two into a single giant release is more or less guaranteed to fail since even a small bug or problem means the whole release has to be rolled back. (even though there was nothing wrong with most of it) Contrast this to continuous releases where every small change is released independently all the time, where, if something breaks, you can likewise just roll back that single small change while letting everyone else carry on as they were and release their stuff whenever it's ready. I could go on

kqr 5y ago
> Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?" If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?" If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?" The discussions get much more productive this way. And I get more information about how valuable the different problems are.

by bedobi 5y ago

kqr 5y ago

> Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?" If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?" If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?" The discussions get much more productive this way. And I get more information about how valuable the different problems are.