7 ms·

I'm not really sure what to make of this article, it says itself it's a study commissioned by promoters of another methodology. If they're consultants trying to

I'm not really sure what to make of this article, it says itself it's a study commissioned by promoters of another methodology. If they're consultants trying to pitch their consulting services, they need these types of things to sell. But my fundamental reaction is, what does failure mean. Because in my world view failure should be expected and accepted and learned from. It's entirely possible to spend a bunch of time avoiding every possible failure mode, and really not delivery much value at all... but we've successfully avoided the work being considered a failure.

pavel_lishin 2y ago
The article also doesn't go into what kind of software was being produced, etc. If you're building control systems for the ISS, or an interplanetary probe, of course you need requirements hammered out pretty well before you start development; you can't just continually push updates out incrementally. But if you're building Yet Another CRUD App at your startup's third pivot, then getting every requirement written down beforehand is virtually impossible.
fisf 2y ago
> But my fundamental reaction is, what does failure mean. Because in my world view failure should be expected and accepted and learned from. That's fine in some domains. It's not acceptable in others (i.e. you cannot just try things and see if they stick). But regardless of that, you still want to minimize failure. So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue.
- trickstra 2y ago
  Agile is about reacting to changing requirements. If the requirements never change, then agile doesn't promise to be better than other methodologies. It came from a rapidly changing crashing markets in the .com bubble. How would the other methodologies fare if requirements changed two or three times in the middle of the project? That's when you need to be agile. How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?
  - tsunamifury 2y ago
    I mean you are entirely discounting that it also allows engineers to pick their tasks and pace them as they see fit, as well as have input into the creation and prioritization of those tasks. Everytime I hear an engineer complain about this, I ask them if you wish the PM would just write a PRD full of guesswork tasks and you execute on them unquestioningly.
    - trickstra 2y ago
      Some engineers complain about having the ability to pick their tasks and have input in prioritization and planning? This has always been the most attractive part of agile for me. Self-organized team. Built around motivated individuals. Striving for technical excellence.
      - tsunamifury 2y ago
        In forums almost every engineer that complains about agile to me then goes on to describe a deeply regimented waterfall system they are actually in. The second common complaint is “I don’t want to do the hard work of giving input, just tell me what to code”.
        trickstra 2y ago
        This is why I hire students. I have to teach them my way before some other company ruins them forever.
    - chownie 2y ago
      I have never worked in an agile setup in which engineers pick tasks, we're given a queue and we take them in priority order with no room for choice. How common is that really?
      - brigandish 2y ago
        That sounds like Lean.
- adastra22 2y ago
  > It's not acceptable in others (i.e. you cannot just try things and see if they stick). Why not? > So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue That is an incorrect characterization of Agile. Maybe some "agile" companies use it as an excuse to avoid requirements, but that is definitely not part of the process.
  - fisf 2y ago
    > Why not? If you fulfill the role of a supplier of a component in a bigger product (especially in an industrial setting), you cannot "try to build something". People are not happy if you tell them that you want to iterate on their control system and deliver incremental value, or tell them that it's not possible in the contractually agreed way. > That is an incorrect characterization of Agile. These are also the cases where you just have to work out overarching requirements upfront.
    - adastra22 2y ago
      Ah, fair. This is a startup site so my mind was on organization that have the freedom to pivot. It is supposed to be that new requirements come from the customer though, working closely in conjunction with engineering team reps. So it’s more like “deliver MVP control system software, test it out with actual users, then incorporate their requested changes into the next sprint.” I’m not surprised if most so-called agile teams didn’t do that though.
      - fisf 2y ago
        Yes, that's possible for product development in a startup (even necessary, because you don't know what you need to build), and in web dev, end user facing apps,... For many other domains, the full incremental / Agile loop is not possible, and becomes disaster if it results in skipping upfront planning: The counterparts you need to integrate with are often not done yet. Maybe the hardware is not finalized. The end user is years away. Maybe each test run is hugely expensive. There is no MVP here, as in the system works as expected or it doesn't. You cannot meaningfully iterate the core software running an MRI machine, a surgical system, financial clearing, pick-and-place machines, automatic rail protection, etc. towards correctness with the end user.
- The_Colonel 2y ago
  Projects with fixed, clear and unambiguous requirements (and the necessary counterpart - fixed budget) I worked on typically turned into a nightmare, because they were not actually fixed, clear and unambiguous. You could pretend everything was fine for like 80% of the allocated time, the next 80% were spent in bickering over possible interpretation of some not-so-unambiguous line in the spec, death marches, blaming each other (client and supplier, but unfortunately also within the company). The main innovation of agile is showing failures early and thus being able to quickly react and correct course, meanwhile in the waterfall the project spent most the time in a quantum superposition without possibility for correction.
