5 ms·

> I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a devel

by lispm 8y ago

> I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes. 'evidence' found in Hackernews posts? > I'm confident the evidence shows zero efficacy this will surely help with selecting evidence, given that you know already the findings. > This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking! How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help? > This is abject nonsense. Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny. > like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area. The team should be cross-functional based on the product the team develops. > This presumes that there always exists some "reproducible way" This actually presumes that I identify successful practices which can be applied in many projects. We did. > You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way. No, I'm not denying it, but when my team had success with Continuous Integration, I probably would use that in the next project - when applicable. It would also be a surprise if in a new project I would need to start from scratch to completely redesign workflows and team communication, without any prior knowledge/practices applicable. I've worked for a few decades in software projects and in software consulting - often I was responsible for project and team setups. Often developing new stuff. I can easily imagine that other domains work differently.

mlthoughts2018 8y ago
> "How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?" Both! > "Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny." Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment. > "The team should be cross-functional based on the product the team develops." This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" (and don't even think of saying the no-true-Scotsman reply, "but that means they're doing Scrum wrong!" Scrum leads them to that type of thinking). In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently of each other because it's not muddied by an artificial requirement for "cross-functional" skills. Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose. > "This actually presumes that I identify successful practices which can be applied in many projects. We did." But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me. What's your reaction to that fact? If your reaction is to say, "well then you did Scrum wrong, because it always works" then you are just denying the premise that any other solution could be possible, and it absolutely is a No True Scotsman fallacy. Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?
- lispm 8y ago
  > Both! Strange, >Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment. Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training. > This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" Management actually meant: we don't want to spend more money. They fooled you. Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project. If your management is too dumb or you are too easily fooled by management, don't blame Scrum. > In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. True. But that has nothing to do with Scrum. > Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently Sure, this is how silos in big companies try to work. For small teams this is overkill. > of each other because it's not muddied by an artificial requirement for "cross-functional" skills. This is not an artificial requirement. Small teams with cross-functional skills make communication more effective. If you have large problems, then you need to scale that. But that is all basic knowledge. > Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Again, basic knowledge. > Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose. Scrum does not impose an unilateral model for all projects. You can develop in all kinds of ways and Scrum might not be applicable to your domain/setup. You can even take elements of Scrum - just don't call it Scrum - a daily standup meeting can be useful in many projects. > But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me. Then don't use it. Simple as that. > Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team? I already said that you can do perfect Scrum and still fail. You can also succeed without Scrum. It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc. Also if your team does not like banana, don't feed them banana.

by lispm 8y ago

mlthoughts2018 8y ago

> "How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?" Both! > "Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny." Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment. > "The team should be cross-functional based on the product the team develops." This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" (and don't even think of saying the no-true-Scotsman reply, "but that means they're doing Scrum wrong!" Scrum leads them to that type of thinking). In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently of each other because it's not muddied by an artificial requirement for "cross-functional" skills. Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose. > "This actually presumes that I identify successful practices which can be applied in many projects. We did." But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me. What's your reaction to that fact? If your reaction is to say, "well then you did Scrum wrong, because it always works" then you are just denying the premise that any other solution could be possible, and it absolutely is a No True Scotsman fallacy. Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?

lispm 8y ago
> Both! Strange, >Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment. Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training. > This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" Management actually meant: we don't want to spend more money. They fooled you. Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project. If your management is too dumb or you are too easily fooled by management, don't blame Scrum. > In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. True. But that has nothing to do with Scrum. > Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently Sure, this is how silos in big companies try to work. For small teams this is overkill. > of each other because it's not muddied by an artificial requirement for "cross-functional" skills. This is not an artificial requirement. Small teams with cross-functional skills make communication more effective. If you have large problems, then you need to scale that. But that is all basic knowledge. > Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Again, basic knowledge. > Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose. Scrum does not impose an unilateral model for all projects. You can develop in all kinds of ways and Scrum might not be applicable to your domain/setup. You can even take elements of Scrum - just don't call it Scrum - a daily standup meeting can be useful in many projects. > But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me. Then don't use it. Simple as that. > Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team? I already said that you can do perfect Scrum and still fail. You can also succeed without Scrum. It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc. Also if your team does not like banana, don't feed them banana.