I made the main point I wanted to make in the post: saying “big company X works this way/uses this thing therefore you should too” is not a good argument, because it only tells you their outcome (and not whether the outcome was due to or in spite of choices made). But I'll expand here.
I find it fascinating, having lived through the first wave of Agile adoption, that Agile is now the "boo heavyweight process encumbering teams" word. Back in 2007 when my management were rejecting calls from the engineers at the digital coal face to adopt an Agile approach to software development, it was the “less ceremonial bullshit, more focusing on outcomes” word.
Maybe it's not that I'm surprised that there are still ways to improve engineering processes, with the Agile manifesto being written in a continuous tense: “We are uncovering better ways of developing software…”. I'm surprised that the rejection of Agile software development as values, principles, and practices is total, when it seems to be based on a dislike of some of the practices.
Actually the principles and values are still there: Kocienda says “A clear vision. Design-led development. Weekly demos to deciders who always made the call on what to do next. Clear communication between cross functional teams. Honest feedback. Managing risk as a function of the rate of actual progress toward goals.” That sounds like working software is the primary measure of progress, like customer interaction is valued over contract negotiation, like continuous attention to technical excellence and good design. Maybe the post-Agile way of working is the agile way of working after all.
People who describe themselves as “self-taught” usually actually learned from somewhere, so I ask the two questions: where did they learn from, and given that they learned from there why do they instead say that they are self-taught.