- brigandish 2y ago
  > So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront Fundamental to agile is to have clear requirements, the time is not fixed. With reference to the quality (scope), time, and cost triangle, each of the major methods picks one point to emphasise, another to fix (not allow to change), and another it manages the change of. Agile wants speed so time is its emphasis, it does that by fixing cost (over a release period) and allowing changing scope, and it does that by limiting the features that go into a release. That doesn't mean that the features required should be unclear. I will deliver these 5 features out of 30 in the next 2 weeks at X dollars. If one of the features isn't ready, we'll drop it. No, I'm not doing features 6,7,8 till later. Yes, you can change you mind about what you want for later releases. Lean emphasises quality and fixes cost while allowing time to change. You can get your burger for X dollars but you're 5th in the queue, you'll have to wait. Traditional is about predictable cost, it (tries to) fixes time and allows change in quality to remain on budget. If everything goes to plan you should come in on time and on budget but maybe with less features or worse features than you wanted. Of course, we know that traditional done badly produces over-budget, over-time projects that don't do what they were supposed to. It seems that agile methods are being used as cover for bad management because, as this entire thread is evidence of, there is widespread misunderstanding of the basics of project management. If you're going into an "agile" project and the requirements that you have are unclear then you need to kick up a fuss and hold the PM and the product owner to account. They should certainly be clear by the beginning of each sprint.
commandlinefan 2y ago
> what does failure mean I've been reading that 50+% of software projects "fail" ever since I started programming in 1992 (long before the term "agile" crept into our lexicon). They consistently fail because they consistently have deadlines but no actual definitions. That was true before Agile, was true during Agile, and will be true after Agile.
- ultrasaurus 2y ago
  I sometimes wonder if our definition of failure is flexible and moves so that half-ish of projects are below average thus failures. I once had to do a post-mortem on why a project went 5% over schedule -- that's a pretty soft definition of failure.
rawgabbit 2y ago
This is the issue of agile. It is a blanket prescription for every scenario which of course … fails. If you are talking about customer expectations, yes, you can manage customer expectations. As long as you are honest and upfront, customers tend to be forgiving. On the other hand, if you are talking about a core API or building block that downstream APIs will depend on, then no. You can't deliver a API that writes to the database/storage layer that only works 90% of the time.
signal 2y ago
- Based on a random survey of software engineers (who somehow had visibility to project inception & outcome) - Doesn't define project - Success was defined by not violating the iron triangle (so nobody knew what they were saying OR they're working on trivial "projects") - If you read reviews for the book it's totally AI generated nonsense

pavel_lishin 2y ago

The article also doesn't go into what kind of software was being produced, etc. If you're building control systems for the ISS, or an interplanetary probe, of course you need requirements hammered out pretty well before you start development; you can't just continually push updates out incrementally. But if you're building Yet Another CRUD App at your startup's third pivot, then getting every requirement written down beforehand is virtually impossible.

fisf 2y ago

> But my fundamental reaction is, what does failure mean. Because in my world view failure should be expected and accepted and learned from. That's fine in some domains. It's not acceptable in others (i.e. you cannot just try things and see if they stick). But regardless of that, you still want to minimize failure. So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue.

trickstra 2y ago
Agile is about reacting to changing requirements. If the requirements never change, then agile doesn't promise to be better than other methodologies. It came from a rapidly changing crashing markets in the .com bubble. How would the other methodologies fare if requirements changed two or three times in the middle of the project? That's when you need to be agile. How did they even measure "success" if the requirements weren't given up front? What did they expect at the end?
- tsunamifury 2y ago
  I mean you are entirely discounting that it also allows engineers to pick their tasks and pace them as they see fit, as well as have input into the creation and prioritization of those tasks. Everytime I hear an engineer complain about this, I ask them if you wish the PM would just write a PRD full of guesswork tasks and you execute on them unquestioningly.
  - trickstra 2y ago
    Some engineers complain about having the ability to pick their tasks and have input in prioritization and planning? This has always been the most attractive part of agile for me. Self-organized team. Built around motivated individuals. Striving for technical excellence.
    - tsunamifury 2y ago
      In forums almost every engineer that complains about agile to me then goes on to describe a deeply regimented waterfall system they are actually in. The second common complaint is “I don’t want to do the hard work of giving input, just tell me what to code”.
      - trickstra 2y ago
        This is why I hire students. I have to teach them my way before some other company ruins them forever.
  - chownie 2y ago
    I have never worked in an agile setup in which engineers pick tasks, we're given a queue and we take them in priority order with no room for choice. How common is that really?
    - brigandish 2y ago
      That sounds like Lean.
