[johan_larson]

The problem I see with various flavors of Agile is that they don't fit in particularly well with how things actually get done at companies.

For example, teams running Agile are very reluctant to give both a delivery date and a fixed set of features. They're willing to promise one or the other, but not both. And that's a problem, because the whole rest of the organization really wants to know when they can announce the release to customers. Planning for releases tends to be a really big deal, the pressure to make promises of both functionality and delivery dates is very strong.

Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work. But this is rarely the case; typically you have a PM or something like that who is in touch with the customers, and is supposed to understand what they want. But this person is rarely senior enough to actually make decisions; important decisions are made by a dev manager or a project lead or someone like that, with the PM just providing input and perspective.

Finally, Agile has this notion that everything is supposed to be handled informally, verbally, person to person. And that's fine for small tweaks to the product. But as soon as you start building something big enough that it takes months and crosses team boundaries, it gets really useful to have an actual document explaining how something is supposed to work. Such a document is an invaluable record on what has actually been decided, and anyone joining the project or wanting to contribute to it absolutely should read it. But Agile tends to discourage creating such documents in the first place.

Given that Agile clashes so hard with how actual organizations get things done, it rarely gets adopted in anything approaching a pure form. The practices that tend to get picked up might be called Agile-light: sprints, daily meetings, and task estimation in points.

[loki49152]

The fundamental insight behind what became agile is that it isn't actually possible to have both a guaranteed delivery date and a guaranteed set of delivered features. The reality of software development just doesn't allow it.

Businesses don't "get things done" by operating as if they can have both. That's why projects fail, businesses cut corners, and then inevitably ship broken products or don't ship at all.

Most of the "agile methodologies" are nonsense dreamt up by borderline con artists attempting to sell their services. The fact that it's an either / or choice - and that nothing can get around that choice - is inherent in the nature of the work.

[johan_larson]

I agree with you that it is not possible to both fix the feature set and fix the delivery date and expect to consistently succeed. But it is also not possibly to tell upper management, who are dealing with a whole other set of difficulties, that they have to pick a feature set or a delivery date and that's all there is to it. If you do that, they'll reject your advice, and find someone else who'll give them a more palatable message.

The best I can come up with is the notion of a double contingency plan. Engineering agrees to a set of functionality to be delivered and a delivery date. This is inevitably going to be a bit optimistic, because people consistently overestimate themselves.

To deal with that, the first contingency plan addresses the question of what should be done if things are not converging to the ship date. The plan here is to keep the ship date, but ask hard questions about what bits of functionality actually need to be kept. What are the actual P0 - MUST HAVE features?

The second contingency plan addresses what is to be done if the first one fails. At this point engineering has already done all they can. They have pushed as hard as they can, and they have deferred every feature that is deferrable. They are down to the actual MUST HAVEs. Now the rest of the organization has to figure out what to do with a product that is inevitably going to be late. What is the alternate ship date? What customers are going to be really unhappy. And so on.

It seems to me any large engineering project should think out these contingency plans in advance. What will they do if making the deadline starts to look daunting? And what will they do if making the deadline turns out to be impossible?

[chiefalchemist]

> Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work.

Yes. Kinda :) But the issue isn't want. The friction is actual make-an-impact business needs.

It's easy to sit around a conference table and spitball wants. But trying to bin that person or group down to specifics as well as resolve disconnect and inconsistencies between the ideas and faces go blank.

Customers want the luxury to spit out wants without having to take the time to knuckle down and do the hard work of defining needs. They have a "you figure it out" attitude. That leads to assumptions. And assumptions lead to dysfunctional product / features, for which the engineers get blamed. Again.

Agile is a worthy solution to this problem, but when IT is treated as a service provider and not an equal partner the tool (i.e., agile) gets mutated to a point it's not truly agile anymore.

[tarcon]

Long Term Deadlines that are conjured up from thin air make no sense. That's why tools like a burn up charts exist.

Extreme Programming suggests having a customer on site. In Scrum the Product Owner is merely a substitute for the Customer.

The agile manifesto values working software more than comprehensive documentation, but does not forbid documentation.

So why do companies and their devs misunderstand this?

[walshemj]

And your point is??? AGILE is meant to change the way companies work