Eating print on camera certainly qualifies you as being on-par with Werner Herzog who ate his shoe on camera. The problem with classifying the need for lightwe

Eating print on camera certainly qualifies you as being on-par with Werner Herzog who ate his shoe on camera. The problem with classifying the need for lightweight methods as an "agile" problem is that agile has become the dogma that it set out to replace twenty years ago. Let that sink in. The word agile divides the room and that's part of the problem with cliched corporate speak. As a result, there is no more confusing argument in software process today than agile because we do not have consensus on its meaning. At best, defining agile is a choice paradox. This is a result of the spectrum from little a agile (actual agility) to Big A Agile (fake corporate agile) where the pointy haired boss tells you to select from a cargo cult of overly complex choices, all of which are bad. My experience has been that teams that wind up at real agile wind up there because they weren't worried about defining a cornucopia of cliched agile speak prior to moving forward and instead did a lean build-measure-learn cycle and just figured it out as a series of continuous improvement iterations whereas fake agile stems from trying to do what some other unicorn says works for them, failing, and never getting it right because there is no cycle of action learning and reflection. tldr; it doesn't actually matter what words you use to describe the gyrations, what matters is that the gyrations work for you and your team and produce the results the team desires. FWIW, most of what I've said is supported in the research and publishing of Alistair Cockburn who was there when it all began twenty years ago and wrote Crystal Clear. The other academic I'd reference who has the done the work and arrives at what I believe are the correct conclusions is Allen Holub.