4 ms·

The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I believe that stems from the fact that agile methods became too "

by myth2018 4y ago

The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I believe that stems from the fact that agile methods became too "productized": there's a whole market of books, lectures, certifications, courses etc and lots of people willing to profit from it. Eventually it became a sort of a religion. If you question it, it's because you don't understand it; if it yields bad results, it's because you did it wrong; if it doesn't fit the dynamics of the rest of the company, it's because the company is immature. All the methods have known limitations and prerequisites. All but Agile, which is perfect. It's a ridiculous lack of empiricism for a discipline like software engineering.

capableweb 4y ago
Most of the consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team doesn't seem to have actually read the original "agile manifesto", which is: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan
- xg15 4y ago
  But couldn't this "ossification" of agile be a sign that the manifesto is actually wrong? A lot of the criticism seems to form around the fact that people actually develop processes around agile, even though agile discourages processes. (And that those processes in the end become empty rituals that hinder development more than support it) But couldn't this actually be a sign that people in fact need processes to get some kind of routine and system into their work?
- myth2018 4y ago
  I agree with you. But even the Manifesto has some points that make it impractical in many circumstances. To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? Agile requires Trust. But trust is a fluid thing, and we must cope with its fluctuations. The client is cooperating? Good, let's get a bit liberal about some rules, but let's keep monitoring the situation. The team is mature enough to self-manage? Good, let the team manage itself, but keep an eye to see if things are still running smoothly as the time goes by. The biggest problem of Agile is that it takes Trust for granted and assumes that every single stakeholder wants the project to succeed, and shares the exact same definition of success.
  - dragonwriter 4y ago
    > To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Yes, but note that the client is inside the circle, not an external force, in Agile. > Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. Yes, that is specifically what the point deals with, on both sides. Favoring contract negotiation over collaboration is a very poor way of dealing with those things. (The X over Y statements in the Manifesto are not X instead of Y, but Y must be centered on supporting X; contract negotiation is necessary, but the terms must be framed to support collaboration rather than impede it by being inflexible for the kinds of things that are known to be likely to change over the time of the project development.) > How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? If the need for collaboration was centered in contract negotiation, then that will be addressed. > The biggest problem of Agile is that it takes Trust for granted The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas.
    - skrtskrt 4y ago
      If you don’t protect yourself with a contract, another party will screw you 11 times out of 10. By all means collaborate, but put it in a contract too.
      - jacobr1 4y ago
        One of the subtleties is how to determine acceptance criteria by the stakeholders/client. You can negotiate upfront a spec, and upon delivery conformance to the spec means success. Or you could negotiate a high-level objective, or a metric to be changed, and every sprint get an on-the-fly approval of the incremental changes delivered. The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
- DreamFlasher 4y ago
  > consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team This is in itself a major point. Managers trying to put scrum on everything. This is my main hope for scrum passing away. I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is. On the other hand so far I haven't worked for a single company that actually did scrum (despite claiming it). They all started by "adjusting the process" and removing the scrum master. Sure. You totally understood how this works.
marcosdumay 4y ago
I don't think "eventually" is the right word there. It immediately became dogma, and the one most used description about people's implementation of agile was always "you are doing it wrong". Somehow the things in the Agile Manifesto never popularized, only those religions did.
pydry 4y ago
If agile were christianity, scrum would be the catholic church - the institutionalized, rigid, dogmatic and hierarchical instantiation of the original vaguely specified & lovey dovey cult.
manuelabeledo 4y ago
> The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs. Thus Agile may not be a failed idea, but it arguably fails at the implementation. Agile apologists seem to be disconnected from this reality.
- matt-attack 4y ago
  Totally agree. All these teams down in the weeds are obsessed with following the rituals to a tee thinking that makes them good little devs. When the whole point is so the middle and upper managements can track your activity to the minute and judge your performance.
ericbarrett 4y ago
Rather than becoming this over time, Scrum slotted into existing teams and practices that were already heavily into rigid project management. The same teams that adopted Scrum were previously using Waterfall or 6-Sigma or some other such prescriptive framework. Agile showed up, got a lot of buzz, and then Scrum came along to sell the buzz to big institutions with entire departments of professional project managers. Were the creators of Scrum hopefully trying to introduce flexibility in the guise of process, or cynically cashing in on a trend? I don't know; all I do know is that Big Software switched from $old_process to Scrum around 2010-2012, and medium-sized companies seemed to follow in the middle of the decade.
joshspankit 4y ago
> I believe that stems from the fact that agile methods became too "productized" While I agree that that’s an issue, I would argue that it stems from the fact that dynamic ideas are opposed to pragmatic ones (at least in the minds of pragmatists). Inevitably in companies there are voices that say “we should mitigate risk”, “let’s do what worked before”, and other things that boil down to “don’t change things because I’m not good with change”. It’s those types of people who productize everything that gains momentum as it’s a cycle of “This new thing is a threat”, “They tried it and it worked, I better change my tone or I’ll be ostracized”, “How can this be made rigid and safe?” “Oh excellent, there’s a certification program now: time to crack down now that I have a whip.”. And as they spend more company money on making it “safe”, the market responds and makes more “safe” products.
urthor 4y ago
I agree. The process itself is fine. The issue is that the practitioners are none-too-adept managers and teams. Making software is simply hard. No amount of Scrum frameworks solves for staffing a project with a talent-less manager. Although Scrum does help for that scenario I'll be honest.

