The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: http://agilemanifesto.org/
The only thing Scrum has ever been great at (and why it's continually chosen despite proven harmful to development productivity) is that it's great at simulating continuous progress and control to management. Other than that, it's simply fostering architectural mess and a political, dogmatic attitude from and towards everyone.
It all starts with a clear product vision from the top and defining how succeeding on it looks like.
If you don't know where to go, Scrum will get you there faster and in even more directions at once.
Or, to cite one of my all time favorites:
"Building intuition on how to make good decisions and cultivating a great relationship with your team will get you 95% of the way there. The plethora of conceptual frameworks for organizing engineering teams won’t make much difference. They make good managers slightly better and bad managers slightly worse."
> The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto:
None of those things are Scrum.
Scrum talks about defining bits of work to do on your product, but doesn’t mention User Stories. (But really, what’s the beef with User Stories? They’re short descriptions of what you hope to achieve! You gotta make some kind of plan sometime or you have no cohesion. If you don’t like the formality of User Stories, drop ‘em).
The meeting structures are not defined by Scrum. The intent and topics are defined, but the structure (apart from vague suggestions for rhythm and timing). They only exist on a cadence so you can predict some parts of the system (like ensuring the client turns up to see the work done). You can change most of the details.
Scrum doesn’t define any planning or estimation practice, it simply recommends you use some system so that the right people are in sync. You have to know if part A takes an order of magnitude longer to make than part B, so that they can hooked up properly.
Specs? Mocks? Task board? None of that is Scrum.
Scrum has two lists: the backlog, and the sprint backlog. The former grows as you learn what to make; the latter comes into being at the start of a sprint and disappears at the end. If you must put it in swim-lanes, that’s your loss. Don’t blame Scrum.
What you're describing sounds almost agile... joke aside, as I tried to point at, the original idea was pretty good, but it's certainly not what the snake oil people made of it and will sell you: https://www.scrumalliance.org/
The original Scrum also talks about servant leadership, when in reality in 99% of wannabe agile organizations, everything is just about enabling some manager's power trips.
The real problem is that Scrum is not agile at all: Scrum is a fat "process" that enforces "following a plan" (regular, rigid meeting structure), "creating comprehensive documentation" (user stories, specs, mocks, task board) and "contract negotiation" (estimation meetings, planning poker). In that way, it's the exact opposite of the original agile Manifesto: http://agilemanifesto.org/
The only thing Scrum has ever been great at (and why it's continually chosen despite proven harmful to development productivity) is that it's great at simulating continuous progress and control to management. Other than that, it's simply fostering architectural mess and a political, dogmatic attitude from and towards everyone.
It all starts with a clear product vision from the top and defining how succeeding on it looks like.
If you don't know where to go, Scrum will get you there faster and in even more directions at once.
Or, to cite one of my all time favorites:
"Building intuition on how to make good decisions and cultivating a great relationship with your team will get you 95% of the way there. The plethora of conceptual frameworks for organizing engineering teams won’t make much difference. They make good managers slightly better and bad managers slightly worse."
— https://www.defmacro.org/2014/10/03/engman.html