Loading ...
Sorry, an error occurred while loading the content.

Strong resistance to Scrum from Development Team

Expand Messages
  • vijay_nathani
    Most customers seem to like Scrum. The top management of a software development company does not seem averse to Scrum, if the customers want it. But, some
    Message 1 of 15 , Oct 11, 2009
    • 0 Attachment
      Most customers seem to like Scrum. The top management of a software development company does not seem averse to Scrum, if the customers want it. But, some project managers / team lead / developers / testers seem strongly opposed to scrum.

      I conduct trainings on Scrum in India. Most of my trainings are in Mumbai and Pune. Many times when I give this training, I have made the above observation. Some people are so opposed to Scrum that sometimes they attempt to disrupt the training e.g. If a project manager is opposed to scrum, he will tell one of his team members (who reports to him and does development / testing) to deliberately ask too many questions / point out problems / corner cases / exceptions / etc. This distracts the attention of the rest from learning scrum to something unimportant.

      Most of the time, I deal with these people by asking them not to delay others and reporting the same to the training department. But, this has happened so many times, that I decided to write down the reasons for the same:

      1) Team leads and Project manager feel afraid of Scrum because it causes a transition from Command & control to self organization. Loss of authority is usually associated with Loss of pay / job / respect.

      2) Some team members, who want to be treated as special, feel threatened that now they are only team members. Scrum does not give them their special role. They have to justify their specialization to other team members. They have to do all activities necessary to make the sprint a success.

      Do others also face similar problems? How are they dealing with the same? I will glad to hear from others.
      Vijay.
      http://sites.google.com/site/nathanivijay/
    • tobias.mayer
      Hi Vijay, In the past I have experienced similar resistance. I don t today. I think it is because over time I have changed the way I see (and teach) Scrum.
      Message 2 of 15 , Oct 11, 2009
      • 0 Attachment
        Hi Vijay,

        In the past I have experienced similar resistance.  I don't today.  I think it is because over time I have changed the way I see (and teach) Scrum.  If we teach Scrum as a prescriptive process it can certainly strike fear into people.  Scrum says do this, Scrum says don't do that...  Recipe for resistance and collapse, for sure.

        A gentler approach is sometimes required, for instance nothing in Scrum says you can't have job titles, or different salaries, or different status... Scrum is not a democracy.  Over time many people reconsider the value of such things and decide they are not as important as they once thought.  But if you start there, you will certainly upset certain people.  And the truth is we don't lose control with Scrum, we gain control.  It is a different kind of control, based on release rather than dictation -- and  certainly more effective.  Again though, this is something that must emerge in context, and if we try to force it the resistance will simply increase.

        I teach Scrum from the principles and values perspective now, I teach it as a framework, or as an abstract class that needs to be implemented in ones own context.  This takes us far way from prescription and into invention.  Most developers get off on invention.

        Just yesterday I wrote a blog post on the idea of Scrum as a contract between developers and business.  The main point being that contracts don't get results, people do.

        The post is here: Scrum doesn't do anything .

        Regards,
        Tobias



        --- In scrumdevelopment@yahoogroups.com, "vijay_nathani" <vijay_nathani@...> wrote:
        >
        > Most customers seem to like Scrum. The top management of a software development company does not seem averse to Scrum, if the customers want it. But, some project managers / team lead / developers / testers seem strongly opposed to scrum.
        >
        > I conduct trainings on Scrum in India. Most of my trainings are in Mumbai and Pune. Many times when I give this training, I have made the above observation. Some people are so opposed to Scrum that sometimes they attempt to disrupt the training e.g. If a project manager is opposed to scrum, he will tell one of his team members (who reports to him and does development / testing) to deliberately ask too many questions / point out problems / corner cases / exceptions / etc. This distracts the attention of the rest from learning scrum to something unimportant.
        >
        > Most of the time, I deal with these people by asking them not to delay others and reporting the same to the training department. But, this has happened so many times, that I decided to write down the reasons for the same:
        >
        > 1) Team leads and Project manager feel afraid of Scrum because it causes a transition from Command & control to self organization. Loss of authority is usually associated with Loss of pay / job / respect.
        >
        > 2) Some team members, who want to be treated as special, feel threatened that now they are only team members. Scrum does not give them their special role. They have to justify their specialization to other team members. They have to do all activities necessary to make the sprint a success.
        >
        > Do others also face similar problems? How are they dealing with the same? I will glad to hear from others.
        > Vijay.
        > http://sites.google.com/site/nathanivijay/
        >
      • George Dinwiddie
        ... There are lots of reasons that someone might be strongly opposed. If you ve got one such person in the class, you might take a break and ask that person
        Message 3 of 15 , Oct 11, 2009
        • 0 Attachment
          vijay_nathani wrote:
          > Most customers seem to like Scrum. The top management of a software
          > development company does not seem averse to Scrum, if the customers
          > want it. But, some project managers / team lead / developers /
          > testers seem strongly opposed to scrum.

          There are lots of reasons that someone might be strongly opposed. If
          you've got one such person in the class, you might take a break and ask
          that person about it. If you've got many, then you might wonder why
          these people are in the training. It's likely they didn't choose to be
          there.

          > I conduct trainings on Scrum in India. Most of my trainings are in
          > Mumbai and Pune. Many times when I give this training, I have made
          > the above observation. Some people are so opposed to Scrum that
          > sometimes they attempt to disrupt the training e.g. If a project
          > manager is opposed to scrum, he will tell one of his team members
          > (who reports to him and does development / testing) to deliberately
          > ask too many questions / point out problems / corner cases /
          > exceptions / etc. This distracts the attention of the rest from
          > learning scrum to something unimportant.

          Are these training classes within an organization (rather than open to
          the public)? Has this manager been forced into the class (and into
          Scrum) by upper management?

          > Most of the time, I deal with these people by asking them not to
          > delay others and reporting the same to the training department. But,
          > this has happened so many times, that I decided to write down the
          > reasons for the same:
          >
          > 1) Team leads and Project manager feel afraid of Scrum because it
          > causes a transition from Command & control to self organization. Loss
          > of authority is usually associated with Loss of pay / job / respect.
          >
          > 2) Some team members, who want to be treated as special, feel
          > threatened that now they are only team members. Scrum does not give
          > them their special role. They have to justify their specialization to
          > other team members. They have to do all activities necessary to make
          > the sprint a success.

          Yes, as Dale Emery points out in his Resistance as a Resource material,
          when someone is resisting something new, you can reframe the situation
          to one where that person is trying to preserve something that they
          value. Is there some way you can help these people preserve what they
          value in a way that's compatible with Scrum?

          > Do others also face similar problems? How are they dealing with the
          > same? I will glad to hear from others.

          Yes, coaches face similar problems all the time. Each situation is
          unique, as it's based on a unique individual. I deal with them by
          learning more about that individual.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Laurent Bossavit
          Hi Tobias, ... If contracts don t get results, and Scrum is a contract, then why bother with Scrum ? If you would recommend a particular contract to people who
          Message 4 of 15 , Oct 11, 2009
          • 0 Attachment
            Hi Tobias,

            > The main point being that contracts don't get results, people do.


            If contracts don't get results, and Scrum is a contract, then why
            bother with Scrum ?

            If you would recommend a particular contract to people who are
            interested in getting results...

            Or even if you would recommend, out of the myriad possible subsets of
            contract-space, a particular *type* of contract...

            Then that must be because the contract has *something* to do with the
            results you get when using it ?

            And, about "contracts don't get results, people get results" :

            "It's the people" is a useful phrase when you want to point attention
            *to* things that matter in developing software. Meetings,
            communication...

            "It's the people" is a harmful phrase when you use it to *distract*
            attention from something. For instance, from claims that Scrum lacks
            engineering practices and is therefore incomplete.

            If you are going to frame Scrum as generic advice which must be
            adapted to specific industries, be willing to confront the
            consequences and conclusions people will draw from that. For instance
            "XP is the software development instantiation of Scrum, so if you're
            going to teach Scrum to software people, teach them XP".

            If we use Scrum (or Agile, XP, etc.) as a weapon word to defuse
            people's curiosity, we should not be surprised when people reject
            Scrum (or Agile, XP, etc.)

            Laurent Bossavit
            laurent@...
          • jscherer147
            Hi Vijay, I think you are on the right track in asking yourself: Why don t people follow me in the direction I want to lead them? That shows that you take
            Message 5 of 15 , Oct 11, 2009
            • 0 Attachment
              Hi Vijay,

              I think you are on the right track in asking yourself:
              Why don't people follow me in the direction I want to lead them?
              That shows that you take these people and their reasons seriously!
              Maybe you could show even more of your respect for these people.
              For example try the following:
              Address these 2 topics explicitly during the course, discuss these common fears and find possible solutions for it together with your audience?

              Josef


              > Most of the time, I deal with these people by asking them not to delay others and reporting the same to the training department. But, this has happened so many times, that I decided to write down the reasons for the same:
              >
              > 1) Team leads and Project manager feel afraid of Scrum because it causes a transition from Command & control to self organization. Loss of authority is usually associated with Loss of pay / job / respect.
              >
              > 2) Some team members, who want to be treated as special, feel threatened that now they are only team members. Scrum does not give them their special role. They have to justify their specialization to other team members. They have to do all activities necessary to make the sprint a success.
              >
              > Do others also face similar problems? How are they dealing with the same? I will glad to hear from others.
              > Vijay.
              > http://sites.google.com/site/nathanivijay/
              >
            • Peter Stevens (cal)
              Hi Vijay, Yes, I have run into that problem too. I found Tobias advice very interesting and look forward to trying it out in my own classes. Some things which
              Message 6 of 15 , Oct 11, 2009
              • 0 Attachment
                Hi Vijay,

                Yes, I have run into that problem too.

                I found Tobias' advice very interesting and look forward to trying it out in my own classes.

                Some things which I have applied which has helped:
                1. I always start my courses and talks with a recognition that that there is more than one right way to do things. Some people believe in the Waterfall and think it most appropriate for their work. I tell them that's OK and focus the course on how Scrum works. I usually ask the skeptics to identify themselves and ask them to identify all the holes, problems, challenges, etc, and save them for the end of each unit, so that we can have an energetic discussion. So they feel taken seriously, they are not threatened, and they have a channel to ask their tough questions without disturbing the course.

                2. Scrum means change and change means uncertainty. People know their place and that's comforting. If the foundations change, people often fear that there will be no place for them. Managers, Testers, Architects & Business Analysts to name just a few may have difficulties seeing their future in a Scrum environment. So I remind them that Scrum does not define operational roles or organizational structures, and that there is a place for everybody, and that for most people (especially testers!) the new roles will be more important than the old one. (This might also be a subject of discussion in the course).
                One big change is the accountability at the end of a sprint. Without Scrum and a definition of done, developers could work on something as long as they felt appropriate, without having to deliver anything that the customer could evaluate. Now they have to deliver something the customer can judge every 30 days.

                I haven't quite got this last point solved. One discovers a lot about the team's dynamics during an in-house training and not all of it is pretty. I am thinking that an exercise or discussion on the value of accountability might be a way to address this issue.

                Hope this helps, and I look forward to hearing other strategies...

                Cheers,

                Peter


                vijay_nathani wrote:
                 

                Most customers seem to like Scrum. The top management of a software development company does not seem averse to Scrum, if the customers want it. But, some project managers / team lead / developers / testers seem strongly opposed to scrum.

                I conduct trainings on Scrum in India. Most of my trainings are in Mumbai and Pune. Many times when I give this training, I have made the above observation. Some people are so opposed to Scrum that sometimes they attempt to disrupt the training e.g. If a project manager is opposed to scrum, he will tell one of his team members (who reports to him and does development / testing) to deliberately ask too many questions / point out problems / corner cases / exceptions / etc. This distracts the attention of the rest from learning scrum to something unimportant.

                Most of the time, I deal with these people by asking them not to delay others and reporting the same to the training department. But, this has happened so many times, that I decided to write down the reasons for the same:

                1) Team leads and Project manager feel afraid of Scrum because it causes a transition from Command & control to self organization. Loss of authority is usually associated with Loss of pay / job / respect.

                2) Some team members, who want to be treated as special, feel threatened that now they are only team members. Scrum does not give them their special role. They have to justify their specialization to other team members. They have to do all activities necessary to make the sprint a success.

                Do others also face similar problems? How are they dealing with the same? I will glad to hear from others.
                Vijay.
                http://sites. google.com/ site/nathanivija y/


              • tobias.mayer
                Laurant, ... Okay. I don t see any value here in trying to explain again that Scrum doesn t lack engineering practices. Clearly my understanding of Scrum
                Message 7 of 15 , Oct 11, 2009
                • 0 Attachment
                  Laurant,

                  > ...Scrum lacks engineering practices and is therefore incomplete.

                  Okay.  I don't see any value here in trying to explain again that Scrum doesn't "lack" engineering practices.  Clearly my understanding of Scrum is utterly different from yours and to continue debating this with you seems to move neither of us forward.

                  > If we use Scrum (or Agile, XP, etc.) as a weapon word to defuse people's curiosity...

                  I don't do that.  Do you?

                  Tobias

                • tobias.mayer
                  Hi Peter, ... accountability might be a way to address this issue. I have often found it useful to step outside the confines of software, or work in general
                  Message 8 of 15 , Oct 11, 2009
                  • 0 Attachment
                    Hi Peter,

                    > I am thinking that an exercise or discussion on the value of
                    accountability might be a way to address this issue.

                    I have often found it useful to step outside the confines of software, or work in general and draw analogies from our personal lives to illustrate some key points such as accountability.  Consider how important it sometimes is to follow through with commitments we make to our spouse, or our children, and what the consequences of failing to deliver may be.  And it is not only about the behavior we engage in (although interesting), but about the feelings it invokes in us that are worth reflecting on.

                    Tobias

                  • Ron Jeffries
                    Hello, tobias.mayer. On Sunday, October 11, 2009, at 2:25:01 PM, ... I confess to being confused. In what way does Scrum not lack engineering practices? Ron
                    Message 9 of 15 , Oct 11, 2009
                    • 0 Attachment
                      Hello, tobias.mayer. On Sunday, October 11, 2009, at 2:25:01 PM,
                      you wrote:

                      >> ...Scrum lacks engineering practices and is therefore incomplete.

                      > Okay. I don't see any value here in trying to explain again that Scrum
                      > doesn't "lack" engineering practices. Clearly my understanding of Scrum
                      > is utterly different from yours and to continue debating this with you
                      > seems to move neither of us forward.

                      I confess to being confused. In what way does Scrum not lack
                      engineering practices?

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      Keep away from people who try to belittle your ambitions. Small people
                      always do that, but the really great make you feel that you, too, can
                      become great. -- Mark Twain.
                    • tobias.mayer
                      Ron, the use of the term lack implies that the practices should have been included and were somehow overlooked. This I fundamentally disagree with. Scrum
                      Message 10 of 15 , Oct 11, 2009
                      • 0 Attachment
                        Ron, the use of the term "lack" implies that the practices should have been included and were somehow overlooked.  This I fundamentally disagree with.  Scrum is agnostic by design. 

                        This is completely different to saying that software development teams using Scrum shouldn't use good engineering practices.  I am not saying that, and I do not believe it.  Of course software development teams should use good engineering practices.  It is a no-brainer.  But that is independent to the framework in which they work.  I would recommend waterfall teams use good engineering practices too -- in fact I did so myself in such environments.

                        You don't have to be doing XP to apply good software development practices.

                        Tobias


                        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                        >
                        > Hello, tobias.mayer. On Sunday, October 11, 2009, at 2:25:01 PM,
                        > you wrote:
                        >
                        > >> ...Scrum lacks engineering practices and is therefore incomplete.
                        >
                        > > Okay. I don't see any value here in trying to explain again that Scrum
                        > > doesn't "lack" engineering practices...
                        >
                        > I confess to being confused. In what way does Scrum not lack
                        > engineering practices?
                        >
                        > Ron Jeffries
                        >
                      • Adam Sroka
                        Hi Tobias: ... Yep... at least it was, but that s a whole other conversation. ... I agree with that completely, but I would add one thing: Agile processes,
                        Message 11 of 15 , Oct 11, 2009
                        • 0 Attachment
                          Hi Tobias:

                          On Sun, Oct 11, 2009 at 2:15 PM, tobias.mayer <scrum@...> wrote:
                          >
                          >
                          >
                          > Ron, the use of the term "lack" implies that the practices should have been included and were somehow overlooked.  This I fundamentally disagree with.  Scrum is agnostic by design.
                          >

                          Yep... at least it was, but that's a whole other conversation.

                          > This is completely different to saying that software development teams using Scrum shouldn't use good engineering practices.  I am not saying that, and I do not believe it.  Of course software development teams should use good engineering practices.  It is a no-brainer.  But that is independent to the framework in which they work.  I would recommend waterfall teams use good engineering practices too -- in fact I did so myself in such environments.
                          >
                          > You don't have to be doing XP to apply good software development practices.
                          >

                          I agree with that completely, but I would add one thing: Agile
                          processes, including Scrum, let you know what is happening frequently.
                          With Scrum you will find out that you suck before you have already
                          failed. Scrum enables continuous improvement by asking us to inspect
                          and adapt. I think it is inevitable that when software teams inspect
                          and adapt part of what they will find is that they more or less suck
                          at technical practices. So, it is difficult to do Scrum honestly and
                          not find yourself addressing those practices.

                          It is fairly easy to adopt a non-Agile practice and not address
                          technical practices because you are never asked to inspect and adapt
                          (At least not until "post mortem".) Moreover, when non-Agile teams do
                          address technical practices they still, generally, don't inspect and
                          adapt. So, they won't necessarily do things incrementally better,
                          they'll just discover a different kind of wrong.

                          All of that to say: XP practices are not "missing" from Scrum, but
                          Scrum teams tend to find them more than other teams that aren't
                          already doing them. There is more than one reason for that, but that
                          in itself should tell us something.
                        • Ron Jeffries
                          Hello, tobias.mayer. On Sunday, October 11, 2009, at 5:15:06 PM, ... Would you agree with does not have , then? Ron Jeffries www.XProgramming.com
                          Message 12 of 15 , Oct 11, 2009
                          • 0 Attachment
                            Hello, tobias.mayer. On Sunday, October 11, 2009, at 5:15:06 PM,
                            you wrote:

                            > Ron, the use of the term "lack" implies that the practices should have
                            > been included and were somehow overlooked. This I fundamentally
                            > disagree with. Scrum is agnostic by design.

                            Would you agree with "does not have", then?

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            We accomplish what we understand. If we are to accomplish something
                            together, we need to understand it together.
                          • Michael James
                            ... [Not responding to Adam in particular.] I ve seen teams take that path, and lately become disappointed that most seem not to. If we (trainers, coaches,
                            Message 13 of 15 , Oct 11, 2009
                            • 0 Attachment
                              On Oct 11, 2009, at 2:31 PM, Adam Sroka wrote:

                              > All of that to say: XP practices are not "missing" from Scrum, but
                              > Scrum teams tend to find them more than other teams that aren't
                              > already doing them.

                              [Not responding to Adam in particular.]

                              I've seen teams take that path, and lately become disappointed that
                              most seem not to.

                              If we (trainers, coaches, consultants, etc.) were doing an awesome job
                              of helping teams do Scrum, I'd expect to see the rate of Google
                              searches for TDD, JUnit, NUnit, refactoring, etc. roughly match the
                              increasing popularity of Scrum over the years. Last I checked, this
                              was not the case.

                              It's been implied that urging people to use "good" practices should be
                              specific enough. Decades ago I remember everyone nodding in a design
                              review meeting when a senior engineer counseled us that leaving hooks
                              for possible future requirements was "good design." Having testers
                              isolated from the development process (Independent Verification &
                              Validation) is still considered a "good" practice to many.

                              So while Scrum shouldn't specify engineering practices, Scrum
                              trainers, coaches, consultants, etc. should probably show some
                              examples of the practices that are possible.

                              --mj
                            • tobias.mayer
                              Hi Ron, ... As you know, a simple phrase can take on a number of different meanings depending on the context you use it in and the intention the speaker has
                              Message 14 of 15 , Oct 11, 2009
                              • 0 Attachment
                                Hi Ron,

                                > Would you agree with "does not have", then?

                                As you know, a simple phrase can take on a number of different meanings depending on the context you use it in and the intention the speaker has for using those words.  Tobias saying "Scrum does not include engineering practices" will mean something very different (it seems) from Laurent saying "Scrum does not include engineering practices".

                                So, would I agree with "does not have"?  Sometimes.  It depends :-)

                                Tobias


                                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                >
                                > Hello, tobias.mayer. On Sunday, October 11, 2009, at 5:15:06 PM,
                                > you wrote:
                                >
                                > > Ron, the use of the term "lack" implies that the practices should have
                                > > been included and were somehow overlooked. This I fundamentally
                                > > disagree with. Scrum is agnostic by design.
                                >
                                > Would you agree with "does not have", then?
                                >
                                > Ron Jeffries

                              • Adam Sroka
                                ... snipped a bit. ... From what I ve seen the trend towards accepting XP practices has been improving lately. I now work for an organization that is primarily
                                Message 15 of 15 , Oct 11, 2009
                                • 0 Attachment
                                  On Sun, Oct 11, 2009 at 4:35 PM, Michael James <michael@...> wrote:
                                  >
                                  >
                                  >
                                  > On Oct 11, 2009, at 2:31 PM, Adam Sroka wrote:
                                  >
                                  > > All of that to say: XP practices are not "missing" from Scrum, but
                                  > > Scrum teams tend to find them more than other teams that aren't
                                  > > already doing them.
                                  >
                                  > [Not responding to Adam in particular.]
                                  >
                                  > I've seen teams take that path, and lately become disappointed that
                                  > most seem not to.
                                  >

                                  snipped a bit.

                                  >
                                  > So while Scrum shouldn't specify engineering practices, Scrum
                                  > trainers, coaches, consultants, etc. should probably show some
                                  > examples of the practices that are possible.
                                  >

                                  From what I've seen the trend towards accepting XP practices has been
                                  improving lately. I now work for an organization that is primarily a
                                  Scrum coaching and training organization (Big Visible.) Part of their
                                  pitch to me was that they have been recommending XP practices for some
                                  time but they wanted to improve their capacity to mentor the technical
                                  team directly.

                                  It's one thing to say, "Maybe you should try TDD," and another to say
                                  "Let's figure out how to do this together, using TDD." Most coaches
                                  that I know are at least doing the former. The latter requires not
                                  only a different skill set but also a different sort of attention. To
                                  coach technical practices you have to win "street cred" with the
                                  technical team and devote most of your attention to them and their
                                  problems. Coaches often find themselves too focused on organizational
                                  change to do that effectively.

                                  I have also encountered a lot of teams that are trying Scrum but XP
                                  practices aren't even on their radar screen. However, most of these
                                  teams are doing Scrum straight out of the book (or CSM course) without
                                  any coaching. I don't know any experienced coaches who don't recommend
                                  XP practices. I certainly don't know any coaches who recommend against
                                  them (I've met a few who will say that they aren't strictly necessary.
                                  Those few still recommend them, however.)
                                Your message has been successfully submitted and would be delivered to recipients shortly.