My impression and experience working in many "classically" or Scrum-driven projects: you either have a team that works, or you don't. Teams mostly work because people communicate well, respect each other, have the necessary skills required for their job and form a unit with a shared sense of goals. Of course, this list is not exhaustive and external factors are important as well, but I'll leave those out of the equation. On the other hand, there are teams that don't work well together, because they're missing one or more of these crucial ingredients. But, and that's my key learning, Scrum needs all these qualities as well, else it will fail. If a project is lucky enough to have a very good Scrum master and product owner(s), they might be able to help a team form through various means.
So... you have this "mythical", but totally incomplete methodology that almost totally depends on factors it can't create itself: what's its purpose then?
There's another crucial factor: is a team really allowed to go all-in on Scrum, meaning it has the support of the rest of the company to provide them with what they need in time and quality? More often than not, deadlines and budget are still fixed (which, from a company's point of view, is perfectly valid), but this removes one of the most important pillars Scrum is based on.
What was the reason for Scrum's success then? Well, I'd argue that it was driven by management, because they learned what happens if you let a team go "black box", missing dead lines, quality, etc., so they got totally excited by the promise of constant, visible delivery. Fair enough. Also, it's a nice, fashionable way of controlling and tracking people, that veils itself as transparency. We don't need leadership, it all falls into place by itself by some democratic process. Many people don't work that way, that's a reality, whether we like it or not. But, and this is one of my most crucial reasons to resent the Scrum hoax: pressure of constant delivery plus chunking tasks into bite-size tasks strongly disadvantages complex, foundational and cross-concern work. Error handling or security (just to name two topics)? Nah, we don't need it now, let's get stuff done! Except: this is all needed! I like to compare it with building a house: nobody would start working on the cosy bed room on the second floor before the foundation is done. Can't build a bathroom without pipes being installed before. How did we think we could build software this way? Of course, all of this can work with Scrum, as it does not prevent good work from happening. But: you need the right people in the right setting. And then you're back to square one, see above.
One last thing: people are not stupid. Once they realize that they're not in a real Scrum setting, they learn how to cope with the situation. Rituals degenerate into meaningless bla bla, story points are not story points anymore, velocity tracking is not perceived as a chance to improve, but surveillance, etc.
For me, the quality of a software product is more determined by people than by tools or methodologies, always was, always will be.
Company decides to do Scrum -> Scrum describes how the team should work together (incomplete) -> If the organization is far removed for the conditions the team needs, Scrum expects the framework to help change the organization -> The Scrum Team is unable to do that, Scrum can then not really succeed.
Maybe we should not describe how the team works, but what the organization should provide.
I've only been on the side of rocky scrum situations for my entire career. I have yet to come across a single person that was like, "Mike. Scrum following all the rules is the best!" Many of us have adjusted (aka lowered to rock bottom) our expectations with it.
One thing that seems to be missing from this is that many aspects of scrum work better when they are integrated into the broader organisation around the scrum team.
For example, who are the sprint reviews for? Hopefully stakeholders. Who can give feedback that influences what's in the next or subsequent sprints.
Also a little missing is the purpose of some parts of scrum as enabling or supporting the team.
Are retros being done on behalf of the squad members? Are those members enabled to speak up about realistic or meaningful sprint goals?
I think it chooses not to. It leaves the way the organisation works open to vary.
For example, a sprint review is for involving stakeholders in a discussion of what's been achieved. Who those stakeholders are depends on the organisation, but scrum done right means they should be outside the team.
Whereas a sprint retro should be about the team. What do they think of what's working and what isn't. What can they do independently of the organisation around them.
My impression and experience working in many "classically" or Scrum-driven projects: you either have a team that works, or you don't. Teams mostly work because people communicate well, respect each other, have the necessary skills required for their job and form a unit with a shared sense of goals. Of course, this list is not exhaustive and external factors are important as well, but I'll leave those out of the equation. On the other hand, there are teams that don't work well together, because they're missing one or more of these crucial ingredients. But, and that's my key learning, Scrum needs all these qualities as well, else it will fail. If a project is lucky enough to have a very good Scrum master and product owner(s), they might be able to help a team form through various means.
So... you have this "mythical", but totally incomplete methodology that almost totally depends on factors it can't create itself: what's its purpose then?
There's another crucial factor: is a team really allowed to go all-in on Scrum, meaning it has the support of the rest of the company to provide them with what they need in time and quality? More often than not, deadlines and budget are still fixed (which, from a company's point of view, is perfectly valid), but this removes one of the most important pillars Scrum is based on.
What was the reason for Scrum's success then? Well, I'd argue that it was driven by management, because they learned what happens if you let a team go "black box", missing dead lines, quality, etc., so they got totally excited by the promise of constant, visible delivery. Fair enough. Also, it's a nice, fashionable way of controlling and tracking people, that veils itself as transparency. We don't need leadership, it all falls into place by itself by some democratic process. Many people don't work that way, that's a reality, whether we like it or not. But, and this is one of my most crucial reasons to resent the Scrum hoax: pressure of constant delivery plus chunking tasks into bite-size tasks strongly disadvantages complex, foundational and cross-concern work. Error handling or security (just to name two topics)? Nah, we don't need it now, let's get stuff done! Except: this is all needed! I like to compare it with building a house: nobody would start working on the cosy bed room on the second floor before the foundation is done. Can't build a bathroom without pipes being installed before. How did we think we could build software this way? Of course, all of this can work with Scrum, as it does not prevent good work from happening. But: you need the right people in the right setting. And then you're back to square one, see above.
One last thing: people are not stupid. Once they realize that they're not in a real Scrum setting, they learn how to cope with the situation. Rituals degenerate into meaningless bla bla, story points are not story points anymore, velocity tracking is not perceived as a chance to improve, but surveillance, etc.
For me, the quality of a software product is more determined by people than by tools or methodologies, always was, always will be.
Thanks for your insightful comment.
Basically:
Company decides to do Scrum -> Scrum describes how the team should work together (incomplete) -> If the organization is far removed for the conditions the team needs, Scrum expects the framework to help change the organization -> The Scrum Team is unable to do that, Scrum can then not really succeed.
Maybe we should not describe how the team works, but what the organization should provide.
I've only been on the side of rocky scrum situations for my entire career. I have yet to come across a single person that was like, "Mike. Scrum following all the rules is the best!" Many of us have adjusted (aka lowered to rock bottom) our expectations with it.
One thing that seems to be missing from this is that many aspects of scrum work better when they are integrated into the broader organisation around the scrum team.
For example, who are the sprint reviews for? Hopefully stakeholders. Who can give feedback that influences what's in the next or subsequent sprints.
Also a little missing is the purpose of some parts of scrum as enabling or supporting the team.
Are retros being done on behalf of the squad members? Are those members enabled to speak up about realistic or meaningful sprint goals?
You're spot on, but Scrum doesn't give much guidance beyond the team level, and expects Scrum to help terraform the org, which rarely happens.
I think it chooses not to. It leaves the way the organisation works open to vary.
For example, a sprint review is for involving stakeholders in a discussion of what's been achieved. Who those stakeholders are depends on the organisation, but scrum done right means they should be outside the team.
Whereas a sprint retro should be about the team. What do they think of what's working and what isn't. What can they do independently of the organisation around them.
Yes, it's a design choice, if I may call it that way.