I suggest you ...

Remove "There are no exceptions to this rule"

A sentence like "there are no exceptions to this rule" makes Scrum overly dogmatic, and keeps people stuck in Shu. The phrase shows up after "Scrum recognizes no titles for Development Team members other than Developer" and "Scrum recognizes no sub-teams in the Development Team". I've seen plenty of cases where exceptions to that rule (and other rules) make perfect sense. Please remove that sentence in both places where it shows up.

106 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Henrik Kniberg shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Forson commented  ·   ·  Flag as inappropriate

    Development Teams include which role(s)?
    Pick all that apply

    Software Architects
    Business Analysts

  • Egbert Bouman commented  ·   ·  Flag as inappropriate

    I strongly agree. It's a peculiar addition to an already perfectly clear statement. Moreover, imho it's OK to name a tester a tester and an architect an architect etc. as a sub-category to developer.

  • Anonymous commented  ·   ·  Flag as inappropriate

    please do not change -- we already hear enough excuses to just continue what they always did -- with project managers and tech managers etc.

  • Tom Mortensen commented  ·   ·  Flag as inappropriate

    I wholeheartedly support the current wording. It is hard enough as it is to convince people to turn their backs on the concept of division of labour.

  • Jens Ostergaard commented  ·   ·  Flag as inappropriate

    Don't change as it is important that all team members feel responsible for all work, and thereby not having separate titles. If my title is tester I will feel more responsible for testing and less for other work.

  • Melvin Perez-Cedano commented  ·   ·  Flag as inappropriate

    Why only these two rules are called out to not allow exceptions? Does it mean that other rules in the SG allow exceptions? If so, those rules should be identified as well.

  • Filip Beslic commented  ·   ·  Flag as inappropriate

    The team's way of working should facilitate the delivery of increments, not tasks. Scrum does this by eliminating 'over the wall' mentality by removing roles. Team-members are thus involved and focus on that what really matters, delivering increments. They do not focus on 'parts' of the solution which falls under their role/function. Scrum unlike waterfall, is not an activity-based approach. Let's keep it that way. So there is no need for other roles than that of developer. I strongly disagree with your request!

  • Ran commented  ·   ·  Flag as inappropriate

    This request is vague and it does not give reasons of removing it other than authors view of what he has observed. Please give better reasons.

  • Anonymous commented  ·   ·  Flag as inappropriate

    The phrase does not say "We" or "An organization using Scrum". It says "Scrum" and that's just fine.

  • gene gendel commented  ·   ·  Flag as inappropriate

    there are always exceptions, imo.
    I think anywhere where we see "no exceptions" it fair to request "on exceptions under normal circumstances". but what if there are edge cases? As an example, a sprint in-flight termination is highly inadvisable act and should be done only at PO's discretion. But it does happen sometimes, in edge cases.

  • Fredrik Wendt commented  ·   ·  Flag as inappropriate

    This suggestion is vague and hart do reason about.

    a) If "there are no exceptions" kinds of statements keeps a team in Shu, is the sentence really what's hindering the team from advancing their practices? I think not. The problem is not within the Scrum Guide, but the team (and possibly their Scrum Master's/Agile Coach's understanding of experimentation and empiricism).

    b) The point of recognizing nothing but one Development Team, and all members of that team taking equal responsibility for the team's work - how would you suggest that sentiment is kept if the phrasing is removed? Or do you not agree that this is team focus is a phenomenon the software industry should move towards?

  • Adam Yuret commented  ·   ·  Flag as inappropriate

    UX design is development. Testing is development. Product management is development. A problem I hope the guide is addressing is the concept that programming is the only thing which is considered 'development' in this way I think they were intending on encouraging cross-functional teams who were in the business of developing value for customers.

    noun: development
    the process of developing or being developed.
    "she traces the development of the novel"
    synonyms: evolution, growth, maturation, expansion, enlargement, spread, progress; More
    a specified state of growth or advancement.

    "the wings attain their full development several hours after birth"

  • David Denham commented  ·   ·  Flag as inappropriate

    I would agree with this. For example, if you have a UX designer on a Scrum team who cannot develop, does it make sense to call them a developer, in spite of them making the team more cross-functional / less dependent? Not everyone needs to be a developer. Can't they just be called 'Players' (or some other rugby term)? He sentiment lies true for other parts of the guide such as estimation. Exceptions always exist.

Feedback and Knowledge Base