4 ms·
> "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 mad
by 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.
- lispm 8y ago> by creating an expectation that every engineer ought to be trained as a full-stack engineer, This is false. Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional. Even 'full stack' (a concept not from Scrum) does not mean 'expert on everything'. Full stack means able to work with front- and backend frameworks for websites. A 'full stack' developer for example will not be expected to be a NLP or a ML expert. The full-stack-developer might have no idea about automated performance tests and he/she usually will not have deep UX skills. I usually use 'T-shaped' or π-shaped as a requirement for team members. Horizontal skills enable the person to work in a Scrum team with all the added stuff (like automated testing, software repositories, task system, continuous integration, ...). Vertical skills add depths in one or two fields: backend development with Java, frontend development with JavaScript, agile testing, business analysis, database admin/programming, cloud infrastructure, etc. Looks like you are setting up strawmans - another fallacy.
- mlthoughts2018 8y ago> “Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional.” It’s naive to approach this in some letter-of-the-law way. Whatever you want to argue that “Scrum says” the reality of what it facilitates & encourages (which is the attenpt to push everyone towards full-stack responsibilities) is different. > “A 'full stack' developer for example will not be expected to be a NLP or a ML expert.“ This is just not how it plays out in big corporate Agile. They absolutely try to combine specialized skills with front end skills. I work in ML & I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals, etc., with job descriptions listing all manner of wishlist full stack competencies in addition to PhD-level skill in some machine learning domain. How these places keep thinking the drives and interests required for this can coexist in a single person, I don’t know, but they keep it up. Always in a “fast-paced Agile environment” too.
- lispm 8y ago> It’s naive to approach this in some letter-of-the-law way The principle of a cross-functional team is widely explained and described. Basically everyone will tell you the same story. Even Wikipedia: https://en.wikipedia.org/wiki/Cross-functional_team https://en.wikipedia.org/wiki/Cross-functional_team > A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. The companies I work for are able to understand that. > I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals Zero? I've just searched on monster.com for "machine learning engineer". Hits: 300+ Then I searched for "machine learning engineer" and "react". Hits: zero. Combinations "machine learning engineer" and "scrum": 8 hits. I fear your 'many times' is not backed up by reality.