Probably the biggest disservice done by Scrum was changing our thinking and language around methodology. It made it so that if something was going to displace it, it had to start with a capital letter, be a "real" version of something, and have a lot of institutional momentum behind it. It acted like some kind of social exploit--one we had no immunity to.
So, we ended up stuck with it, suffering untold millions of hours wasted in useless meetings and untold creativity crushed since it didn't fit into the process. We should've just tossed the notion that there's some kind of planning structure that makes sense across all possible projects, then done whatever made sense for our specific environments, not put a name on it, or even talked about "methodology" much at all.
Agile instead of agile, Scrum, Kanban, Scrumban, “shift left”, etc are all words that indicate the place has not only drank the kool aid but tried to drown any voices of reason with it.
> Can you feel the energy of a software industry eager to break free from the low-trust environments we’ve grown used to?
I beg your pardon, but Scrum did not fail because "it does not work", it fails because low-trust environment won't make room for an agile mindset. An I really hate the term "agile mindset", because it is overused. But if you give people responsibility and accountability, you can get a powerful, creative environment. Which, in turn, means that you need less management. Interestingly enough, middle management is usually not happy about that - so Scrum fails.
The subtext of the article seems basically to be that the author does not want to estimate tasks. Which is nice when someone else pays. It is less nice when you have to pay however.
Despite what they have told you, that's never a real issue. If the project is divided into small tasks, if progress is not being made on these tasks, the management always has the right to steer the direction of the project or to reassign the staff tasked to it. This is how management can continue to control the expenses. As for estimates, even an AI can give those, probably better than what a human can, and without any stress.
So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
How often carpenter needs to study while constructing what is the correct method to build to wall, and while doing that, try to find out whether the client wanted the wall or a floor, or even both of them?
Try to give any proper estimations before actually starting that kind of project, when the scope is not known and there is no buy-in to spend half of the time just to plan all little details.
It is not just "give an estimation", but a whole procedure to complete.
That's not a fair comparison at all. A bathroom or kitchen is something they have worked on a hundred or more times before, with little variation. In contrast, software is almost always original. If you ask me to implement the same software a hundred times with minor variations, of course I can give you good estimates without stress.
THIS exactly is what Software “professionals” have amazingly successfully been able to convince everyone. That somehow what we do is “special” and we just cannot possible tell you how long XYZ is going to take…
Software “is almost always original” is the same argument as if an incompetent carpetner would say “sorry, no two kitchens are alike and while I use same sh*t to build them I have never built yours exactly and hence I’ll send you the bill when I am done.”
Some changes to software are simple, but even simple changes can at times have unintended consequences, triggering the need for substantial refactoring or abstraction or performance tuning. It is all case by case, and it's not fully possible to fully predict what's needed ahead of time.
> So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
I love these general contractor analogies because it tells me that these people don't understand software engineering.
Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation.
It is up to management and business to decide if they are skilled and willing to accept the nature of software engineering.
I thought they debunked the "Spotify model" as something being promoted by a few consultants but also being phased out at the same time as being exposed to the public (nearly 10 years ago in 2014).
There are dozens of articles about the problems with matrix management that it introduced.
This is a weird and unbalanced selection... I expected to see waterfall or some variation on here, but nothing like it, even though it is very common. Lots of mentions of evolving & fully-autonomous engineering structures without even mentioning how this interfaces with all the other parts of every company larger than a few people. Valve's approach is not really a methodology vs. a perk from generating ridiculous per head revenues for a pretty small company. Shape up can only work as described when your company is small and run by a benevolent dictator will complete control.
This reads like someone which had bad management using effort estimates as hours and bugged the team about it. I'm saying that having seen plenty of environments where they do Scrum wrong.
> Because there are no sprints, you don’t have to worry about whether something fits into a sprint
I like fitting things into sprints. It forces tasks to be broken down into manageable items. If it's too big to fit, it's also probably ill-defined. Sometimes it goes over the sprint; it's alright; discuss during retro and learn from it.
> If an emergency arises, everyone pauses their work
You can still do that with Scrum. Scrum is a framework to estimate the effort and measure at fixed points in time. That's not an excuse to dismiss issues. Unless all of your work is unplanned, you can handle surprises AND estimate your leftover velocity.
"When you finish a task, you simply pull the next one from the top of the backlog”
Please, no. When you've finished a task see if you can help with a blocked or in-flight task.
Teams win points for finishing work, not starting new work.
Probably the biggest disservice done by Scrum was changing our thinking and language around methodology. It made it so that if something was going to displace it, it had to start with a capital letter, be a "real" version of something, and have a lot of institutional momentum behind it. It acted like some kind of social exploit--one we had no immunity to.
So, we ended up stuck with it, suffering untold millions of hours wasted in useless meetings and untold creativity crushed since it didn't fit into the process. We should've just tossed the notion that there's some kind of planning structure that makes sense across all possible projects, then done whatever made sense for our specific environments, not put a name on it, or even talked about "methodology" much at all.
Agile instead of agile, Scrum, Kanban, Scrumban, “shift left”, etc are all words that indicate the place has not only drank the kool aid but tried to drown any voices of reason with it.
> Can you feel the energy of a software industry eager to break free from the low-trust environments we’ve grown used to?
I beg your pardon, but Scrum did not fail because "it does not work", it fails because low-trust environment won't make room for an agile mindset. An I really hate the term "agile mindset", because it is overused. But if you give people responsibility and accountability, you can get a powerful, creative environment. Which, in turn, means that you need less management. Interestingly enough, middle management is usually not happy about that - so Scrum fails.
The subtext of the article seems basically to be that the author does not want to estimate tasks. Which is nice when someone else pays. It is less nice when you have to pay however.
Despite what they have told you, that's never a real issue. If the project is divided into small tasks, if progress is not being made on these tasks, the management always has the right to steer the direction of the project or to reassign the staff tasked to it. This is how management can continue to control the expenses. As for estimates, even an AI can give those, probably better than what a human can, and without any stress.
So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
How often carpenter needs to study while constructing what is the correct method to build to wall, and while doing that, try to find out whether the client wanted the wall or a floor, or even both of them?
Try to give any proper estimations before actually starting that kind of project, when the scope is not known and there is no buy-in to spend half of the time just to plan all little details.
It is not just "give an estimation", but a whole procedure to complete.
That's not a fair comparison at all. A bathroom or kitchen is something they have worked on a hundred or more times before, with little variation. In contrast, software is almost always original. If you ask me to implement the same software a hundred times with minor variations, of course I can give you good estimates without stress.
THIS exactly is what Software “professionals” have amazingly successfully been able to convince everyone. That somehow what we do is “special” and we just cannot possible tell you how long XYZ is going to take… Software “is almost always original” is the same argument as if an incompetent carpetner would say “sorry, no two kitchens are alike and while I use same sh*t to build them I have never built yours exactly and hence I’ll send you the bill when I am done.”
Some changes to software are simple, but even simple changes can at times have unintended consequences, triggering the need for substantial refactoring or abstraction or performance tuning. It is all case by case, and it's not fully possible to fully predict what's needed ahead of time.
And carpenter never experiences surprises after he opens the walls and sees wiring from Civil War era, lead pipes, etc...? Surely that never happens
> So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
I love these general contractor analogies because it tells me that these people don't understand software engineering.
Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation.
It is up to management and business to decide if they are skilled and willing to accept the nature of software engineering.
Yeah, the real world needs costs, estimates, timelines.
And you can help make them as good as possible.
Would have loved to see the author include a section on Extreme Programming.
Still my favorite.
I thought they debunked the "Spotify model" as something being promoted by a few consultants but also being phased out at the same time as being exposed to the public (nearly 10 years ago in 2014).
There are dozens of articles about the problems with matrix management that it introduced.
This is a weird and unbalanced selection... I expected to see waterfall or some variation on here, but nothing like it, even though it is very common. Lots of mentions of evolving & fully-autonomous engineering structures without even mentioning how this interfaces with all the other parts of every company larger than a few people. Valve's approach is not really a methodology vs. a perk from generating ridiculous per head revenues for a pretty small company. Shape up can only work as described when your company is small and run by a benevolent dictator will complete control.
This reads like someone which had bad management using effort estimates as hours and bugged the team about it. I'm saying that having seen plenty of environments where they do Scrum wrong.
> Because there are no sprints, you don’t have to worry about whether something fits into a sprint
I like fitting things into sprints. It forces tasks to be broken down into manageable items. If it's too big to fit, it's also probably ill-defined. Sometimes it goes over the sprint; it's alright; discuss during retro and learn from it.
> If an emergency arises, everyone pauses their work
You can still do that with Scrum. Scrum is a framework to estimate the effort and measure at fixed points in time. That's not an excuse to dismiss issues. Unless all of your work is unplanned, you can handle surprises AND estimate your leftover velocity.
All these frameworks and still Common Sense reigns supreme yet rarely applied.
Common sense is not common. Common sense is more akin to wisdom.
I like how kanban and agile are "alternatives" as if they're not very similar to how scrum it's defined.