Inapplicable metaphor; a foundation is singular by definition. And project planning is not software development, and not my topic. I write requirements and functional specifications but I'm not a project manager and my one experience as a dev lead was enough to know that management isn't my thing.'
I'm talking about software development; writing code, finding and fixing bugs. And I remember the early days in the industry when managers understood that our work requires focus and concentration, back before mangers were replaced by people with business degrees who started with doubling us up in offices and did away with the whole idea of letting us work uninterrupted. Listening to some guy yelling in Hindi on the phone all day with tobacco on his breath, that took away a big hunk of joy right there.
The logic is simple. The methodologies contribute very little, they entail daily interruptions, they add extra layers of process, they misdirect priorities; and, finally, most of us don't need them.
I can see how some junior developers need more structure in their management and without regular guidance will drift. I get it.
But viewing software in terms of teams is just wrong, it's a collaborative endeavor but it should never include people working on the same code files. The methodologies heavily emphasize writing software as a social activity, which it isn't, I think if I had to sit through a "sprint retrospective ("let's spend four hours discussing what we just learned about teamwork") I would go straight out of my mind. This culminates in the abhorrent practice of pair programming, which I think should land managers in prison.
One three hour episode of it in 2009 had me quit my job the next day and seek therapy for PTSD eleven years later; to order people to pair program is sadistic and it is psychologically harmful. I sleep further from my spouse than I sat next to the condescending lickspittle I had to pair program with. Thanks, Glen Beck, I had troubled sleep for over a decade.
I stand by my statement about concentration. If you have not read my article on Flow
please read it now, and if you’re really feeling frisky you can read the referenced study. . This is the foundation of my assertion that concentration is itself the foundation of good programming.
Since developers are constantly interrupted they can't concentrate; since they can't concentrate they write lousy code; management doesn't address this by returning to what worked before, but instead by adding another layer of process, the idiocy known as test-driven development, which I have written several articles about, a colossal waste of time and with a particularly intense fanaticism. It's hard to imagine anything more plainly misguided than TDD.
The best jobs I've had restricted recurring meetings to one per week, and we had separate one-off design collaborations that were very fruitful.
I've never met anyone who liked working with agile and scrum. In my last onsite job in the USA the "daily scrum" turned my 30 minute commute to a 90 minute one, an hour lost every day in glacial traffic instead of getting in at the 10AM I was used to. Everyone hated it and managers refused to move it to an hour that would not require us to drive in rush hour traffic, which in Seattle is terrible.
And the methodologies claim to have invented processes e.g. dividing projects into smaller milestones that I was already doing 30 years ago. A "sprint" is nothing but yet another justification to keep people working 60 or more hours a week because the pressure never relents.
And, finally, the methodologies introduce new nomenclatures that ranges from empty to irritating, Calling user scenarios “stories” feels like kindergarten; we have an whole new lexicon of buzz that sounds intelligent but adds nothing. In science and mathematics the insertion of new words for non-new ideas is the very coin of fraud. What the hell does “refactor” even mean?
Over to you.