3 ms·

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 c

by 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?
- myth2018 4y ago
  > Yes, but note that the client is inside the circle, not an external force, in Agile Indeed, and this is one of the points Agile gets furthest from real world. Anecdote: I've worked for an average-sized bank with users who were cooperative but not that much. One day we were faced by an urgent legal requirement and the bank had to choose: either to halt operations or to adapt the software, otherwise our equivalent of a CFO would be arrested. The customer became an integral part of the team, we had extremely fast iterations and that was my first Agile project, and I didn't know it because I was going to hear first time about Agile only three years after that. As soon as the legal requirement was met, things got back to normal. That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard. > 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 I agree, but even avoiding the "instead of" interpretation, I believe the ideas in the Manifesto are only actionable under special conditions. Each project is a different case and demands a different combination of agile/non-agile variables, it all depends on the environment it presents (customer behavior, team's maturity, project complexity etc)
dasil003 4y ago
These are good points, but trust is not a prerequisite only for Agile. IMHO all large-scale software projects require trust to create space for the team to figure out the right path. If trust is lacking, it needs to be established, but the actions and steps that need to be taken are highly contextual and outside the scope of the Agile Manifesto.
- myth2018 4y ago
  I agree it's needed and it must be established if lacking, but 1) sometimes it's too unstable and you need institutional devices to counterbalance, but such devices are dismissed as useless bureaucracy in agile ideology and 2) agile seems to assume an idyllic world in which trust is established a priori and can be safely taken for granted

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?
myth2018 4y ago
> Yes, but note that the client is inside the circle, not an external force, in Agile Indeed, and this is one of the points Agile gets furthest from real world. Anecdote: I've worked for an average-sized bank with users who were cooperative but not that much. One day we were faced by an urgent legal requirement and the bank had to choose: either to halt operations or to adapt the software, otherwise our equivalent of a CFO would be arrested. The customer became an integral part of the team, we had extremely fast iterations and that was my first Agile project, and I didn't know it because I was going to hear first time about Agile only three years after that. As soon as the legal requirement was met, things got back to normal. That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard. > 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 I agree, but even avoiding the "instead of" interpretation, I believe the ideas in the Manifesto are only actionable under special conditions. Each project is a different case and demands a different combination of agile/non-agile variables, it all depends on the environment it presents (customer behavior, team's maturity, project complexity etc)

dasil003 4y ago

These are good points, but trust is not a prerequisite only for Agile. IMHO all large-scale software projects require trust to create space for the team to figure out the right path. If trust is lacking, it needs to be established, but the actions and steps that need to be taken are highly contextual and outside the scope of the Agile Manifesto.

myth2018 4y ago
I agree it's needed and it must be established if lacking, but 1) sometimes it's too unstable and you need institutional devices to counterbalance, but such devices are dismissed as useless bureaucracy in agile ideology and 2) agile seems to assume an idyllic world in which trust is established a priori and can be safely taken for granted