4 ms·

If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a pr

If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that. I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.

stephenhuey 6y ago
I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing. If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
- chris11 6y ago
  > people using Waterfall for software development. Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman. > but not usually for software where you learn more from users about what should be done and tweaked as you go along I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
kube-system 6y ago
I don't think that's a fair assessment. There are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult. I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful. How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%29#Workflow https://en.wikipedia.org/wiki/Scrum_%28software_development%... Some big things I've learned are: * Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly. * You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint. * All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.
- chris11 6y ago
  > I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes. And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it. I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
tootie 6y ago
"Hindrance to me" is the wrong attitude unless you run the company. Scrum is not for the team to work faster. It's for the teams work to be visible, understood and correctly allocated. I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates and then doing whatever they want.
- vesinisa 6y ago
  What a sad and nihilistic view. Experienced devs are smart people. If you communicate the company targets, priorities and deadlines clearly, they will naturally find a way to self-organize to achieve those goals. Devs think it's micromanagement when they feel like they are not trusted to execute the communicated plans, but are instead required to report every hour worked to some slavemaster who might at any moment "allocate" them to a different task.
  - killtimeatwork 6y ago
    Not in my experience. In my experience, if you give the devs leeway, they'll come up with some totally overengineered architecture with the latest tech in it (which is great for their CVs) and will spend a lot of the time bikesheding over nonsense (e.g. killing each other PRs because "too functional" or "not functional enough"). The developers don't care about the company goals, but they care about their CVs and personal preferences regarding languages, tooling etc. Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
    - vesinisa 6y ago
      Well I suggest you stop working with colleagues you describe as psychopaths ASAP for the sake of your own mental health. I could never work with a developer who sacrifices the company's / team's business goals for a line in their own CV. But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business. If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?
lmm 6y ago
Again and again I've gone into the details of people's criticisms of scrum, and again and again it's turned out that they were just not actually doing it. Actually doing scrum does work 100% of the time as far as I can tell.
- odshoifsdhfs 6y ago
  And on the other hand, you have a lot of testimonies here that say the only places they saw scrum work was when it was adapted to the team, and the ones that followed it to the letter failed. It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
  - lmm 6y ago
    Only two that I'd call perfect, but I also saw a direct correlation between how much a company broke the rules and how bad the results were.

stephenhuey 6y ago

I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing. If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.

chris11 6y ago
> people using Waterfall for software development. Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman. > but not usually for software where you learn more from users about what should be done and tweaked as you go along I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.

kube-system 6y ago

I don't think that's a fair assessment. There are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult. I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful. How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%29#Workflow https://en.wikipedia.org/wiki/Scrum_%28software_development%... Some big things I've learned are: * Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly. * You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint. * All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.

chris11 6y ago
> I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes. And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it. I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.

tootie 6y ago

"Hindrance to me" is the wrong attitude unless you run the company. Scrum is not for the team to work faster. It's for the teams work to be visible, understood and correctly allocated. I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates and then doing whatever they want.

vesinisa 6y ago
What a sad and nihilistic view. Experienced devs are smart people. If you communicate the company targets, priorities and deadlines clearly, they will naturally find a way to self-organize to achieve those goals. Devs think it's micromanagement when they feel like they are not trusted to execute the communicated plans, but are instead required to report every hour worked to some slavemaster who might at any moment "allocate" them to a different task.
- killtimeatwork 6y ago
  Not in my experience. In my experience, if you give the devs leeway, they'll come up with some totally overengineered architecture with the latest tech in it (which is great for their CVs) and will spend a lot of the time bikesheding over nonsense (e.g. killing each other PRs because "too functional" or "not functional enough"). The developers don't care about the company goals, but they care about their CVs and personal preferences regarding languages, tooling etc. Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
  - vesinisa 6y ago
    Well I suggest you stop working with colleagues you describe as psychopaths ASAP for the sake of your own mental health. I could never work with a developer who sacrifices the company's / team's business goals for a line in their own CV. But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business. If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?

lmm 6y ago

Again and again I've gone into the details of people's criticisms of scrum, and again and again it's turned out that they were just not actually doing it. Actually doing scrum does work 100% of the time as far as I can tell.

odshoifsdhfs 6y ago
And on the other hand, you have a lot of testimonies here that say the only places they saw scrum work was when it was adapted to the team, and the ones that followed it to the letter failed. It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
- lmm 6y ago
  Only two that I'd call perfect, but I also saw a direct correlation between how much a company broke the rules and how bad the results were.