11–20 of 201 posts
Ultimately, it's more about the people involved. Bad teams are going to find a way to screw themselves over no matter what process they use. Good teams don't need a rigid process since they'll just find a way to get stuff done no matter what.
I suspect it's the author that has changed, not everyone else. It's probably a combination of a nostalgic bias combined with the author's increasing age making it harder to get on with a typical team of young whippersnappers.
I say this as someone who is over forty and regularly falling into the "things were better in my day" trap (although hopefully self-aware enough to see it).
Most management and process exists to turn 1.0x developers into 1.2x (in theory) but turns the 10x into 3x or 2x or sometimes -2x. When you start enforcing process, closing up definitions of work, and take power away from engineers, you lose so much more off the top than you get from bringing up the bottom.
The problem is that very few executives actually want to create an inspiring place to work where people do their best. ("Fuck you, I've got mine.") They want incremental "improvements" (of questionable long-term value) on what already exists. This hand-wringing about process sounds a lot like early communism: it trudges along happily, inventing new structures, in complete ignorance of the human motivations around it.
this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.
>anti-intellectualism that is so pervasive in the software development scene Errrr....
"I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now." I suspect it's the author that has changed, not everyone else. It's probably a combination of a nostalgic bias combined with the author's increasing age making it harder to get on with a typical team of youn…
He's probably seen a few teams ruined by young megalomaniacs who want to put terms like Scrum and Kanban all over their resumes because they (being Clueless, in the MacLeod / Gervais sense of the word) think it's the ticket to the brass ring.
In a nutshell: because by the time software companies start to look for some methodology silver bullet they are already hip-deep in trouble and no amount of 'process' will fix multiple years of bad hiring decisions, bad engineering and unrealistic expectations.
Problem is that with agile (as I understand and mildly practice it at least) you can't have "identical requirements", because you don't have full, complete and detailed requirements upfront.
In my own anecdotal experience I would say the team matters way more than the methodology. I've been on teams that could have been (and were) repeatedly successful on projects that ranged widely from strict agile to strict waterfall. Every single time that team pumped out good quality software reasonably on time. I've also been on teams that were not successful no matter what methodology they used. The team just wasn…