3 ms·
> 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
by 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.
- mlthoughts2018 8y ago> "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." Earlier you made a disingenuous comparison of the relative bloat of RUP and Agile RUP in comparison to Scrum. The relative overhead costs of Scrum compared to those other methods don't matter. Only the overhead of Scrum compared to low-overhead and low-formalism methods that deliver the same business outcomes. > "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." Scrum, despite not explicitly saying it in any formal documents, facilitates managers in avoiding adding or removing of the right specialized people, by creating an expectation that every engineer ought to be trained as a full-stack engineer, and using language that makes it sound like every team ought to cover every possible domain. > "If your management is too dumb or you are too easily fooled by management, don't blame Scrum." How is this relevant? No one mentioned dumb management nor workers who are fooled by management. We are talking about how Scrum encourages and facilitates this kind of behavior, even among earnest management and fully-aware teams. It seems like more of the same No True Scotsman fallacy for you to presume it can only be caused by "too dumb" management or teams being "fooled". Yet again, in your description, the bad stuff cannot happen in a "real" Scrum setup, only in a "bad" one where people are either dumb or foolish. Defining away your problem. > "True. But that has nothing to do with Scrum." False, Scrum explicitly holds it as a principle that teams should always be cross-functional. Scrum doesn't allow the possibility that e.g. front-end work for a wide variety of products should be separated into a single front-end team, and corresponding backend work separated into different backend-specific teams. It advocates that all teams working on projects with front-end and backend needs should be both front-end and backend teams. This is very much a direct problem with Scrum itself. > "Scrum does not impose an unilateral model for all projects." This is one of the defining properties of Scrum. A unilateral choice for sprint length, format and frequency of planning meeting, details of required story point estimation, daily stand ups, required retrospective, etc. Scrum doesn't allow omitting these things when they are not useful. There is a tiny amount of customization allowed (e.g. t-shirt sizes instead of story points, or 3-week sprints instead of 2-week), but it's meaningless in terms of what a team actually needs to customize (which is stuff like dropping estimation all together, and e.g. only hold occasional retro meetings scheduled in an ad hoc way at the team's convenience, not enforced every X weeks as part of a sprint). > "It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc." My experience is the opposite... that adding Scrum in exactly those situations just means we have to do extra boilerplate work to get the same end product finished on time, and that Scrum is not more likely to succeed than other methods.