2 ms·

The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process. If I estimate s

by beat 11y ago

The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process. If I estimate something will take two days, and I'm off by 50%, it'll take three days. If I estimate it'll take two years, and I'm off by 50%, it'll take three years. And because I can get a lot more practice at two day schedules than two year schedules, I'll improve my accuracy over time, through steady practice. This takes us back to the triangle of constraints that Kent Beck talked about in the first Extreme Programming book. There are three constraints on projects - schedule, scope, and resources. You can control two of them. Generally, resources are inflexible. So in practice, projects are either schedule-bound (we must hit this date) or scope-bound (we must have these features). A project that tries to do both, without a significant resource surplus, is probably doomed. Since estimation improves over time with short iterations, it seems better to me to be scope-constrained than schedule-constrained. With steady progress, you can achieve the goals eventually. Good agile processes are much better at saying where you are and where you're going than when you'll get there.

p4wnc6 11y ago
I've never experienced estimation improving over time in an Agile process. In fact, since short estimation cycles are just as susceptible to political games as longer cycles, and this dominates the whole process in any organization, the length of the estimation cycle really has nothing to do with the estimation issue. But, what shorter estimation cycles are responsible for is a decoupling of the overall big picture progress from the immediate tasks being prioritized. This often leads to sprints that are well scoped, and everything in the sprint gets completed close to on time (at least as close as in longer work cycles, but not usually any closer), but, crucially all of the work has to be scrapped because the whole sprint, conceptually, was not right. In my experience, this happens maybe 1/5 of the time in Agile exactly in ways that would be prevented with longer-term planning. It's very similar to the classical fractal effects of measuring the coast of Britain. By refining your ruler, you merely think you're being more accurate, and a lot of people are doing a lot of performative managerial crap for the sake of the Scrum performance, like a ritual. It feels like you are estimating better, but really because the whole meta-level concept you are working on isn't guided by longer-term thinking, you end up having so much round off error, added up over more and more cycles, that the overall waste is colossally greater than systems that involve some more significant longer-term pre-planning and which work on variable cycle lengths instead of a cookie-cutter, one-size-fits-all approach (which is the core philosophy of Agile, though people try to obfuscate this fact by No True Scotsman-ing it with the Agile Principles). I also can't miss the opportunity to point out this great article on the political games we play during estimation: < http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC3... >
- beat 11y ago
  All excellent points. But having done big waterfall, bad corporate agile, and good agile, the problem of work failing conceptually is common to all of them. The question is, how do you recover from it? I think good agile recovers more gracefully from conceptual failures than either waterfall (which tends to throw good money after bad, because admitting failure is not an option), or corporate agile (because corporate agile is usually just buzzword-compliant waterfall).
  - p4wnc6 11y ago
    I'm not saying waterfall is a good alternative. Waterfall is just as shitty as Agile, but one benefit is that wastes less of everyone's time with meetings and busywork. But waterfall is equally guilty of a one-size-fits-all mentality, from the opposite view of Agile, and this cookie-cutter property is what makes both methods attractive to bureaucracies. I'm a fan of common sense. If it's clear in a given team and project context that two week sprints, story points, and frequent meetings are really going to help, then just do it. And when that stops working, just switch and do something else. When architects or researchers are telling you a given project direction needs to slow down for some more intensive piloting research, do it and don't hesitate to violate sacred Scrum principles. This stuff should be figured out organically, based on the given project and given personnel. Never with a fixed mandate to a single prescribed method or time frame.
    - beat 11y ago
      Continuous improvement of the process itself is part of any good agile process. Corporate buzzword compliance agile is often guilty of not doing that - the "cookie-cutter property". But importantly, I've found that a refined agile process saves more work than it costs, by figuring out what doesn't need done before doing it, and prioritizing immediate value over future value. It's very important to be able to say "This is good enough for now, but we know it's not good enough for the future". It keeps the perfect from being the enemy of the good. Likewise, it's important to be able to say "Well, I guess that didn't work", and have it be an integral part of the process. Without process, you have no guidance over what wrong turns you took and what those wrong turns cost.

by beat 11y ago

p4wnc6 11y ago

I've never experienced estimation improving over time in an Agile process. In fact, since short estimation cycles are just as susceptible to political games as longer cycles, and this dominates the whole process in any organization, the length of the estimation cycle really has nothing to do with the estimation issue. But, what shorter estimation cycles are responsible for is a decoupling of the overall big picture progress from the immediate tasks being prioritized. This often leads to sprints that are well scoped, and everything in the sprint gets completed close to on time (at least as close as in longer work cycles, but not usually any closer), but, crucially all of the work has to be scrapped because the whole sprint, conceptually, was not right. In my experience, this happens maybe 1/5 of the time in Agile exactly in ways that would be prevented with longer-term planning. It's very similar to the classical fractal effects of measuring the coast of Britain. By refining your ruler, you merely think you're being more accurate, and a lot of people are doing a lot of performative managerial crap for the sake of the Scrum performance, like a ritual. It feels like you are estimating better, but really because the whole meta-level concept you are working on isn't guided by longer-term thinking, you end up having so much round off error, added up over more and more cycles, that the overall waste is colossally greater than systems that involve some more significant longer-term pre-planning and which work on variable cycle lengths instead of a cookie-cutter, one-size-fits-all approach (which is the core philosophy of Agile, though people try to obfuscate this fact by No True Scotsman-ing it with the Agile Principles). I also can't miss the opportunity to point out this great article on the political games we play during estimation: < http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC3... >

beat 11y ago
All excellent points. But having done big waterfall, bad corporate agile, and good agile, the problem of work failing conceptually is common to all of them. The question is, how do you recover from it? I think good agile recovers more gracefully from conceptual failures than either waterfall (which tends to throw good money after bad, because admitting failure is not an option), or corporate agile (because corporate agile is usually just buzzword-compliant waterfall).
- p4wnc6 11y ago
  I'm not saying waterfall is a good alternative. Waterfall is just as shitty as Agile, but one benefit is that wastes less of everyone's time with meetings and busywork. But waterfall is equally guilty of a one-size-fits-all mentality, from the opposite view of Agile, and this cookie-cutter property is what makes both methods attractive to bureaucracies. I'm a fan of common sense. If it's clear in a given team and project context that two week sprints, story points, and frequent meetings are really going to help, then just do it. And when that stops working, just switch and do something else. When architects or researchers are telling you a given project direction needs to slow down for some more intensive piloting research, do it and don't hesitate to violate sacred Scrum principles. This stuff should be figured out organically, based on the given project and given personnel. Never with a fixed mandate to a single prescribed method or time frame.
  - beat 11y ago
    Continuous improvement of the process itself is part of any good agile process. Corporate buzzword compliance agile is often guilty of not doing that - the "cookie-cutter property". But importantly, I've found that a refined agile process saves more work than it costs, by figuring out what doesn't need done before doing it, and prioritizing immediate value over future value. It's very important to be able to say "This is good enough for now, but we know it's not good enough for the future". It keeps the perfect from being the enemy of the good. Likewise, it's important to be able to say "Well, I guess that didn't work", and have it be an integral part of the process. Without process, you have no guidance over what wrong turns you took and what those wrong turns cost.