3 ms·
I’ve used strict versions of agile, as well as a dozen quasi-versions. They were all horrible. Both for managers and ICs. It seems what works the best, as leas
by ryanSrich 5y ago
I’ve used strict versions of agile, as well as a dozen quasi-versions. They were all horrible. Both for managers and ICs.
It seems what works the best, as least for B2B SaaS, is driven more by building a feature that works, instead of trying to hit a date, or stripping the feature down to nothing in order to hit that date.
- Closi 5y agoEh, it's all horses for courses. Sometimes you have to hit a date, sometimes you don't. Sometimes having something is better than nothing, other times unless you have all the functionality it's worthless. Sometimes you can know all the requirements upfront, other times they are ambiguous and require testing and failing. The only way to be wrong is to pick one methodology and apply it to all circumstances. There are times pure agile will work, there are times waterfall will work, and there are times that neither of these are right and you have to do something else.
- UK-Al05 5y agoI mean two of those are agile goals. Hitting a date by striping features, or a feature with fixed scope but no fixed date.
- ryanSrich 5y agoFair enough, but in every instance I’ve encountered agile it’s taken on the methodology of stripping away - “ex: well we can’t build XYZ by date, so we should just aim for X”. Meanwhile, X is essentially useless without Y and Z. I also think setting dates makes things go slower. We don’t use delivery dates at my company. Instead, we have quarterly cycles. Whatever gets done in that cycle gets done. We only aim to deliver one big feature per quarter, but it ends up being 2-3 because we’re so conservative. This also takes the pressure off of releases.
- Zigurd 5y agoLook for "estimates" in The Manifesto for Agile Software Development and the 12 principles. Spoiler alert...