> Veterans of the military and the airmail service still insisted they could fly "by the seat of the pants," and they thought less of those who could not. Their self-deception now seems all the more profound because the solution to the problem of flying in clouds and darkness -- a gyroscope adapted to flying -- was already widely available.
Reminds me quite a bit of programmers who insist that any formal developments process (including lightweight agile ones) is a crutch needed only by mediocre developers (which they of course don't need) and invented by companies who can't hire only the best (where they of course would never work).
Why in the world would it remind you of that? A development process is just a way to improve collaboration over basic informal communication. Without gyroscopes you are literally incapable of sensing your orientation. It would be like being unable to see anyone else's code.
It's the reaction of "veterans" that reminds me of it, the conviction that their vaguely-defined "skill" trumps everything - not the details of the thing they're rejecting.
Though there are similarities in that area as well: without any kind of coordinated planning, measurement of progress, and feedback-gathering, you're unable to see in what state the project really is, whether you're able to meet deadlines, stay in budget, and actually building the right thing.
Everyone believes themselves to be skilled, and the strength of belief correlates not much with actual skill. But even those who are still need to coordinate with others.
And while you can do all that without a formal process, can you do it repeatably (so results are comparable and composable) across time and team members? Can you be sure you won't forget doing some of it when you're busy? How often and when should you ideally do it?
Once you've thought about that, discussed it with your team members and come to an agreement with them, what you have is a formal process. The only thing left to do is to write it down so you'll still remember it next month.
When you say "formal" you are being a bit vague. Perhaps you can be more specific about which techniques you found to have a measurable difference? Is "light agile" the new thing?
The whole point of agile has always been to be lightweight, pretty much by definition (read the Agile Manifesto). If it feels oppressive or constricting, you're either doing it very wrong (every good thing can be perverted into its opposite) or need to get over your primadonna issues.
By "formal", I just mean that there's a written process for what to do when that everyone follows as long as they do not have a very good specific reason to deviate from it (and if that happens too often you try to find the reason and fix it, possibly by adjusting the process).
Things that make a big difference to me: continuous integration. Time-boxed releases focused on fully-working incremental business value. Regular reviews of the process itself. Rigid rules for what should and should not be discussed in meetings (at least the recurring all-hands ones).
Measurable differences? No, just heaps of anecdotal evidence. There's damn little quantifiable evidence for anything at project scale, no matter which industry, probably because differences between projects are so large and controlled experiments at that scale almost impossible.
Reminds me quite a bit of programmers who insist that any formal developments process (including lightweight agile ones) is a crutch needed only by mediocre developers (which they of course don't need) and invented by companies who can't hire only the best (where they of course would never work).