capableweb 4y ago

Most of the consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team doesn't seem to have actually read the original "agile manifesto", which is: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan

xg15 4y ago
But couldn't this "ossification" of agile be a sign that the manifesto is actually wrong? A lot of the criticism seems to form around the fact that people actually develop processes around agile, even though agile discourages processes. (And that those processes in the end become empty rituals that hinder development more than support it) But couldn't this actually be a sign that people in fact need processes to get some kind of routine and system into their work?
myth2018 4y ago
I agree with you. But even the Manifesto has some points that make it impractical in many circumstances. To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? Agile requires Trust. But trust is a fluid thing, and we must cope with its fluctuations. The client is cooperating? Good, let's get a bit liberal about some rules, but let's keep monitoring the situation. The team is mature enough to self-manage? Good, let the team manage itself, but keep an eye to see if things are still running smoothly as the time goes by. The biggest problem of Agile is that it takes Trust for granted and assumes that every single stakeholder wants the project to succeed, and shares the exact same definition of success.
- dragonwriter 4y ago
  > To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Yes, but note that the client is inside the circle, not an external force, in Agile. > Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. Yes, that is specifically what the point deals with, on both sides. Favoring contract negotiation over collaboration is a very poor way of dealing with those things. (The X over Y statements in the Manifesto are not X instead of Y, but Y must be centered on supporting X; contract negotiation is necessary, but the terms must be framed to support collaboration rather than impede it by being inflexible for the kinds of things that are known to be likely to change over the time of the project development.) > How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore? If the need for collaboration was centered in contract negotiation, then that will be addressed. > The biggest problem of Agile is that it takes Trust for granted The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas.
  - skrtskrt 4y ago
    If you don’t protect yourself with a contract, another party will screw you 11 times out of 10. By all means collaborate, but put it in a contract too.
    - jacobr1 4y ago
      One of the subtleties is how to determine acceptance criteria by the stakeholders/client. You can negotiate upfront a spec, and upon delivery conformance to the spec means success. Or you could negotiate a high-level objective, or a metric to be changed, and every sprint get an on-the-fly approval of the incremental changes delivered. The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
DreamFlasher 4y ago
> consultants/junior developers/managers and others who try to shoehorn "agile" into every process and team This is in itself a major point. Managers trying to put scrum on everything. This is my main hope for scrum passing away. I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is. On the other hand so far I haven't worked for a single company that actually did scrum (despite claiming it). They all started by "adjusting the process" and removing the scrum master. Sure. You totally understood how this works.

marcosdumay 4y ago

I don't think "eventually" is the right word there. It immediately became dogma, and the one most used description about people's implementation of agile was always "you are doing it wrong". Somehow the things in the Agile Manifesto never popularized, only those religions did.

pydry 4y ago

If agile were christianity, scrum would be the catholic church - the institutionalized, rigid, dogmatic and hierarchical instantiation of the original vaguely specified & lovey dovey cult.

manuelabeledo 4y ago

> The biggest problem is not in Agile itself, but indeed in the dogmatism of its practitioners. I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs. Thus Agile may not be a failed idea, but it arguably fails at the implementation. Agile apologists seem to be disconnected from this reality.

matt-attack 4y ago
Totally agree. All these teams down in the weeds are obsessed with following the rituals to a tee thinking that makes them good little devs. When the whole point is so the middle and upper managements can track your activity to the minute and judge your performance.

ericbarrett 4y ago

Rather than becoming this over time, Scrum slotted into existing teams and practices that were already heavily into rigid project management. The same teams that adopted Scrum were previously using Waterfall or 6-Sigma or some other such prescriptive framework. Agile showed up, got a lot of buzz, and then Scrum came along to sell the buzz to big institutions with entire departments of professional project managers. Were the creators of Scrum hopefully trying to introduce flexibility in the guise of process, or cynically cashing in on a trend? I don't know; all I do know is that Big Software switched from $old_process to Scrum around 2010-2012, and medium-sized companies seemed to follow in the middle of the decade.

joshspankit 4y ago

> I believe that stems from the fact that agile methods became too "productized" While I agree that that’s an issue, I would argue that it stems from the fact that dynamic ideas are opposed to pragmatic ones (at least in the minds of pragmatists). Inevitably in companies there are voices that say “we should mitigate risk”, “let’s do what worked before”, and other things that boil down to “don’t change things because I’m not good with change”. It’s those types of people who productize everything that gains momentum as it’s a cycle of “This new thing is a threat”, “They tried it and it worked, I better change my tone or I’ll be ostracized”, “How can this be made rigid and safe?” “Oh excellent, there’s a certification program now: time to crack down now that I have a whip.”. And as they spend more company money on making it “safe”, the market responds and makes more “safe” products.

urthor 4y ago

I agree. The process itself is fine. The issue is that the practitioners are none-too-adept managers and teams. Making software is simply hard. No amount of Scrum frameworks solves for staffing a project with a talent-less manager. Although Scrum does help for that scenario I'll be honest.