My spicy opinion on agile—pretty much any software development methodology—is that the method is never and has never been the problem. Agile can work. Scrum can work. Waterfall can work.
The problem has always been management and executives and their obsession with command and control tactics. If you don’t fix management, shuffling things around on the dev side won’t matter one jot.
Read the original papers on waterfall-style dev and you’ll find that they are eerily similar to many agile approaches.
The dev methodology has never been the problem. The problem has always been management.
@baldur I agree. If you read what the phased model folks were saying (like Benington) it's not too far away from the foundations of good software delivery.
You'd make pragmatic adjustments based on the invention of tools like source control, build servers, deployment automation - and to account for the huge difference in economics.
@baldur None of the papers I studied advocated for command and control (or top-down programming as Benington called it).
I wrote down my thoughts here:
@baldur YES!
I keep having this conversation with everyone around me, and it just Strick's me that manager use "agile" as a way to both be over reach into dev workflow and so they can relax themselves from having well done specs
There is no silver bullet
@baldur I agree. The reason I've sometimes pushed for processes in the past is specifically to mitigate some of the damage of poor managers.
By insisting on sprints, you can (try to) force managers to decide what goes into the sprint and what has to wait, instead of them just throwing stuff into a pile.
By insisting on planning meetings you can (try to) force managers to describe their thinking clearly or risk throwing the card back for clarification.
@baldur Kanban-style limits on how many tasks can be "in progress" can give developers an explanation why they can't just pick up something new. Retrospective meetings allow developers to say "this didn't work" in a neutral setting rather than complaining about a specific manager.
Not that often helps, but it *sometimes* helps. Sadly, as you say, if management see themselves as "leaders" to control the "workers", there's no fixing the core of the problem.
@baldur I don't think that's spicy at all.
Project management in general is (one) way to manage risk and process is usually a (poor) replacement for trust.
At a certain org scale, you have to have process, because humans aren't wired to trust that many people.
@baldur one of the core misconceptions about any of these approaches is that it's linear and acyclic (Waterfall is usually llustrated and conceptualized as a sequence of steps that go in one direction with a start and end, rather than a circle)
It's a LifeCYCLE. It's the same several steps over and over.
The longer each phase is, the more leverage that phase has over the whole process. So you really want that proces to be a small circle rotating fast, rather than a big circle rotating slowly.
@baldur @lisamelton Spicy? Maybe.
Absolutely correct? Definitely?
This is a great take IMHO.
Well said.
@baldur One of the most valuable things I've ever read, supports your point.
Baldur Bjarnason
Steve Fenton ➜
Fran
Andrew Radev
Andrew Theken
annie gray
indigo
elmuerte
blueorangeblue
Curt Krone
Passenger
Jack Baty
SpaceLifeForm
Søren
BugGenerator
Robert Link
Andy Wootton