3 ms·

> “Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating” I’m skeptical of this

by mlthoughts2018 8y ago

> “Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating” I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go. But regardless it sounds like your process was fairly different from Agile. The only superficial similarity was having some notion of a regular sprint cadence, but cadence based scheduling is common to many project management strategies. It sounds like you had something very pragmatic for your exact situation, which is great — that’s the whole goal, the very thing Agile paradoxically does not conceptually support.

com2kid 8y ago
> I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go. I usually agree, but we were in a bit of a special situation: 1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for our specific needs It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible! > the very thing Agile paradoxically does not conceptually support. Early on, a few of the more senior engineers wanted everything to be done as one big design up front. That is after all how embedded hardware projects are normally delivered. (And for hardware that makes a lot of sense, lead times are a thing!) The idea of shipping embedded firmware every 3 weeks is considered insane by many people. Heck I think that throughout the industry it is still considered insane. But if we had not pushed for "agile", users would have suffered. They wouldn't have gotten the incredible stream of features that they did, and the teams wouldn't have been forced to maintain constant stability and code quality. That idea of "always ready to ship" is one of the tenants of agile. Of course having milestones is common, but "our code is always good" is not common, and it is one of agile's differentiators and adhering to that leads to systematic changes in how teams function.
- dasmoth 8y ago
  1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for our specific needs It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible! That's an interesting set of observations there. I've been wondering for a while whether we -- as a field -- have been systematically underestimating the cost of using libraries. To my eye, the anecdata definitely seem to be on the side of projects going more smoothly when the dependencies are few and well understood. Does anyone know of anyone doing research into this kind of thing?
  - com2kid 8y ago
    I'd personally say libraries save time in net, but they add unpredictability. Especially for experienced devs who have written framework code before. "How long will it take you to write a graphics rendering routine that you've previously written on another project" is easier to estimate than "does this feature in the graphics library we are using work?" The library probably works, sure, but when it doesn't the problem can become an almost unbounded time sink.
    - dasmoth 8y ago
      Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it). I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.
AnimalMuppet 8y ago
I've worked on an agile team (specifically XP). The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those. Also, XP was very into feedback. "How much did we get done in the last two weeks? How much did we think we were going to get done? Let's use that to adjust our estimates going forward." This was actually done with story points, so that when we "adjusted", the units of estimation stayed the same (that is, an item that was 4 story points before was still 4 story points), but we realized that the team was only doing 12 story points per 2-week sprint, instead of the 20 that we expected. And yes, it worked very well for us, and it was truly agile. And I disagree with you that agile doesn't allow something tuned for your exact situation. Or rather, agile allows that, even if Agile doesn't. We'd sometimes say "For the next two sprints, we're going to tweak our approach in this specific way. If it works, we'll keep doing it that way." That is, our process was one of the parameters we could adjust.
- speedplane 8y ago
  > I've worked on an agile team .... The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those. That's not really all that agile. The agile teams I've worked on try to break things down much smaller, ideally half-days or less. Any estimate of how complex some task is, is often off by a factor of 2, sometimes much more. Only by breaking down tasks into small bits can you really start getting a handle on your velocity and complexity of a project.
  - AstralStorm 8y ago
    Not true at all. Every increment is supposed to be shippable and better quality than the one before. So the chunks cannot be too small or you risk never shipping by never shipping critical functionality that is hard to chunk, or instead you end up with long stretches where software does not work and is not testable. This also ignores the fact that there are evolutionary dead ends and digging yourself out of such a hole is hard.

com2kid 8y ago

> I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go. I usually agree, but we were in a bit of a special situation: 1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for our specific needs It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible! > the very thing Agile paradoxically does not conceptually support. Early on, a few of the more senior engineers wanted everything to be done as one big design up front. That is after all how embedded hardware projects are normally delivered. (And for hardware that makes a lot of sense, lead times are a thing!) The idea of shipping embedded firmware every 3 weeks is considered insane by many people. Heck I think that throughout the industry it is still considered insane. But if we had not pushed for "agile", users would have suffered. They wouldn't have gotten the incredible stream of features that they did, and the teams wouldn't have been forced to maintain constant stability and code quality. That idea of "always ready to ship" is one of the tenants of agile. Of course having milestones is common, but "our code is always good" is not common, and it is one of agile's differentiators and adhering to that leads to systematic changes in how teams function.

dasmoth 8y ago
1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for our specific needs It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible! That's an interesting set of observations there. I've been wondering for a while whether we -- as a field -- have been systematically underestimating the cost of using libraries. To my eye, the anecdata definitely seem to be on the side of projects going more smoothly when the dependencies are few and well understood. Does anyone know of anyone doing research into this kind of thing?
- com2kid 8y ago
  I'd personally say libraries save time in net, but they add unpredictability. Especially for experienced devs who have written framework code before. "How long will it take you to write a graphics rendering routine that you've previously written on another project" is easier to estimate than "does this feature in the graphics library we are using work?" The library probably works, sure, but when it doesn't the problem can become an almost unbounded time sink.
  - dasmoth 8y ago
    Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it). I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.

AnimalMuppet 8y ago

I've worked on an agile team (specifically XP). The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those. Also, XP was very into feedback. "How much did we get done in the last two weeks? How much did we think we were going to get done? Let's use that to adjust our estimates going forward." This was actually done with story points, so that when we "adjusted", the units of estimation stayed the same (that is, an item that was 4 story points before was still 4 story points), but we realized that the team was only doing 12 story points per 2-week sprint, instead of the 20 that we expected. And yes, it worked very well for us, and it was truly agile. And I disagree with you that agile doesn't allow something tuned for your exact situation. Or rather, agile allows that, even if Agile doesn't. We'd sometimes say "For the next two sprints, we're going to tweak our approach in this specific way. If it works, we'll keep doing it that way." That is, our process was one of the parameters we could adjust.

speedplane 8y ago
> I've worked on an agile team .... The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those. That's not really all that agile. The agile teams I've worked on try to break things down much smaller, ideally half-days or less. Any estimate of how complex some task is, is often off by a factor of 2, sometimes much more. Only by breaking down tasks into small bits can you really start getting a handle on your velocity and complexity of a project.
- AstralStorm 8y ago
  Not true at all. Every increment is supposed to be shippable and better quality than the one before. So the chunks cannot be too small or you risk never shipping by never shipping critical functionality that is hard to chunk, or instead you end up with long stretches where software does not work and is not testable. This also ignores the fact that there are evolutionary dead ends and digging yourself out of such a hole is hard.