adastra22 2y ago
> It's not acceptable in others (i.e. you cannot just try things and see if they stick). Why not? > So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront, and this leads to higher failure rates, this is still an issue That is an incorrect characterization of Agile. Maybe some "agile" companies use it as an excuse to avoid requirements, but that is definitely not part of the process.
- fisf 2y ago
  > Why not? If you fulfill the role of a supplier of a component in a bigger product (especially in an industrial setting), you cannot "try to build something". People are not happy if you tell them that you want to iterate on their control system and deliver incremental value, or tell them that it's not possible in the contractually agreed way. > That is an incorrect characterization of Agile. These are also the cases where you just have to work out overarching requirements upfront.
  - adastra22 2y ago
    Ah, fair. This is a startup site so my mind was on organization that have the freedom to pivot. It is supposed to be that new requirements come from the customer though, working closely in conjunction with engineering team reps. So it’s more like “deliver MVP control system software, test it out with actual users, then incorporate their requested changes into the next sprint.” I’m not surprised if most so-called agile teams didn’t do that though.
    - fisf 2y ago
      Yes, that's possible for product development in a startup (even necessary, because you don't know what you need to build), and in web dev, end user facing apps,... For many other domains, the full incremental / Agile loop is not possible, and becomes disaster if it results in skipping upfront planning: The counterparts you need to integrate with are often not done yet. Maybe the hardware is not finalized. The end user is years away. Maybe each test run is hugely expensive. There is no MVP here, as in the system works as expected or it doesn't. You cannot meaningfully iterate the core software running an MRI machine, a surgical system, financial clearing, pick-and-place machines, automatic rail protection, etc. towards correctness with the end user.
The_Colonel 2y ago
Projects with fixed, clear and unambiguous requirements (and the necessary counterpart - fixed budget) I worked on typically turned into a nightmare, because they were not actually fixed, clear and unambiguous. You could pretend everything was fine for like 80% of the allocated time, the next 80% were spent in bickering over possible interpretation of some not-so-unambiguous line in the spec, death marches, blaming each other (client and supplier, but unfortunately also within the company). The main innovation of agile is showing failures early and thus being able to quickly react and correct course, meanwhile in the waterfall the project spent most the time in a quantum superposition without possibility for correction.
brigandish 2y ago
> So if one methodology (Agile) pushes to spend less time on fixed and clear requirements upfront Fundamental to agile is to have clear requirements, the time is not fixed. With reference to the quality (scope), time, and cost triangle, each of the major methods picks one point to emphasise, another to fix (not allow to change), and another it manages the change of. Agile wants speed so time is its emphasis, it does that by fixing cost (over a release period) and allowing changing scope, and it does that by limiting the features that go into a release. That doesn't mean that the features required should be unclear. I will deliver these 5 features out of 30 in the next 2 weeks at X dollars. If one of the features isn't ready, we'll drop it. No, I'm not doing features 6,7,8 till later. Yes, you can change you mind about what you want for later releases. Lean emphasises quality and fixes cost while allowing time to change. You can get your burger for X dollars but you're 5th in the queue, you'll have to wait. Traditional is about predictable cost, it (tries to) fixes time and allows change in quality to remain on budget. If everything goes to plan you should come in on time and on budget but maybe with less features or worse features than you wanted. Of course, we know that traditional done badly produces over-budget, over-time projects that don't do what they were supposed to. It seems that agile methods are being used as cover for bad management because, as this entire thread is evidence of, there is widespread misunderstanding of the basics of project management. If you're going into an "agile" project and the requirements that you have are unclear then you need to kick up a fuss and hold the PM and the product owner to account. They should certainly be clear by the beginning of each sprint.

commandlinefan 2y ago

> what does failure mean I've been reading that 50+% of software projects "fail" ever since I started programming in 1992 (long before the term "agile" crept into our lexicon). They consistently fail because they consistently have deadlines but no actual definitions. That was true before Agile, was true during Agile, and will be true after Agile.

ultrasaurus 2y ago
I sometimes wonder if our definition of failure is flexible and moves so that half-ish of projects are below average thus failures. I once had to do a post-mortem on why a project went 5% over schedule -- that's a pretty soft definition of failure.

rawgabbit 2y ago

This is the issue of agile. It is a blanket prescription for every scenario which of course … fails. If you are talking about customer expectations, yes, you can manage customer expectations. As long as you are honest and upfront, customers tend to be forgiving. On the other hand, if you are talking about a core API or building block that downstream APIs will depend on, then no. You can't deliver a API that writes to the database/storage layer that only works 90% of the time.

signal 2y ago

- Based on a random survey of software engineers (who somehow had visibility to project inception & outcome) - Doesn't define project - Success was defined by not violating the iron triangle (so nobody knew what they were saying OR they're working on trivial "projects") - If you read reviews for the book it's totally AI generated nonsense