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

Scrum is bad for employees (apparently)

Expand Messages
  • Richard Banks
    I have to share this with everyone... I ve been running scrum effectively now for about 6 months and apart from the occasional stakeholder trying to override
    Message 1 of 18 , Jul 31, 2006
    • 0 Attachment

      I have to share this with everyone…

       

      I’ve been running scrum effectively now for about 6 months and apart from the occasional stakeholder trying to override the product owner it’s truly bedded down and delivery real business value to the company.  Anyway, I had a couple of resignations from my staff last Friday – which was the conclusion of our last sprint.

       

      The first was because scrum makes people accountable for their work and exposes them.  Employee A is a difficult person who only has two ways of estimating any job in a sprint.  It’s either 8 hours or the entire sprint – no middle ground, no thought given to what the job might involve.  “That’s all there is and don’t tell me otherwise because I’m the one who has to deliver”.  The grief I had trying to get this bloke to stop being a child and act like a near-normal adult!!  He’s the kind of developer who doesn’t like others code reviewing their work, who thinks they know better than everyone else and who, because of their superior brain power, knows that of course the rules don’t apply to them.

       

      Well the pressure finally hit the limit and the resignation came and the thing that got them out the door was that scrum was a “stupid process”.  It’s apparently stupid because making teams self organizing and self managing means that the boss doesn’t have to do anything anymore.  Oh, and of course it’s stupid because you have to tell everyone else what you’ve been doing and you’ve got to talk to the rest of the team each day and the rest of the team are dumb because I’m so smart and I could do a better job than any one else on my own in my spare time.

       

      I thanked God big time for relieving me of this pain in the neck!  And I got big smiles from the rest of my staff when I let them know he was gone.

       

      Employee B (who just happened to be mentored by Employee A) left because “scrum is too restrictive”.  “What do you mean?” I asked innocently.  “Well“, came the reply, “when I have to do a job I really like to investigate it, to understand what’s going on deep in the code, to really get a feel for the inner workings of the problem and the intricacies involved.  Having to deliver every 2 weeks means that I don’t really have time to do a lot of investigation.  There are a lot of things I do at home that could really improve the product and I don’t get to try them here because we keep having to do things from the backlog”.   Translation:  I can’t muck around and play as much as I used to.  Why don’t I get to decide on my own how the product works. Scrum means I’m accountable for my time and I don’t like that.

       

      The moral to the story?  Scrum is obviously really bad for your employees – after all it makes them accountable, visible and efficient and no employee wants that to happen (well, at least the bad ones don’t).

       

      P.S. As you may have inferred I didn’t exactly cry myself to sleep on Friday night.

       

      - Richard.

      http://richardsbraindump.blogspot.com

    • Paul Hodgetts
      ... It does sound like Employee A was not in the right environment for either him or your team. I think Scrum/agile does often produce a fundamental culture
      Message 2 of 18 , Jul 31, 2006
      • 0 Attachment
        Richard Banks wrote:

        > Employee A is a difficult person [...]

        It does sound like Employee A was not in the right environment
        for either him or your team. I think Scrum/agile does often
        produce a fundamental culture change over time, and the new
        culture may not be right for all the existing team members.
        I've see a good number of organizations and individuals who
        are unwilling to deal with a mismatch. Looks like you did.

        > Employee B ... left because "scrum is too restrictive".
        > [...]
        > Having to deliver every 2 weeks means that I don't really
        > have time to do a lot of investigation. There are a lot of
        > things I do at home that could really improve the product
        > and I don't get to try them here because we keep having to
        > do things from the backlog". Translation: I can't muck
        > around and play as much as I used to. Why don't I get to
        > decide on my own how the product works. Scrum means I'm
        > accountable for my time and I don't like that.

        This might be worth a little retrospecting on. While I'm on
        board with the notion that as team members we can't just be
        going off and doing stuff that isn't in alignment with the
        team and/or doesn't contribute to the real sprint goals, I'd
        also be a little concerned if team members felt they were so
        hell-bent on delivering features that there was no time to
        try and improve things by introducing and experimenting with
        new ideas. Does your team have a mechanism for introducing
        new things? Is there any time allocated for experiments and
        learning? Might be worth a thought or two...

        Paul
        -----
        Paul Hodgetts -- CEO, Coach, Trainer, Consultant
        Agile Logic -- www.agilelogic.com
        Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
        Complete solutions for adopting agile processes, Scrum and XP.
      • Richard Banks
        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Paul Hodgetts Sent: Tuesday, 1 August 2006 2:37 p.m. To:
        Message 3 of 18 , Jul 31, 2006
        • 0 Attachment

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Paul Hodgetts
          Sent: Tuesday, 1 August 2006 2:37 p.m.
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Scrum is bad for employees (apparently)

           

          […]


          This might be worth a little retrospecting on. […] I'd
          also be a little concerned if team members felt they were so
          hell-bent on delivering features that there was no time to
          try and improve things by introducing and experimenting with
          new ideas. Does your team have a mechanism for introducing
          new things? Is there any time allocated for experiments and
          learning? Might be worth a thought or two...

          Not only do I get teams to include buffer in their normal sprint estimates for improvements, refactorings, etc but I also have an entire team devoted to just that - the “Core” team whose mandate is to improve the internals of the product, investigate AJAX, SOA, and all the other buzzwords and if/how we can incorporate these into the product in a meaningful way.  The members of this team are rotated through based on a mix of their delivery performance, technical skills and time spent in the trenches.  Effectively if you’re do a good job you get some time on this team as a reward allowing you to exploring new ideas and to spend some time at the cutting edge before being thrown back into the real world again.

          Employee B was just a poor developer who felt the pressure to perform and was exposed by scrum.  The gap between him and all the other developers became more and more apparent the more sprints we completed.  Under “normal” development environments he would have been able to hide a lot better and explain away slow performance as investigative work.

          - Richard

          http://richardsbraindump.blogspot.com

        • PaulOldfield1@aol.com
          (responding to Richard) (I wrote this before reading the reply from the other Paul; I ve added a postscript) ... Don t take this as criticism, just something
          Message 4 of 18 , Aug 1, 2006
          • 0 Attachment
            (responding to Richard)
             
            (I wrote this before reading the reply from the other Paul; I've added
            a postscript)
             
            > ...Anyway, I had a couple of resignations from my staff last
            Friday
            > – which was the conclusion of our last sprint.
             
            Don't take this as criticism, just something you may want to think
            about.
             
            Suppose you had to continue working with these folk?  How would
            you go about changing their attitudes?
             
            The reason I mention this is that if you had that option, you would
            have two ways of dealing with the situation and could choose which
            was more appropriate.  Having a choice is always valuable.
            I guess it's up to you to decide whether it's worth the cost incurred
            in taking that skill on board... or using a third party with that skill.
             
            It's hard to say from the limited report, but your ex-employee B
            might have been worth the effort.  Indeed, where one has to live
            with the person, one might find ex-employee A not entirely
            intractable.
             
            Paul Oldfield.
             
            (postscript)
            >
            style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Employee B was just a poor developer who felt the pressure to
            > perform and was exposed by scrum.  The gap between him and
            > all the other developers became more and more apparent the more
            > sprints we completed.  Under “normal” development environments
            > he
            would have been able to hide a lot better and explain away
            > slow performance as investigative work
             
            Do you censure or reward performance for the team as a whole,
            or for individuals?  Scrum is good at exposing problems.  We get
            to choose how to address them.  You might find Alistair Cockburn's
            writings on "Personal Safety" (e.g. in Crystal Clear) worth reading.
             
             
          • Ken Schwaber
            I expect 20% turnover in professionals and 40% turnover in management as Scrum gets implemented. Ken _____ From: scrumdevelopment@yahoogroups.com
            Message 5 of 18 , Aug 1, 2006
            • 0 Attachment

              I expect 20% turnover in professionals and 40% turnover in management as Scrum gets implemented.

              Ken

               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Richard Banks
              Sent: Monday, July 31, 2006 6:46 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Scrum is bad for employees (apparently)

               

              I have to share this with everyone…

               

              I’ve been running scrum effectively now for about 6 months and apart from the occasional stakeholder trying to override the product owner it’s truly bedded down and delivery real business value to the company.  Anyway, I had a couple of resignations from my staff last Friday – which was the conclusion of our last sprint.

               

              The first was because scrum makes people accountable for their work and exposes them.  Employee A is a difficult person who only has two ways of estimating any job in a sprint.  It’s either 8 hours or the entire sprint – no middle ground, no thought given to what the job might involve.  “That’s all there is and don’t tell me otherwise because I’m the one who has to deliver”.  The grief I had trying to get this bloke to stop being a child and act like a near-normal adult!!  He’s the kind of developer who doesn’t like others code reviewing their work, who thinks they know better than everyone else and who, because of their superior brain power, knows that of course the rules don’t apply to them.

               

              Well the pressure finally hit the limit and the resignation came and the thing that got them out the door was that scrum was a “stupid process”.  It’s apparently stupid because making teams self organizing and self managing means that the boss doesn’t have to do anything anymore.  Oh, and of course it’s stupid because you have to tell everyone else what you’ve been doing and you’ve got to talk to the rest of the team each day and the rest of the team are dumb because I’m so smart and I could do a better job than any one else on my own in my spare time.

               

              I thanked God big time for relieving me of this pain in the neck!  And I got big smiles from the rest of my staff when I let them know he was gone.

               

              Employee B (who just happened to be mentored by Employee A) left because “scrum is too restrictive”.  “What do you mean?” I asked innocently.  “Well“, came the reply, “when I have to do a job I really like to investigate it, to understand what’s going on deep in the code, to really get a feel for the inner workings of the problem and the intricacies involved.  Having to deliver every 2 weeks means that I don’t really have time to do a lot of investigation.  There are a lot of things I do at home that could really improve the product and I don’t get to try them here because we keep having to do things from the backlog”.   Translation:  I can’t muck around and play as much as I used to.  Why don’t I get to decide on my own how the product works. Scrum means I’m accountable for my time and I don’t like that.

               

              The moral to the story?  Scrum is obviously really bad for your employees – after all it makes them accountable, visible and efficient and no employee wants that to happen (well, at least the bad ones don’t).

               

              P.S. As you may have inferred I didn’t exactly cry myself to sleep on Friday night.

               

              - Richard.

              http://richardsbrai ndump.blogspot. com

            • Keith Sader
              Interesting, do you think that there s anything that can/should be done to change that? What have you found to be the main causes of said turnover? thanks, ...
              Message 6 of 18 , Aug 1, 2006
              • 0 Attachment
                Interesting, do you think that there's anything that can/should be done to change that?

                What have you found to be the main causes of said turnover?

                thanks,

                On 8/1/06, Ken Schwaber <ken.schwaber@...> wrote:

                I expect 20% turnover in professionals and 40% turnover in management as Scrum gets implemented.

                Ken


                --
                Keith Sader
                ksader@...
                http://www.sader-family.org/roller/page/ksader
                (coming back)http://www.saderfamily.org/roller/page/ksader
              • woynam
                Unfortunately, my experience has shown that as Scrum get adopted, 20% of Scrum practices will be ignored by the professionals, and 40% of the practices will be
                Message 7 of 18 , Aug 1, 2006
                • 0 Attachment
                  Unfortunately, my experience has shown that as Scrum get adopted, 20%
                  of Scrum practices will be ignored by the professionals, and 40% of
                  the practices will be ignored by management, with little turnover.

                  Sigh.

                  They'll call it 'Scrum', but they won't really embrace the principles.
                  Too many organizations find it easier to bend the process to fit their
                  existing culture, than fundamentally change the staff, or replace them.

                  Mark


                  --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                  <ken.schwaber@...> wrote:
                  >
                  > I expect 20% turnover in professionals and 40% turnover in management as
                  > Scrum gets implemented.
                  >
                  > Ken
                  > _____
                  >
                  > From: scrumdevelopment@yahoogroups.com
                  > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Richard Banks
                  > Sent: Monday, July 31, 2006 6:46 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] Scrum is bad for employees (apparently)
                  >
                  >
                  >
                  > I have to share this with everyone.
                  >
                  >
                  >
                  > I've been running scrum effectively now for about 6 months and apart
                  from
                  > the occasional stakeholder trying to override the product owner it's
                  truly
                  > bedded down and delivery real business value to the company.
                  Anyway, I had
                  > a couple of resignations from my staff last Friday - which was the
                  > conclusion of our last sprint.
                  >
                  >
                  >
                  > The first was because scrum makes people accountable for their work and
                  > exposes them. Employee A is a difficult person who only has two ways of
                  > estimating any job in a sprint. It's either 8 hours or the entire
                  sprint -
                  > no middle ground, no thought given to what the job might involve.
                  "That's
                  > all there is and don't tell me otherwise because I'm the one who has to
                  > deliver". The grief I had trying to get this bloke to stop being a
                  child
                  > and act like a near-normal adult!! He's the kind of developer who
                  doesn't
                  > like others code reviewing their work, who thinks they know better than
                  > everyone else and who, because of their superior brain power, knows
                  that of
                  > course the rules don't apply to them.
                  >
                  >
                  >
                  > Well the pressure finally hit the limit and the resignation came and the
                  > thing that got them out the door was that scrum was a "stupid process".
                  > It's apparently stupid because making teams self organizing and self
                  > managing means that the boss doesn't have to do anything anymore.
                  Oh, and
                  > of course it's stupid because you have to tell everyone else what you've
                  > been doing and you've got to talk to the rest of the team each day
                  and the
                  > rest of the team are dumb because I'm so smart and I could do a
                  better job
                  > than any one else on my own in my spare time.
                  >
                  >
                  >
                  > I thanked God big time for relieving me of this pain in the neck!
                  And I got
                  > big smiles from the rest of my staff when I let them know he was gone.
                  >
                  >
                  >
                  > Employee B (who just happened to be mentored by Employee A) left because
                  > "scrum is too restrictive". "What do you mean?" I asked innocently.
                  > "Well", came the reply, "when I have to do a job I really like to
                  > investigate it, to understand what's going on deep in the code, to
                  really
                  > get a feel for the inner workings of the problem and the intricacies
                  > involved. Having to deliver every 2 weeks means that I don't really
                  have
                  > time to do a lot of investigation. There are a lot of things I do
                  at home
                  > that could really improve the product and I don't get to try them here
                  > because we keep having to do things from the backlog". Translation: I
                  > can't muck around and play as much as I used to. Why don't I get to
                  decide
                  > on my own how the product works. Scrum means I'm accountable for my
                  time and
                  > I don't like that.
                  >
                  >
                  >
                  > The moral to the story? Scrum is obviously really bad for your
                  employees -
                  > after all it makes them accountable, visible and efficient and no
                  employee
                  > wants that to happen (well, at least the bad ones don't).
                  >
                  >
                  >
                  > P.S. As you may have inferred I didn't exactly cry myself to sleep
                  on Friday
                  > night.
                  >
                  >
                  >
                  > - Richard.
                  >
                  > http://richardsbraindump.blogspot.com
                  >
                • David H.
                  ... Where is the coach or Scrum Master then? This is one of the things I will not have nor did I ever allow them. Of course, as an external coach, it is easier
                  Message 8 of 18 , Aug 1, 2006
                  • 0 Attachment
                    On 01/08/06, woynam <woyna@...> wrote:
                    >
                    > Unfortunately, my experience has shown that as Scrum get adopted, 20%
                    > of Scrum practices will be ignored by the professionals, and 40% of
                    > the practices will be ignored by management, with little turnover.
                    >
                    Where is the coach or Scrum Master then?
                    This is one of the things I will not have nor did I ever allow them.
                    Of course, as an external coach, it is easier for you to break with
                    paradimes, but still. You need to put your foot down. Some rules are
                    not broken, period.

                    > Sigh.
                    >
                    > They'll call it 'Scrum', but they won't really embrace the principles.
                    > Too many organizations find it easier to bend the process to fit their
                    > existing culture, than fundamentally change the staff, or replace them.
                    >
                    Yepp, but as I said above, if you do not allow yourself to be bent,
                    then you can make a difference. Sometimes being laid off because you
                    believed in something is not such a bad thing. I know that it scored
                    me a job once.

                    -d

                    --
                    Sent from gmail so do not trust this communication.
                    Do not send me sensitive information here, ask for my none-gmail accounts.

                    "Therefore the considerations of the intelligent always include both
                    benefit and harm." - Sun Tzu
                  • Keith Sader
                    ... Yes, and as an external coach, I can see where that s political suicide unless you have the support of a large political ally. ... Yes, but how many times
                    Message 9 of 18 , Aug 1, 2006
                    • 0 Attachment
                      >
                      > Where is the coach or Scrum Master then?
                      > This is one of the things I will not have nor did I ever allow them.
                      > Of course, as an external coach, it is easier for you to break with
                      > paradimes, but still. You need to put your foot down. Some rules are
                      > not broken, period.

                      Yes, and as an external coach, I can see where that's political
                      suicide unless you have the support of a large political ally.


                      > Yepp, but as I said above, if you do not allow yourself to be bent,
                      > then you can make a difference. Sometimes being laid off because you
                      > believed in something is not such a bad thing. I know that it scored
                      > me a job once.

                      Yes, but how many times did it deny you a job?(I'm not saying that
                      being denied those jobs was a bad thing on the whole)

                      thanks,
                      --
                      Keith Sader
                      ksader@...
                      http://www.sader-family.org/roller/page/ksader
                      (coming back)http://www.saderfamily.org/roller/page/ksader
                    • David H.
                      ... Usually the one big alley I ever had was money. That guy costs us a shot load of cash, he has a good reputation, maybe we should start listening to him
                      Message 10 of 18 , Aug 1, 2006
                      • 0 Attachment
                        On 01/08/06, Keith Sader <ksader@...> wrote:
                        > >
                        > > Where is the coach or Scrum Master then?
                        > > This is one of the things I will not have nor did I ever allow them.
                        > > Of course, as an external coach, it is easier for you to break with
                        > > paradimes, but still. You need to put your foot down. Some rules are
                        > > not broken, period.
                        >
                        > Yes, and as an external coach, I can see where that's political
                        > suicide unless you have the support of a large political ally.
                        >
                        Usually the one big alley I ever had was money.

                        "That guy costs us a shot load of cash, he has a good reputation,
                        maybe we should start listening to him"
                        >
                        > > Yepp, but as I said above, if you do not allow yourself to be bent,
                        > > then you can make a difference. Sometimes being laid off because you
                        > > believed in something is not such a bad thing. I know that it scored
                        > > me a job once.
                        >
                        > Yes, but how many times did it deny you a job?(I'm not saying that
                        > being denied those jobs was a bad thing on the whole)
                        >
                        To be honest, I cannot recall that ever happening. In the European
                        market people do honour integrity and honesty. However, as you pointed
                        out, if an employer wanted to bend me and the processes I know to fit
                        their wierd understanding of what work should be, I would not work
                        there.,

                        -d

                        --
                        Sent from gmail so do not trust this communication.
                        Do not send me sensitive information here, ask for my none-gmail accounts.

                        "Therefore the considerations of the intelligent always include both
                        benefit and harm." - Sun Tzu
                      • aefager
                        ... and ... ways of ... I m ... bloke ... kind ... Ahh, the Cowboy Coder. I am guessing that this gentleman was difficult even before Scrum came about.
                        Message 11 of 18 , Aug 1, 2006
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, "Richard Banks"
                          <richard.banks@...> wrote:
                          > The first was because scrum makes people accountable for their work
                          and
                          > exposes them. Employee A is a difficult person who only has two
                          ways of
                          > estimating any job in a sprint. It's either 8 hours or the entire
                          > sprint - no middle ground, no thought given to what the job might
                          > involve. "That's all there is and don't tell me otherwise because
                          I'm
                          > the one who has to deliver". The grief I had trying to get this
                          bloke
                          > to stop being a child and act like a near-normal adult!! He's the
                          kind
                          > of developer who doesn't like others code reviewing their work, who
                          > thinks they know better than everyone else and who, because of their
                          > superior brain power, knows that of course the rules don't apply to
                          > them.
                          Ahh, the Cowboy Coder. I am guessing that this gentleman was
                          difficult even before Scrum came about. Bluster and rigidity on one
                          side, breaks rules that were obstacles in his eyes on the othr side.

                          Sorry that you had to go through that. I am guessing you did not
                          have firing power there, because that kind of attitude, in front of
                          the group during a planning session, with the client, product owner
                          and other team members there, just by being accepted, was doing harm
                          to the team.

                          Why was Employee B given to Employee A as a mentor? All their views
                          of the process were getting clouded by A's dislike of the system, and
                          they probably never had a chance.

                          I think Employee B should have been given more of a chance, but that
                          Employee A should have been booted long ago.

                          > - Richard.
                          >
                          > http://richardsbraindump.blogspot.com
                          >
                        • woynam
                          ... The SMs attended the certification class, but as many of you have experienced, some of them simply didn t get it , i.e. the agile principles. At other
                          Message 12 of 18 , Aug 1, 2006
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...> wrote:
                            >
                            > On 01/08/06, woynam <woyna@...> wrote:
                            > >
                            > > Unfortunately, my experience has shown that as Scrum get adopted, 20%
                            > > of Scrum practices will be ignored by the professionals, and 40% of
                            > > the practices will be ignored by management, with little turnover.
                            > >
                            > Where is the coach or Scrum Master then?
                            > This is one of the things I will not have nor did I ever allow them.
                            > Of course, as an external coach, it is easier for you to break with
                            > paradimes, but still. You need to put your foot down. Some rules are
                            > not broken, period.

                            The SMs attended the certification class, but as many of you have
                            experienced, some of them simply didn't "get it", i.e. the agile
                            principles. At other times, the SMs felt powerless, since they don't
                            actually wield any power. If the team chose not to self organize, or
                            ignore agile practices, there wasn't much the SM could do, especially
                            if the managers weren't themselves 100% committed. Often the managers
                            would pull team members temporarily off the team to work on other
                            problems, violating the principles of agile.

                            The sad reality, as many of us have experienced, is that it's easier
                            to adopt the agile label, and use a few practices, e.g. daily meeting,
                            than learn what it really means to be agile.

                            Mark

                            >
                            > > Sigh.
                            > >
                            > > They'll call it 'Scrum', but they won't really embrace the principles.
                            > > Too many organizations find it easier to bend the process to fit their
                            > > existing culture, than fundamentally change the staff, or replace
                            them.
                            > >
                            > Yepp, but as I said above, if you do not allow yourself to be bent,
                            > then you can make a difference. Sometimes being laid off because you
                            > believed in something is not such a bad thing. I know that it scored
                            > me a job once.
                            >
                          • Richard Banks
                            (responding to Paul) Do you censure or reward performance for the team as a whole, or for individuals? Scrum is good at exposing problems. We get to choose
                            Message 13 of 18 , Aug 1, 2006
                            • 0 Attachment

                               (responding to Paul)

                                

                              Do you censure or reward performance for the team as a whole,

                              or for individuals?  Scrum is good at exposing problems.  We get

                              to choose how to address them.  You might find Alistair Cockburn's

                              writings on "Personal Safety" (e.g. in Crystal Clear) worth reading.

                               

                              I reward both individuals and teams.  I’ve always made it clear that the team succeeds together or fails together and that I don’t care if a poor team member causes a sprint to fail because it’s “all for one and one for all”.  On the flip side I am also very much aware of the performance of individuals as I want to make sure that good people don’t feel badly done by because they struggle with poorly performing team members.

                               

                              Thanks for the tip on the book.  I’ll head off to the shops at lunch and have a look.

                               

                              - Richard.

                            • Stacia Heimgartner
                              I have also encountered some turnover with teams adopting agile. I d have to venture out and say that something must be working if a couple of people cannot
                              Message 14 of 18 , Aug 1, 2006
                              • 0 Attachment
                                I have also encountered some turnover with teams adopting agile. I'd have to venture out and say that something must be working if a couple of people cannot stand what it exposes. It's my opinion that these are the same people who were probably hiding behind bureacracy all along.
                                 
                                I've experienced the Cowboy Coder, the Houdini, the Bad ScrumMaster, and the Sneaky Product Owner - and some companies allow this bad behavior in the name of self-managed teams. I have also seen the Turbulent Tester and this person remains with the team because he has proven to be the (loud) voice of quality and reason on the team. Sometimes not all 'bad' traits are bad; giving people a chance is certainly worth what comes out of their own self-discoveries. And, also, not all can make it through the change.
                                 
                                Not everyone will agree with a new methodology all of the time. That goes for waterfall or agile. And this thread is also correct in stating that many teams/programs/companies adopt the agile designer label, but alas, there's nobody filling out the pants. Seeing lots of this lately. It takes a willing leader (at the director or C level) to stick her neck out and believe in the principles - not just sign the checkbook.
                                 
                                 
                                 
                                 
                              • Nicholas Cancelliere
                                We ve had some turnover at my company after adopting scrum. We ve been through two developers and a QA tester. It is hard for some people to get out of old
                                Message 15 of 18 , Aug 1, 2006
                                • 0 Attachment

                                  We've had some turnover at my company after adopting scrum.  We've been through two developers and a QA tester.  It is hard for some people to get out of old habits.  For the developers the idea of having to write code that works (unit tested, and checked into the build) and always being able to have a near shippable product is a big change.  They're used to letting guts hang out and not have to worry about the mess until the mad rush towards the end, and let QA find all the issues and report them back to be fixed!

                                  Our QA manager was never able to relax and allow for acceptance testing early in the iteration.  They insisted on testing everything at the end when the code was completely "frozen."


                                  On Jul 31, 2006, at 5:45 PM, Richard Banks wrote:


                                  I have to share this with everyone…

                                   

                                  I’ve been running scrum effectively now for about 6 months and apart from the occasional stakeholder trying to override the product owner it’s truly bedded down and delivery real business value to the company.  Anyway, I had a couple of resignations from my staff last Friday – which was the conclusion of our last sprint.

                                   

                                  The first was because scrum makes people accountable for their work and exposes them.  Employee A is a difficult person who only has two ways of estimating any job in a sprint.  It’s either 8 hours or the entire sprint – no middle ground, no thought given to what the job might involve.  “That’s all there is and don’t tell me otherwise because I’m the one who has to deliver”.  The grief I had trying to get this bloke to stop being a child and act like a near-normal adult!!  He’s the kind of developer who doesn’t like others code reviewing their work, who thinks they know better than everyone else and who, because of their superior brain power, knows that of course the rules don’t apply to them.

                                   

                                  Well the pressure finally hit the limit and the resignation came and the thing that got them out the door was that scrum was a “stupid process”.  It’s apparently stupid because making teams self organizing and self managing means that the boss doesn’t have to do anything anymore.  Oh, and of course it’s stupid because you have to tell everyone else what you’ve been doing and you’ve got to talk to the rest of the team each day and the rest of the team are dumb because I’m so smart and I could do a better job than any one else on my own in my spare time.

                                   

                                  I thanked God big time for relieving me of this pain in the neck!  And I got big smiles from the rest of my staff when I let them know he was gone.

                                   

                                  Employee B (who just happened to be mentored by Employee A) left because “scrum is too restrictive”.  “What do you mean?” I asked innocently.  “Well“, came the reply, “when I have to do a job I really like to investigate it, to understand what’s going on deep in the code, to really get a feel for the inner workings of the problem and the intricacies involved.  Having to deliver every 2 weeks means that I don’t really have time to do a lot of investigation.  There are a lot of things I do at home that could really improve the product and I don’t get to try them here because we keep having to do things from the backlog”.   Translation:  I can’t muck around and play as much as I used to.  Why don’t I get to decide on my own how the product works. Scrum means I’m accountable for my time and I don’t like that.

                                   

                                  The moral to the story?  Scrum is obviously really bad for your employees – after all it makes them accountable, visible and efficient and no employee wants that to happen (well, at least the bad ones don’t).

                                   

                                  P.S. As you may have inferred I didn’t exactly cry myself to sleep on Friday night.

                                   

                                  - Richard.

                                  http://richardsbraindump.blogspot.com



                                • Brent Barton
                                  ... Agree on Stacia s statements. When these become visible issues, it is important to get these issues addressed using open, honest, respectful methods.
                                  Message 16 of 18 , Aug 1, 2006
                                  • 0 Attachment
                                    Stacia wrote:

                                    > I've experienced the Cowboy Coder, the Houdini, the Bad ScrumMaster, and the Sneaky Product Owner - and some companies allow this bad behavior in the name of self-managed teams. I have also seen the Turbulent Tester and this person remains with the team because he has proven to be the (loud) voice of quality and reason on the team. Sometimes not all 'bad' traits are bad; giving people a chance is certainly worth what comes out of their own self-discoveries. And, also, not all can make it through the change.

                                    Agree on Stacia's statements. When these become visible issues, it is important to get these issues addressed using open, honest, respectful methods. "Fearless Change" describes the late adopter and the laggard. Bringing along a late adopter has been very beneficial in my experience as well as providing the Skeptic role that helps us be thorough.


                                    Brent Barton
                                  • dwsmtnview
                                    ... That s one possible translation. I hope you allowed for other possibilities. I like to ... understand what s going on deep in the code might mean I
                                    Message 17 of 18 , Aug 1, 2006
                                    • 0 Attachment
                                      Richard Banks writes:

                                      > Employee B (who just happened to be mentored by Employee A)
                                      > left because "scrum is too restrictive". "What do you mean?"
                                      > asked innocently. "Well", came the reply, "when I have to do
                                      > a job I really like to investigate it, to understand what's
                                      > going on deep in the code, to really get a feel for the inner
                                      > workings of the problem and the intricacies involved. Having
                                      > to deliver every 2 weeks means that I don't really have time
                                      > to do a lot of investigation. There are a lot of things I do
                                      > at home that could really improve the product and I don't
                                      > get to try them here because we keep having to do things from
                                      > the backlog".
                                      >
                                      > Translation: I can't muck around and play as much as I used
                                      > to. Why don't I get to decide on my own how the product works.
                                      > Scrum means I'm accountable for my time and I don't like that.

                                      That's one possible translation. I hope you allowed for other
                                      possibilities. "I like to ... understand what's going on deep
                                      in the code" might mean "I don't understand what's going on
                                      deep in _this_ code." That could say something about employee
                                      B, or it may say something about the state of the code base.
                                      Sometimes it's the newer employees (I'm assuming B was a
                                      newer, based on his being mentored) who are the first to
                                      notice a design or refactoring deficit that the old-timers
                                      have grown numb to.

                                      "There are things that could improve our code base that I
                                      don't get a chance to try" can also mean "This code base is
                                      stale and we're not letting in new ideas". If you're one of
                                      the old hands who had the original ideas, this can be hard
                                      to hear and easy to dismiss. But it is worth checking out,
                                      since a stale, debt-ridden code base can be a barrier to
                                      lots of things, including bringing new people in to the
                                      team. This might be a good agenda item for your team's next
                                      retrospective.

                                      Dave
                                    • Paul Beckford
                                      ... Hi Dave, Not wanting to speak for Richard, but yes those are indeed alternative translations and possibilities worth exploring in some instances. In my
                                      Message 18 of 18 , Aug 1, 2006
                                      • 0 Attachment
                                        dwsmtnview wrote:

                                        > Richard Banks writes:
                                        >
                                        > > Translation: I can't muck around and play as much as I used
                                        > > to. Why don't I get to decide on my own how the product works.
                                        > > Scrum means I'm accountable for my time and I don't like that.
                                        >
                                        > That's one possible translation. I hope you allowed for other
                                        > possibilities. "I like to ... understand what's going on deep
                                        > in the code" might mean "I don't understand what's going on
                                        > deep in _this_ code." That could say something about employee
                                        > B, or it may say something about the state of the code base.
                                        > Sometimes it's the newer employees (I'm assuming B was a
                                        > newer, based on his being mentored) who are the first to
                                        > notice a design or refactoring deficit that the old-timers
                                        > have grown numb to.
                                        >
                                        > Dave
                                        >



















                                        Hi Dave,

                                        Not wanting to speak for Richard, but yes those are indeed alternative
                                        translations and possibilities worth exploring in some instances. In my
                                        experience a disruptive team member can unbalance the team and cause
                                        considerable pain for everyone. Usually it doesn't take much people
                                        management skills to determine whether an individual is genuinely trying
                                        to make a postive contribution and needs help or whether they are hell
                                        bent on being disruptive.

                                        When it is the latter IMO as a leader you must act, and act quickly. A
                                        good analogy IMO is sport. A good coach doesn't hesitate in getting rid
                                        of a player who is disrupting the team. If you do not act, you
                                        jeopardise your credability and trust with the other team members and in
                                        so doing reduce your effectiveness as a leader. After all who wants to
                                        follow someone unable to make decisions?

                                        BTW. Acting may mean exploring the problem as a team, and deciding that
                                        as a team we will help and address the concerns of employee B, but if
                                        after a while the team concensus is still that employee B is a pain,
                                        then that person should go.

                                        Paul.
                                      Your message has been successfully submitted and would be delivered to recipients shortly.