The Scrum guides proudly state:
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Organizations trying to enforce this to a team might not realize, however, that people may simply choose to accept sharing the team blame (e.g. in case of possibly missing a deadline for a release) rather than accepting to do things they are not specialized for (e.g. a person who usually writes code may not sign in to define test cases if she is not used to it, even when the sprint’s timeline would be in red.)
This could easily happen when individuals think that such contribution might eventually jeopardize the overall quality of the deliverables that their team produces.
Some people might say that these members are just “not committed enough” (from the utopian point of view), but in my opinion the former ones would then just be fully blind, similar to the way communists were in the 20th century trying to make anybody work for everybody else; without a proper degree of pragmatism, people would easily miss the fact that productivity only flourishes upon specialization (and liberalism.)
The “nonconformist” developers mentioned above may actually be “too” committed to the product instead – so much that they’d rather screw Scrum entirely than deliver lower quality software to their customers; and I’d argue they have all the rights in the world to do so – what would users want: green sprints or, better, good products?…
Update: As readers mentioned to me there is a side story for this as well: very specialized tier teams or individuals that (just kinda) work together are not good either; backend and UI, for example, should be developed in tandem by a single team (or a single developer), and never provided by separate groups upon formal requests.
This one is an older issue that many organizations still face, but the full stack development trends (together with keeping teams small) are partially or at least conceptually solving this – that’s why in this article I originally insisted on the enforced Scrum toxicity alone – it’s a more recent issue, based on a more actual trend. (Note also that in my opinion Scrum itself, just like many other methodologies, may be good enough for specific projects if the teams consensually auto-select and auto-apply it themselves.)