4 ms·
"The core idea I took out of Agile is that once the high-level estimates are completed..." This is not a core idea of Agile. The high level estimates are not p
by mattmcknight 8y ago
"The core idea I took out of Agile is that once the high-level estimates are completed..."
This is not a core idea of Agile. The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process.
"Developers don't estimate in hours or days, they use points or t-shirt sizes, because honestly, we do suck at estimating."
No, they don't estimate in hours or days because those are commitments that are used against them- regardless of whether they are expected to attend other company meetings or other priorities are thrust upon them. Points or sizes are intended to be complexity or quantity of work estimates, which could take different amount of time.
In addition, estimates, whether of time or complexity, have uncertainty. Many enterprises are unable to deal with uncertainty.
If you fix cost and time as part of the budget, what you are left to be flexible on is scope. This is the most natural place for flexibility, as there is are often a wide variety of implementation choices that limit cost and deliver a low budget version of a feature versus one that would require more time.
- yebyen 8y ago> This is not a core idea of Agile. The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process. In the first edit of this comment, before I submitted it, I said "we don't really do Agile, we do Agile-Lite" – I cut this line because I've heard this repeated by leadership and I've asked what does it mean, and never got an answer. I almost wanted to include it, so maybe I understand now! Developer teams are Agile. Dev leadership is Agile-lite. > The high level estimates are not part of Agile- fixed scope, time, and cost is the opposite of agile. You are just doing extra fake work around what is a fixed design process. Leadership tries to fix scope, time, and cost on the long-term calendar because we want to deliver predictably, to not appear unpredictable or unreliable. As much as I tell upper management that you can't have fixed scope, time, and cost, they persist in trying to fix all of those. And their budgets and goals seem to win over my objections, damn near every time! I'm not doing extra fake work, I'm taking direction from senior leadership. Their work may be fake. Your opinion on their fake work, is duly noted, and I'm going to decline to state whether I agree for political reasons (in so many words, I like my boss and I rarely get time of my own to interact with the bosses boss.) I try to do my work and not rock the boat. Which is why I might get a demand to do something in 6 weeks that is clearly going to take 12, and just do the work. "We'll be given the extra time when we need it." That's healthy, even if it's somewhat dishonest. > No, they don't estimate in hours or days because those are commitments that are used against them- regardless of whether they are expected to attend other company meetings or other priorities are thrust upon them. That's a fact. But at some level, if you have this toxicity in your culture, someone is going to have to translate from t-shirt sizes into hours and weeks at some point, and when these estimates turn out to be wrong, someone's head will have to hit the block. (Hopefully theirs and not ours.) I'd like to think that doesn't actually happen here, and also that's not why we use t-shirt sizes. Maybe just why your team uses them. Or maybe I'm just naive about it.