5 ms·

"Why software developers hate Agile that is done wrong" FTFY

by tobib 7y ago

vkou 7y ago
Ah, the no true Scottsman. If it's not working, despite all the best efforts of your scrum-certified agilistas, it's because you're doing Agile wrong. If it's working, then it's because Agile is awesome! I've never seen a non-functioning team start functioning after Agile was introduced. And I've been on plenty of functioning teams that aren't doing Agile. Agile the process is about as useful as a tiger-warding talisman. Look, ma, no tigers!
- detaro 7y ago
  I mean, if you use a process that's apparently fixed enough it's worth making certifications around it, it's quite likely not "agile" in both the dictionary sense of the word and in the sense of the agile manifesto.
  - vkou 7y ago
    The agile manifesto is so broad and vague, it is all things to all people, and therefore useless. As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, because there are always capital-R 'Reasons' for why <your company's particular flavour of horrorshow> is having a negative impact on developer productivity. 'Reasons' that neither you, nor your team lead, nor his manager have any power to change, regardless of whether or not you are six-sigma-black-belt-scrum-master-rock-star-certified. There's only two valuable ideas in agile, that are actually broadly applicable. 1. Do continuous integration. 2. If it doesn't make sense to do something, don't do it. You don't need to get into philosophical discussions over the manifesto, and the purity of your adherence to agile philosophies, or any of that nonsense. What you do need to do is to go and deploy Jenkins (Or whatever the new hotness is in the CI world), and don't build features that nobody needs.
    - mindcrime 7y ago
      As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
    - detaro 7y ago
      I work in an environment with projects for many different customers, and almost as many different approaches to coordination with the customer, and I'd say the points from the agile manifesto are quite useful to suggest and evaluate the process for a project. Can we get a proper quick feedback loop? Can I talk directly to people that actually know about the details? How does the change process work? How much overhead is there that's not directly relevant to doing whatever it is were asked to do? What kind of decisions do we need to stick to that have been made without/against technical guidance? It really depends on the customer if that process is something that can't be influenced. Although of course we're as an external party often have more freedom in that regard than a customers direct employees. EDIT: added some specific questions
- GetOutOfBed 7y ago
  Agile works perfectly fine where I works. We just try to adhere to the manifesto. Works much better than anything I have been part of the last 25 years of my career, for sure. We wasted so much time back then.
JohnFen 7y ago
I've worked in a few Agile shops, and it was horrible in all but one. Perhaps that one was "doing it right". The thing is that it appears to be extraordinarily hard to do Agile right. I think that any system that is so difficult to implement correctly is an inherently flawed system.
- Cederfjard 7y ago
  Might it not be that it's extraordinarily hard to manage software development in general? Are you aware of any other methodology that's easier to do right and get the desired results?
  - JohnFen 7y ago
    Yes, managing software development is generally hard and there is no silver bullet. But I do think that the methods that I commonly encountered before Agile were better in terms of both developer stress and software quality. Interestingly, in many ways they also weren't all that different from what Agile is intending to bring. They still involved something analogous to "sprints", they still allowed for course correction and pivoting during development, and all of that. Agile seems to position itself as the opposite of "waterfall", but outside of large corporate environments, I'd never seen a shop that actually used waterfall as described by the Agile community.
SkyBelow 7y ago
If I hate something only when it is done wrong, but it is so easy to do wrong that it is far more often done wrong than not, at what point should I consider just hating the thing because it is so easy to do wrong?

"Why software developers hate Agile that is done wrong" FTFY

by tobib 7y ago

"Why software developers hate Agile that is done wrong" FTFY

vkou 7y ago

Ah, the no true Scottsman. If it's not working, despite all the best efforts of your scrum-certified agilistas, it's because you're doing Agile wrong. If it's working, then it's because Agile is awesome! I've never seen a non-functioning team start functioning after Agile was introduced. And I've been on plenty of functioning teams that aren't doing Agile. Agile the process is about as useful as a tiger-warding talisman. Look, ma, no tigers!

detaro 7y ago
I mean, if you use a process that's apparently fixed enough it's worth making certifications around it, it's quite likely not "agile" in both the dictionary sense of the word and in the sense of the agile manifesto.
- vkou 7y ago
  The agile manifesto is so broad and vague, it is all things to all people, and therefore useless. As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, because there are always capital-R 'Reasons' for why <your company's particular flavour of horrorshow> is having a negative impact on developer productivity. 'Reasons' that neither you, nor your team lead, nor his manager have any power to change, regardless of whether or not you are six-sigma-black-belt-scrum-master-rock-star-certified. There's only two valuable ideas in agile, that are actually broadly applicable. 1. Do continuous integration. 2. If it doesn't make sense to do something, don't do it. You don't need to get into philosophical discussions over the manifesto, and the purity of your adherence to agile philosophies, or any of that nonsense. What you do need to do is to go and deploy Jenkins (Or whatever the new hotness is in the CI world), and don't build features that nobody needs.
  - mindcrime 7y ago
    As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
  - detaro 7y ago
    I work in an environment with projects for many different customers, and almost as many different approaches to coordination with the customer, and I'd say the points from the agile manifesto are quite useful to suggest and evaluate the process for a project. Can we get a proper quick feedback loop? Can I talk directly to people that actually know about the details? How does the change process work? How much overhead is there that's not directly relevant to doing whatever it is were asked to do? What kind of decisions do we need to stick to that have been made without/against technical guidance? It really depends on the customer if that process is something that can't be influenced. Although of course we're as an external party often have more freedom in that regard than a customers direct employees. EDIT: added some specific questions
GetOutOfBed 7y ago
Agile works perfectly fine where I works. We just try to adhere to the manifesto. Works much better than anything I have been part of the last 25 years of my career, for sure. We wasted so much time back then.

JohnFen 7y ago

I've worked in a few Agile shops, and it was horrible in all but one. Perhaps that one was "doing it right". The thing is that it appears to be extraordinarily hard to do Agile right. I think that any system that is so difficult to implement correctly is an inherently flawed system.

Cederfjard 7y ago
Might it not be that it's extraordinarily hard to manage software development in general? Are you aware of any other methodology that's easier to do right and get the desired results?
- JohnFen 7y ago
  Yes, managing software development is generally hard and there is no silver bullet. But I do think that the methods that I commonly encountered before Agile were better in terms of both developer stress and software quality. Interestingly, in many ways they also weren't all that different from what Agile is intending to bring. They still involved something analogous to "sprints", they still allowed for course correction and pivoting during development, and all of that. Agile seems to position itself as the opposite of "waterfall", but outside of large corporate environments, I'd never seen a shop that actually used waterfall as described by the Agile community.

SkyBelow 7y ago

If I hate something only when it is done wrong, but it is so easy to do wrong that it is far more often done wrong than not, at what point should I consider just hating the thing because it is so easy to do wrong?