5 ms·

> I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I ran a team were we shipped (firmware!) every 3 w

> I have never once seen or heard of any Agile process anywhere actually working with any degree of success. I ran a team were we shipped (firmware!) every 3 weeks. After the first year of tracking all our numbers we were able to hit our estimates within a few hours +/- for the entire team. 3 week sprints, 2 weeks writing code, 1 week testing and bug fixing. It wasn't perfect, and learning how to do it was painful, but once we got going it worked great. We didn't adhere strongly to any one guiding principle, but being able to use sprints to align work across multiple teams, and as a planning mechanism for management was incredibly useful. "Our breakdown of that feature means it'll take 3 sprints in total, the last of those sprints the work is split across 2 devs, if one of those devs gets reassigned it'll take 4 sprints." Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating, and knowing how far to break work down. There is of course a trade off between gains from breaking work down, and time spent doing the breakdown! Several months were rather painful when we went too far one way, and then inevitably the next few months swung too far in the other direction. But in the end? Yeah it all worked out. We figured out what length of sprint worked for us, what type of estimation system to use, and how much work to put into our planning sessions. FWIW one of the huge benefit of doing the work breakdowns is being able to see opportunities to parallelize work, and also to see natural stopping points. My team was lucky to have someone almost full-time dedicated to managing our workflow, without that the entire process wouldn't have been tenable. The tools just suck up too much time.

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?
jay_kyburz 8y ago
> I have never once seen or heard of any Agile process anywhere actually working with any degree of success. We built Bioshock using agile. We didn't use any prescribed agile methodologies like SCRUM, but we developed a process that worked for us based on agile core principles. update: Sorry meant to reply one above.
- mlthoughts2018 8y ago
  I guess it would all hinge on what exactly is meant by “we developed a process that worked for us based on agile core principles.” The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile, even though it may (likely) have nothing to do with anything that could be said to resemble Agile.
  - dragonwriter 8y ago
    > The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile That's more consistent with the Agile Manifesto than calling any of the concrete development methodologies that come out of the Agile community “Agile” merely because they emerge from that community. Choosing the process that works in practice for your team in their concrete situation is pretty much the whole of the Agile Manifesto. The failure of the Agile community is that it has almost no literature or body of knowledge oriented toward how you do that, just a bunch of concrete development practices without tools for adapting them or choosing among them. OTOH, tools operationalizing essentially the values of the Agile Manifesto do exist in the Lean community. (Which is why I sometimes, when feeling particularly snarky, call Lean “Agile, but for engineers” or “Agile, but usable”.)
    - mlthoughts2018 8y ago
      If this is true, it means Agile has no definition, it’s a vacuous term. If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. It reminds me of a great LessWrong quote, “If you can explain every outcome equally well, you have zero knowledge.”
LoSboccacc 8y ago
> Our breakdown of that feature > actually plan sounds like waterfall with extra steps (like a lot of corporate agile)
- egwor 8y ago
  Breaking down features into smaller chunks isn't waterfall. There seems to be some confusion that there are two ways of delivering: agile vs waterfall and if it isn't one then it is the other. Waterfall is about the set of phases and the staggered project transitions. See https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model Agile software development is about 'advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change'. See https://en.wikipedia.org/wiki/Agile_software_development https://en.wikipedia.org/wiki/Agile_software_development For a very large feature, agile deliveries will split that larger feature into chunks and deliver those. That reduces risk and can get feedback ('adapt') to how that 'chunk' has gone. Edited for grammar.
  - AstralStorm 8y ago
    There is one problem in that the design, vision or story (high level requirement) can get lost in all of this. This is how many agile projects end up, doing churn instead of satisfying the user more with every iteration. Typically this results in a mishmash and never finishing. (instead the thing is dropped) Bioshock itself still has game breaking bugs nobody will ever fix - and its story wasn't too iterative. The process is not immune to building the wrong thing at all - devs always want to side with easier vs better and agile pushes them even more by forcing things to be independently chunked...

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?

jay_kyburz 8y ago

> I have never once seen or heard of any Agile process anywhere actually working with any degree of success. We built Bioshock using agile. We didn't use any prescribed agile methodologies like SCRUM, but we developed a process that worked for us based on agile core principles. update: Sorry meant to reply one above.

mlthoughts2018 8y ago
I guess it would all hinge on what exactly is meant by “we developed a process that worked for us based on agile core principles.” The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile, even though it may (likely) have nothing to do with anything that could be said to resemble Agile.
- dragonwriter 8y ago
  > The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile That's more consistent with the Agile Manifesto than calling any of the concrete development methodologies that come out of the Agile community “Agile” merely because they emerge from that community. Choosing the process that works in practice for your team in their concrete situation is pretty much the whole of the Agile Manifesto. The failure of the Agile community is that it has almost no literature or body of knowledge oriented toward how you do that, just a bunch of concrete development practices without tools for adapting them or choosing among them. OTOH, tools operationalizing essentially the values of the Agile Manifesto do exist in the Lean community. (Which is why I sometimes, when feeling particularly snarky, call Lean “Agile, but for engineers” or “Agile, but usable”.)
  - mlthoughts2018 8y ago
    If this is true, it means Agile has no definition, it’s a vacuous term. If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work. It reminds me of a great LessWrong quote, “If you can explain every outcome equally well, you have zero knowledge.”

LoSboccacc 8y ago

> Our breakdown of that feature > actually plan sounds like waterfall with extra steps (like a lot of corporate agile)

egwor 8y ago
Breaking down features into smaller chunks isn't waterfall. There seems to be some confusion that there are two ways of delivering: agile vs waterfall and if it isn't one then it is the other. Waterfall is about the set of phases and the staggered project transitions. See https://en.wikipedia.org/wiki/Waterfall_model https://en.wikipedia.org/wiki/Waterfall_model Agile software development is about 'advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change'. See https://en.wikipedia.org/wiki/Agile_software_development https://en.wikipedia.org/wiki/Agile_software_development For a very large feature, agile deliveries will split that larger feature into chunks and deliver those. That reduces risk and can get feedback ('adapt') to how that 'chunk' has gone. Edited for grammar.
- AstralStorm 8y ago
  There is one problem in that the design, vision or story (high level requirement) can get lost in all of this. This is how many agile projects end up, doing churn instead of satisfying the user more with every iteration. Typically this results in a mishmash and never finishing. (instead the thing is dropped) Bioshock itself still has game breaking bugs nobody will ever fix - and its story wasn't too iterative. The process is not immune to building the wrong thing at all - devs always want to side with easier vs better and agile pushes them even more by forcing things to be independently chunked...