3 ms·

> In Big Agile, engineering = new features. I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring th

> In Big Agile, engineering = new features. I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before? Didn't managers before 2001 demand new features for their products? Did they use to empathise more with engineering work? If they hadn't yet learnt about t-shirt sizes, didn't they demand estimates in specific time periods (months, days, hours)? Didn't they make promises based on arbitrary dates and then pressed developers to meet those deadlines, expecting them to work overtime (as can be inferred from agile principle 8: "agile processes promote sustainable development ... Developers should be able to maintain a constant pace indefinitely)? What sins has 'agile' committed, apart from inadvertently unleashing an army of 'scrum masters' who discovered an easy way to game the system and 'break into tech' after taking a two-day course?

bluefirebrand 1y ago
Agile gave managers the idea that any task, no matter how complex, should be able to be broken down enough to fit into a ticket that can be estimated semi-accurately before even looking into the problem, and the work required to complete the ticket can fit into a two week time period
- iliaskurt 1y ago
  comment of the year
- vannevar 1y ago
  I think managers had those kind of ideas way before agile. And if anyone on the team doesn't think a given ticket can be completed within a sprint, they should speak up--the whole point is that the team concurs that X can be done in a sprint, and they collectively decide what X is. Empirically, I'd say in my experience that the sprint velocity has been accurate around 80% of the time. Which is enough to be useful.
  - azangru 1y ago
    I'd just like to point out that the notion of 'sprint', let alone sprint velocity, comes specifically from scrum. Which is just one version of agile software development, albeit the most common one. For example, the arbitrariness of the sprint timebox, as well as the guessing of how much will be done over that time period, are perhaps among its weakest ideas, and have often been criticized.
    - bluefirebrand 1y ago
      I think that at this point people have to let go of "Scrum is not the only way to do Agile" It's "technically" true, and I admit that, but this battle is lost If someone says they are doing Agile they mean Scrum. Otherwise they will specify Kanban (or whatever else) by name I know it's not technically correct, but that's just how it is, sorry
    - vannevar 1y ago
      Fair. But the central idea of scrum is a self-managed team, and there's nothing that says every sprint has to have the same duration, it just makes calculating the velocity easier. There's also nothing that says you can't pause sprints for some unstructured design and experimentation time, something that I think teams do too little of. The problem is that many organizations don't understand the self-managing aspect and simply put a manager in charge of the team and the scrum, which pretty much sabotages things from the start. This micromanagement, along with imposing unrealistic development timelines, are the two biggest mistakes that I commonly see. Neither of them are unique to agile.
- anonymars 1y ago
  I think t-shirt sizing is madness. "How long is a piece of string?" But we've had tickets to create other tickets, because, as you point out, speccing out the feature (including what does it do and what does it not do) is itself a ton of work In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value*? So Amdahl's law says having AI optimize that part isn't going to move the needle all that much *it's certainly possible to expend lots more effort coding, but is it coding in the right direction?
  - bluefirebrand 1y ago
    > In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value Ehh... I've heard this sort of reasoning before and I get where it comes from, but I'm not sure I agree. It feels like "Idea Guy" propaganda to overvalue their contribution. Figuring out what to build doesn't provide real value at all imo. It provides theoretical value. Coding is closer to 100% of the work that actually provides the value Edit: This is why people who actually have skills to build things are made to sign NDAs and Non-competes when hired or before being pitched projects. The ideas people want to keep the value of their idea and undervalue the skill of actually building things
    - anonymars 1y ago
      I am in no way saying "the idea guy" is doing 80% of the work, that's probably less than 10% Put another way -- genuine question to which I have only a guess: who does more coding during an average day? A junior developer or a senior developer? Broadly I'd posit the junior developers do a lot more coding, and the more senior you get the more important "English" becomes over any programming language. Maybe I'm in an aberrant bubble. But I doubt it. > This is why people who actually have skills to build things are made to sign NDAs and Non-competes when hired or before being pitched projects. So what I'm getting at is, my version would be: "this is why senior developers code less than junior developers"
vonneumannstan 1y ago
>I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before? Because it adds hours of nearly pointless meetings to your workweek? The time spent in standups and retros and sprint planning and refinement that imo add nearly no value is shocking...
- azangru 1y ago
  Yes; dysfunctional meetings suck up time. But on the other hand, in a dysfunctional team without meetings, developers do not coordinate their efforts, may not realise what is the most important to do on a given day, do not get a shared understanding of which aspects of their work can be improved, do not know or care about the full picture of the product that they are working on; information, instead of flowing freely between developers, or between teams of developers, or between management and developers, tends to stagnate in silos.
  - vonneumannstan 1y ago
    No one is saying no meetings or no planning. But the amount of required meetings that could be emails necessary in Agile is way over the top.
- vannevar 1y ago
  Then your problem is bad meetings, not agile. If there's truly no value in quick daily updates and occasional work planning/review meetings, it's only because either those things are being done some other way or the team is dysfunctional.
- roryirvine 1y ago
  But that's nothing to do with Agile - after all, any of the big pre-Agile iterative methodologies from the 1990s like RUP or DSDM were just as often plagued with pointless meetings! One of the most important aspects of following an Agile methodology is that teams are expected to be self-organising, so if the meetings you're participating in aren't working for you, you should absolutely be discussing that with your team. It could be that others do find them valuable, but you might well find that they feel the same as you and would be willing to consider how to make them more effective.
hunter-gatherer 1y ago
In short, my experience with Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity. I do see how it is actually useful when talking to managers and investors about progress. However from the engineers' view it is just more of an administrative burden. In my view the "sin" that Agile committed was the promise of productivity, when really (from engineering viewpoints) it appears to be an unnecessary accountability mechanism. I worked in fiance once with Agile, where there exists in the culture an infinite growth mindset. So I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. Some companies probably don't suffer from this though.
- deleted 1y ago
  [deleted]
- azangru 1y ago
  > Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity > ... > I worked in fiance once with Agile ... I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. It's fascinating to me how different a meaning different people put into the word 'agile'. The 'agile' of the founders was about small teams, close collaboration with the customer, and frequent feedback based on the real emerging working software, which allowed the customer to adapt and change their mind early (hence 'agile', as in 'flexible'). What it contrasted itself to was heavy, slow-moving organisations, with large interdependent teams, multiple layers of management between developers and customers, and long periods of planning (presentations, designs, architecture, etc.) without working code to back it up. All this sounds to me like an intuitively good idea and a natural way to work. None of that resembles the monstrosity that people complain about while calling it 'agile'. In fact, I feel that this monstrosity is the creature of the pre-agile period that appropriated the new jargon.

bluefirebrand 1y ago

Agile gave managers the idea that any task, no matter how complex, should be able to be broken down enough to fit into a ticket that can be estimated semi-accurately before even looking into the problem, and the work required to complete the ticket can fit into a two week time period

iliaskurt 1y ago
comment of the year
vannevar 1y ago
I think managers had those kind of ideas way before agile. And if anyone on the team doesn't think a given ticket can be completed within a sprint, they should speak up--the whole point is that the team concurs that X can be done in a sprint, and they collectively decide what X is. Empirically, I'd say in my experience that the sprint velocity has been accurate around 80% of the time. Which is enough to be useful.
- azangru 1y ago
  I'd just like to point out that the notion of 'sprint', let alone sprint velocity, comes specifically from scrum. Which is just one version of agile software development, albeit the most common one. For example, the arbitrariness of the sprint timebox, as well as the guessing of how much will be done over that time period, are perhaps among its weakest ideas, and have often been criticized.
  - bluefirebrand 1y ago
    I think that at this point people have to let go of "Scrum is not the only way to do Agile" It's "technically" true, and I admit that, but this battle is lost If someone says they are doing Agile they mean Scrum. Otherwise they will specify Kanban (or whatever else) by name I know it's not technically correct, but that's just how it is, sorry
  - vannevar 1y ago
    Fair. But the central idea of scrum is a self-managed team, and there's nothing that says every sprint has to have the same duration, it just makes calculating the velocity easier. There's also nothing that says you can't pause sprints for some unstructured design and experimentation time, something that I think teams do too little of. The problem is that many organizations don't understand the self-managing aspect and simply put a manager in charge of the team and the scrum, which pretty much sabotages things from the start. This micromanagement, along with imposing unrealistic development timelines, are the two biggest mistakes that I commonly see. Neither of them are unique to agile.
anonymars 1y ago
I think t-shirt sizing is madness. "How long is a piece of string?" But we've had tickets to create other tickets, because, as you point out, speccing out the feature (including what does it do and what does it not do) is itself a ton of work In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value*? So Amdahl's law says having AI optimize that part isn't going to move the needle all that much *it's certainly possible to expend lots more effort coding, but is it coding in the right direction?
- bluefirebrand 1y ago
  > In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value Ehh... I've heard this sort of reasoning before and I get where it comes from, but I'm not sure I agree. It feels like "Idea Guy" propaganda to overvalue their contribution. Figuring out what to build doesn't provide real value at all imo. It provides theoretical value. Coding is closer to 100% of the work that actually provides the value Edit: This is why people who actually have skills to build things are made to sign NDAs and Non-competes when hired or before being pitched projects. The ideas people want to keep the value of their idea and undervalue the skill of actually building things
  - anonymars 1y ago
    I am in no way saying "the idea guy" is doing 80% of the work, that's probably less than 10% Put another way -- genuine question to which I have only a guess: who does more coding during an average day? A junior developer or a senior developer? Broadly I'd posit the junior developers do a lot more coding, and the more senior you get the more important "English" becomes over any programming language. Maybe I'm in an aberrant bubble. But I doubt it. > This is why people who actually have skills to build things are made to sign NDAs and Non-competes when hired or before being pitched projects. So what I'm getting at is, my version would be: "this is why senior developers code less than junior developers"

vonneumannstan 1y ago

>I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before? Because it adds hours of nearly pointless meetings to your workweek? The time spent in standups and retros and sprint planning and refinement that imo add nearly no value is shocking...

azangru 1y ago
Yes; dysfunctional meetings suck up time. But on the other hand, in a dysfunctional team without meetings, developers do not coordinate their efforts, may not realise what is the most important to do on a given day, do not get a shared understanding of which aspects of their work can be improved, do not know or care about the full picture of the product that they are working on; information, instead of flowing freely between developers, or between teams of developers, or between management and developers, tends to stagnate in silos.
- vonneumannstan 1y ago
  No one is saying no meetings or no planning. But the amount of required meetings that could be emails necessary in Agile is way over the top.
vannevar 1y ago
Then your problem is bad meetings, not agile. If there's truly no value in quick daily updates and occasional work planning/review meetings, it's only because either those things are being done some other way or the team is dysfunctional.
roryirvine 1y ago
But that's nothing to do with Agile - after all, any of the big pre-Agile iterative methodologies from the 1990s like RUP or DSDM were just as often plagued with pointless meetings! One of the most important aspects of following an Agile methodology is that teams are expected to be self-organising, so if the meetings you're participating in aren't working for you, you should absolutely be discussing that with your team. It could be that others do find them valuable, but you might well find that they feel the same as you and would be willing to consider how to make them more effective.

hunter-gatherer 1y ago

In short, my experience with Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity. I do see how it is actually useful when talking to managers and investors about progress. However from the engineers' view it is just more of an administrative burden. In my view the "sin" that Agile committed was the promise of productivity, when really (from engineering viewpoints) it appears to be an unnecessary accountability mechanism. I worked in fiance once with Agile, where there exists in the culture an infinite growth mindset. So I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. Some companies probably don't suffer from this though.

deleted 1y ago
[deleted]
azangru 1y ago
> Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity > ... > I worked in fiance once with Agile ... I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. It's fascinating to me how different a meaning different people put into the word 'agile'. The 'agile' of the founders was about small teams, close collaboration with the customer, and frequent feedback based on the real emerging working software, which allowed the customer to adapt and change their mind early (hence 'agile', as in 'flexible'). What it contrasted itself to was heavy, slow-moving organisations, with large interdependent teams, multiple layers of management between developers and customers, and long periods of planning (presentations, designs, architecture, etc.) without working code to back it up. All this sounds to me like an intuitively good idea and a natural way to work. None of that resembles the monstrosity that people complain about while calling it 'agile'. In fact, I feel that this monstrosity is the creature of the pre-agile period that appropriated the new jargon.