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.

109 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Henrik Kniberg shared this idea  ·   ·  Admin →

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Egbert Bouman commented  · 

        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  · 

        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  · 

        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  · 

        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  · 

        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  · 

        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!

      • Alan Larimer commented  · 

        +1Million Fredrik Wendt
        +1Million Adam Yuret

      • Ran commented  · 

        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  · 

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

      • gene gendel commented  · 

        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  · 

        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  · 

        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.

        de·vel·op·ment
        dəˈveləpmənt/
        noun
        noun: development
        1.
        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"

      • Dan Bergh Johnsson commented  · 

        A team consisting of layers doing a Due Diligence might chose another title for the team members than "Developer"

      • David Denham commented  · 

        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.

      • Jason Yip commented  · 

        Seems odd to anthropomorphise Scrum in general...

      Feedback and Knowledge Base