[Tabular-Iceberg]

They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals.

I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.

[pydry]

>They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals.

Part of the reason I think we need this is to be able to categorically rule "agility" given the constraints a team is under. We need a framework that can say with crystal clarity that if you force waterfall planning on a team, they won't be agile no matter how good their coach is.

This needs to be a simple yes/no framework - something that could easily be answered with a questionnaire with objective answers to questions that can't be bullshitted. "Does your company do X, Y and Z?" "Ok, you've rejected agility".

This could include things like "will you rule out measuring productivity?" (Y/N) or "will you expect detailed plans from your team on the features they plan to build with milestones?" (Y/N). "Will the team have unfiltered access to the customer?" (Y/N). These questions need to be the awkward kinds of questions that managers who want waterfall in agile's clothing will have to answer wrongly.

>I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process

The authors never even mentioned the word empirical. When I said that the vagueness of the agile principles let people project their own desires onto what "agile" is, this is exactly the kind of thing I meant.

I think empiricism is quite possibly something that ought to be included in an "agile v2.0" though. For me agility does mean doing a series of small experiments on lots of different things and keeping/expanding on the things which work and dropping the things which don't. However, that's something I picked up by myself. The principles didn't teach me to do that.

[Kim_Bruning]

The way you word it, it sounds very much like a cargo cult phenomenon.

Copying the external trappings (Towers, runways, procedures.) , not the underlying goals or process (shipping cargo across the pacific).

I only do a small number of projects myself, but my understanding is that in a lot of places, people might follow "the agile process", rather than that they are aiming at actual Capital-A-Agility (where any and all process is merely a means to that end, and is rapidly tuned and adjusted as required) .

[drewcoo]

It was a general philosophy of how people can work together.

It lacked any of the specifics that typify cargo cults. It was the exact opposite of cargo cult - an actual understanding without any specific required rituals.

[Kim_Bruning]

I think you've read my comment backwards!

[EchoChamberMan]

How would one go about generalizing goals in the cargo cult example? To me, it would be something like "achieve your business goals," which while true, is not super useful. Maybe that would have been a better description though, given how much commodification is prioritized.