At the end of the day, tasks are going to take as long as they are going to take. That is what very few people outside of dev want to admit. And furthermore, most tasks provide very little value once an app is up and running.Its just the cycle of corporate. Each position/team justifying their roles. Doesn't matter if it's scrum, waterfall, or whatever other method you want to implement.
Very good video overall. Those are the exact points I hate about scrum. The part I disagree with is that there is some "true" scrum that isn't disfunction. I've never seen it. Any place that would allow it, wouldn't need scrum because they would already be reasonable. Scrum is the disfunction. This is why scrum gets adopted, because it can be turned into status meetings and micromanagement. Companies love it because it makes them feel like they are measuring developer productivity. They can goad developers to work harder and longer hours. When any company talks about scrum, the disfunction is exactly what they have in mind. Although I wasn't really a fan of scrum when I first learned about it coming from XP. 1. it isn't a development process, it doesn't cover things like releases, code reviews, SCM or anything I care about as a developer. 2. sprints do not increase in length if the work planned ends up being longer than expected. It turns sprints away from iterative development into a meeting schedule.
I dunno if it's hated. I think the problem with Scrum is that it is sold to devs as an Agile method but when you read the Agile Manifesto the only thing it matches is the retrospective meeting. No self organizing team, commitment to estimations, waterfall processes on disguise such as quoting a set of features in number of sprints (the shops then sells the sprints and the client expects exactly the feature "that were paid for"), negotiations with clients , meetings on why a project exceeded the estimations... Just be frank! Scrum is scrum, Agile is another thing.
I feel we so often miss that agile isn't a process, a set of events or a plan you execute to reap the sweet benefits. It's a mindset, a culture, a way of facing and dealing with change, of solving problems. Scrum, Kanban, LeSS, Nexus and so on and so forth can be used to further that... but none of them are agile. It's the people who are agile. This cultural journey is so often lost. You can have every single event prescribed in the Scrum Guide and not be the slightest bit agile in your organisation. On the flip side you can also be agile and be doing none of them.
The big problem I have with both SCRUM and Agile is what you said right at the end: SCRUM is just a framework. That allows so many people to tout its glory while showing absolutely none of it. It's like saying "a peanut butter and jelly sandwich is just a framework, so I make mine with olives, no jelly, and tons of salt." At a certain point, people have to be willing to say "yeah, this isn't Agile" or "yeah, this isn't SCRUM", and the fact that no one seems to be doing that and giving concrete examples just allows the horror to continue. SCRUM and Agile cannot be "just a framework" anymore.
The problem with scrum, is that, as a framework, it does very little to protect against the anti-patterns you describe. Any simplistic implementation of scrum will end up as you describe.
Perfect content. There are 2 other situations that I already saw that make scrum fail: the product owner define too many features to be delivered on the sprint, never even looking at the team velocity/capacity (he inserts just what he wants) and in the end, he reports to managers that the team couldn't deliver all. The second one is just following the scrum rituals blind, just because they have to. Using 4h to review or planning 2 week sprints. The result is more meetings than work done. Scrum is an excelent framework but everyone that participate, must understand it completely.
You should be given an honorary title for this comment God bless u my brother. most of the Product or p[project managers are not even technical people they just tell us what they bb want
Or they ask for a feature and how IMPORTANT it is. But forgets to write down the acceptance criteria, or doesn't even care about proper requirements, not even when asked by developers.
developers want to solve problems, scrum solves nothing, it IS THE problem. waterfall was not even bad, and waterfall is not even only alternative daily scrum is not important. estimations are the one i hate, velocity is stupid, also sprints are stupid.. why sprints when we have CONTINUOUS integration and delivery? scrum is very stupid
scrum serves the sole purpose of preventing any dev from becoming irreplaceable. It's the "prior defense" of useless managers trying to appear useful. no dev should be treated as an enemy of the project/product, but scrum already starts from this premise.
@@algonix11 not really but it sure prevents devs to make themselves irreplacable by not writing detailed documentation, using unnecessary complex code and such stuff. Prior to agile when some deeper bug occured it was easier and cheaper to rewrite whole parts of the code from the scratch if original developer was already gone. Been there, done that. I spent too much time to learn to think same way as the original author of the code to be able to fix the bugs and not break it more.
Johann chapoutot is a french historian specialized in nazism period (+20 years of study). Heads of management schools were ex-nazi officers. In short, the agile method comes from nazi officer methods. The Scrum master is the "happiness manager" witch is the nazi officer responsible of nothing. The Scrum master dumps all the responsabilities to the "Tech Lead" which is the nazi Fuhrer (a nazi fuhrer is a leader of 5 members). The members are human materials and therefore expandables.
@@bigneiltoo well I don’t think that scrum humanizes any more than rugby or american football or soccer humanizes. With the right team, the right coach and the right manager you can win a lot of matches and really enjoy it. Most of us play in fifth grade company teams with soccer moms as trainers and the local fast food place owner as managers… hate the players, don’t hate the game I’d say :-)
@@karlgustav9960 Forcing everyone to hear what everyone else is doing every day thrashes the brain. It's exclusively for the managers to micromanage. It's like if your daughter had an issue, having every one of her friends tell you about their problems every day and calling it enjoyable.
@@bigneiltoo who said work wasn’t had to be enjoyable? :-) What you probably refer to is the daily scrum / standup, and I do agree that in a lot of toxic work environments it is abused by managers as a daily status report. But guess what, it is not scrums fault that developers perpetuate this toxic behavior, you might as well say „no blockers“ and that’s it. Talk to your scrum master if you think that the value the team draws from the daily can be increased.
Seen this in other sectors, example EU project management, bad and lazy but highly socially skilled low and middle management pisses the entire framework out the window and frustrates everyone in the team making the workplace toxic. One of the things managers that have never written a piece of software will never understand there are layers of complexity and judging developers on how many lines of code were written or how many issues were solved will result that everyone will ignore the hard issues, those that take weeks to solve due to complexity, and ship out a product that is unsafe and fragile ---- agile ... fragile ... some connection there. Product owner has no place in the developer meeting. People don't got to Mercedes and be a smart ass on how the car is being built and at what pace (the deadlines are usually determined by contracts but those are breached offten .. even in the car industry) this should be solely on the developer team and the team leader. Companies that fail to see this will lose their most capable developers and their market share.
At the end of the day, tasks are going to take as long as they are going to take. That is what very few people outside of dev want to admit. And furthermore, most tasks provide very little value once an app is up and running.Its just the cycle of corporate. Each position/team justifying their roles. Doesn't matter if it's scrum, waterfall, or whatever other method you want to implement.
all scrum masters have been fired from our company(
👏👏👏
Very good video overall. Those are the exact points I hate about scrum. The part I disagree with is that there is some "true" scrum that isn't disfunction. I've never seen it. Any place that would allow it, wouldn't need scrum because they would already be reasonable. Scrum is the disfunction. This is why scrum gets adopted, because it can be turned into status meetings and micromanagement. Companies love it because it makes them feel like they are measuring developer productivity. They can goad developers to work harder and longer hours. When any company talks about scrum, the disfunction is exactly what they have in mind.
Although I wasn't really a fan of scrum when I first learned about it coming from XP. 1. it isn't a development process, it doesn't cover things like releases, code reviews, SCM or anything I care about as a developer. 2. sprints do not increase in length if the work planned ends up being longer than expected. It turns sprints away from iterative development into a meeting schedule.
Scrum is daily humiliation, disrespect, and a waste of time.
I dunno if it's hated. I think the problem with Scrum is that it is sold to devs as an Agile method but when you read the Agile Manifesto the only thing it matches is the retrospective meeting. No self organizing team, commitment to estimations, waterfall processes on disguise such as quoting a set of features in number of sprints (the shops then sells the sprints and the client expects exactly the feature "that were paid for"), negotiations with clients , meetings on why a project exceeded the estimations... Just be frank! Scrum is scrum, Agile is another thing.
I feel we so often miss that agile isn't a process, a set of events or a plan you execute to reap the sweet benefits. It's a mindset, a culture, a way of facing and dealing with change, of solving problems. Scrum, Kanban, LeSS, Nexus and so on and so forth can be used to further that... but none of them are agile. It's the people who are agile.
This cultural journey is so often lost.
You can have every single event prescribed in the Scrum Guide and not be the slightest bit agile in your organisation. On the flip side you can also be agile and be doing none of them.
Well said @Daniel. :)
The big problem I have with both SCRUM and Agile is what you said right at the end: SCRUM is just a framework. That allows so many people to tout its glory while showing absolutely none of it. It's like saying "a peanut butter and jelly sandwich is just a framework, so I make mine with olives, no jelly, and tons of salt." At a certain point, people have to be willing to say "yeah, this isn't Agile" or "yeah, this isn't SCRUM", and the fact that no one seems to be doing that and giving concrete examples just allows the horror to continue.
SCRUM and Agile cannot be "just a framework" anymore.
I myself are also frustrated with it sometimes. 😂
"using daily meeting as status report meeting", yes 100% true.
The problem with scrum, is that, as a framework, it does very little to protect against the anti-patterns you describe. Any simplistic implementation of scrum will end up as you describe.
Perfect content. There are 2 other situations that I already saw that make scrum fail: the product owner define too many features to be delivered on the sprint, never even looking at the team velocity/capacity (he inserts just what he wants) and in the end, he reports to managers that the team couldn't deliver all. The second one is just following the scrum rituals blind, just because they have to. Using 4h to review or planning 2 week sprints. The result is more meetings than work done. Scrum is an excelent framework but everyone that participate, must understand it completely.
You should be given an honorary title for this comment God bless u my brother. most of the Product or p[project managers are not even technical people they just tell us what they bb want
Or they ask for a feature and how IMPORTANT it is. But forgets to write down the acceptance criteria, or doesn't even care about proper requirements, not even when asked by developers.
developers want to solve problems, scrum solves nothing, it IS THE problem. waterfall was not even bad, and waterfall is not even only alternative
daily scrum is not important. estimations are the one i hate, velocity is stupid, also sprints are stupid.. why sprints when we have CONTINUOUS integration and delivery? scrum is very stupid
You seem to hate Scrum soo much.
indeed@@scrummastermind
The purpose of SCRUM is to deliver bad news as early as possible. That's all
scrum serves the sole purpose of preventing any dev from becoming irreplaceable. It's the "prior defense" of useless managers trying to appear useful. no dev should be treated as an enemy of the project/product, but scrum already starts from this premise.
@@algonix11 not really but it sure prevents devs to make themselves irreplacable by not writing detailed documentation, using unnecessary complex code and such stuff.
Prior to agile when some deeper bug occured it was easier and cheaper to rewrite whole parts of the code from the scratch if original developer was already gone. Been there, done that. I spent too much time to learn to think same way as the original author of the code to be able to fix the bugs and not break it more.
Johann chapoutot is a french historian specialized in nazism period (+20 years of study).
Heads of management schools were ex-nazi officers. In short, the agile method comes from nazi officer methods.
The Scrum master is the "happiness manager" witch is the nazi officer responsible of nothing.
The Scrum master dumps all the responsabilities to the "Tech Lead" which is the nazi Fuhrer (a nazi fuhrer is a leader of 5 members).
The members are human materials and therefore expandables.
Good content as always
Thank you 🙏
Developers and stakeholders both hate Scrum
Maybe some programmers (sorry I used the p-word) hate to be humanized and rather be emotionless baddass bug killing robots? 😂
After all that hard work, their brain is wired to be a robot. 🙃 Dang.
Did you just suggest that Scrum "humanizes"?
@@bigneiltoo well I don’t think that scrum humanizes any more than rugby or american football or soccer humanizes. With the right team, the right coach and the right manager you can win a lot of matches and really enjoy it. Most of us play in fifth grade company teams with soccer moms as trainers and the local fast food place owner as managers… hate the players, don’t hate the game I’d say :-)
@@karlgustav9960 Forcing everyone to hear what everyone else is doing every day thrashes the brain. It's exclusively for the managers to micromanage. It's like if your daughter had an issue, having every one of her friends tell you about their problems every day and calling it enjoyable.
@@bigneiltoo who said work wasn’t had to be enjoyable? :-) What you probably refer to is the daily scrum / standup, and I do agree that in a lot of toxic work environments it is abused by managers as a daily status report. But guess what, it is not scrums fault that developers perpetuate this toxic behavior, you might as well say „no blockers“ and that’s it. Talk to your scrum master if you think that the value the team draws from the daily can be increased.
Scrum died when it became corporitized.
Without music video would have been better.
Seen this in other sectors, example EU project management, bad and lazy but highly socially skilled low and middle management pisses the entire framework out the window and frustrates everyone in the team making the workplace toxic. One of the things managers that have never written a piece of software will never understand there are layers of complexity and judging developers on how many lines of code were written or how many issues were solved will result that everyone will ignore the hard issues, those that take weeks to solve due to complexity, and ship out a product that is unsafe and fragile ---- agile ... fragile ... some connection there. Product owner has no place in the developer meeting. People don't got to Mercedes and be a smart ass on how the car is being built and at what pace (the deadlines are usually determined by contracts but those are breached offten .. even in the car industry) this should be solely on the developer team and the team leader. Companies that fail to see this will lose their most capable developers and their market share.