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

Re: [scrumdevelopment] Re: Getting Team Members Out of "Me Mentality"

Expand Messages
  • dan mcdonnell
    Lowell, Agreed we just came to the same conclusion that we needed to update performance objectives with Scrum. I am in the process of writing performance goals
    Message 1 of 11 , Sep 2, 2006
      Lowell,
      Agreed we just came to the same conclusion that we
      needed to update performance objectives with Scrum. I
      am in the process of writing performance goals for a
      large scrum team, do you have anything to share with
      the group on what you have done in the past? Thanks

      --- Lowell Lindstrom <lowell@...> wrote:

      > Steve's guidance resonates with me as a good short
      > term, survive-the-release
      > solution. In this case, there are limits as to how
      > far you can push since
      > their departure from the team probably risks the
      > release more than their
      > current "me" behavior. Anything that can help them
      > feel more ownership and
      > importance is likely to help.
      >
      >
      >
      > Over time, however, the "me mentality" will become
      > the boat anchor on your
      > agile cruise. You'll need those individuals to
      > participate or they'll
      > limit everyone else. If they can't change and the
      > organization is committed
      > to being agile, then it is no longer a good cultural
      > fit and the sooner that
      > is resolved the better for everyone.
      >
      >
      >
      > As the CSM, here are some things I would keep in
      > mind as I move forward:
      >
      >
      >
      > - Does the organization above the team really
      > support agile and
      > teamwork? Lip service to teamwork has been around
      > forever and today's
      > environment is no different. In some organizations,
      > either knowingly or
      > not, middle managers just want it to get done and
      > will tolerate quite a bit
      > of latitude in the new (agile) process that teams
      > are being encouraged to
      > use. If the "me" individual(s) are going to get
      > support or indifference up
      > the chain (or with your Product Owner or key
      > stakeholders), then this will
      > be a difficult change to effect. In that case, you
      > very well may be stuck
      > with the "survival" approach.
      >
      >
      >
      > - What would you do if a developer started to
      > consistently check in
      > code that does not compile? If that sounds like a
      > completely different
      > level of infraction to you then lower your agility
      > rating by 5 points ;-).
      > Before long, not collaborating with your agile team
      > will be as unthinkable
      > as checking in code that does not compile or does
      > not have tests. For many
      > (most?) agile teams that is the case today.
      >
      >
      >
      > - Are the team ground rules clearly and
      > commonly understood? I was
      > working with a team that had embraced pair
      > programming and open workspace.
      > After a few months, some of the developers start
      > noting in the retrospective
      > that not everyone was pairing and in fact some were
      > going back to their
      > offices to do their work. Both violated the team's
      > ground rules. Upon
      > further review, it turned out that one of the
      > managers who was sensitive to
      > those that preferred the "quite cube" had told them
      > privately that they did
      > not have to work in the lab (an example of the first
      > bullet). Aside from
      > the manager's mistake, it left the team without a
      > commonly understood
      > expectation. Often even when you can't conceive of
      > there being a disconnect
      > or miscommunication, you'll find that it can be that
      > simple to solve. In
      > pair programming example, a simple re-clarification
      > of the expected rules
      > and how to deal with a few exceptions was all that
      > was required.
      >
      >
      >
      > - Modify performance review criteria. Most
      > organizations I am
      > working with are finding that the performance
      > expectations and goals need to
      > be updated to reflect the collaboration skills and
      > behaviors that critical
      > for agile to be successful. My preferred way to do
      > this is the involve the
      > team in determining how that should be expressed and
      > measured. After all,
      > they are the ones collaborating. Using this
      > approach reinforces the
      > confidence in self-organizing teams, not to mention
      > the improved
      > understanding and buy-in.
      >
      >
      >
      > Good luck!
      >
      >
      >
      > Lowell
      >
      > ___________________________
      >
      > Lowell Lindstrom
      >
      > oobeya group
      >
      > www.oobeyagroup.com
      >
      > email: lowell@...
      >
      > phone: 630.335.0889 fax: 630.547.4202
      >
      > MSN/Yahoo/Skype: lowelllindstrom
      >
      > AIM: lowell8281
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > 2b.
      >
      >
      >
      <http://groups.yahoo.com/group/scrumdevelopment/message/15834;_ylc=X3oDMTJyN
      >
      G90dGd0BF9TAzk3MzU5NzE1BGdycElkAzE1NjkwNjQEZ3Jwc3BJZAMxNjAyMjA5MDIxBG1zZ0lkA
      >
      zE1ODM0BHNlYwNkbXNnBHNsawN2bXNnBHN0aW1lAzExNTY4NzIzNzg->
      > Re: Getting Team
      > Members Out of "Me Mentality"
      >
      > Posted by: "Steve Ropa"
      >
      <mailto:theropas2@...?Subject=%20Re%3A%20Getting%20Team%20Members%20
      > Out%20of%20%22Me%20Mentality%22>
      > theropas2@...
      > <http://profiles.yahoo.com/steveropa> steveropa
      >
      > Tue Aug 29, 2006 9:32 am (PST)
      >
      > Hi Nick,
      >
      > One thing that I have found to help is to appeal to
      > their ego.
      > Each person is different, so it may or may not work
      > with your
      > gunslingers. I have enlisted their aid by asking
      > them to help
      > teach others how to stay up to date, or some other
      > such thing.
      > Prodding seldom works for me. I also have found that
      > trying to
      > change their nature is probably not worth the
      > effort. It would
      > be nice to turn them into "team players" but in
      > reality you need
      > to work within their mindset.
      >
      > Of course, that's the carrot. Sometimes you have to
      > use the
      > stick. "You can't sign up for more stories until you
      > update your
      > current status" might work. Do you have any official
      > authority
      > over these guys? It might come down to "my way or
      > the highway"
      > at some point, but I would only do that as a last
      > resort.
      >
      >
      > Steve
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    • urpenguin
      ... Do you really have a team or do you have a number of individuals assigned to work in a group? How was the team formed? Did they go through the team
      Message 2 of 11 , Sep 2, 2006
        --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
        <nicholas@...> wrote:
        >

        Do you really have a team or do you have a number of individuals
        assigned to work in a group?

        How was the team formed? Did they go through the team formation
        stages, "forming", "storming", "norming", "performing"? How do they
        manage conflict? Do the individuals trust the other people in the
        group?

        Until the group comes together as a team it will just be individuals
        working together as a group. A team embodies the concept of self-
        sacrifice. If people are more concerned about their own interests
        then results of the team then it won't be a true team.

        Cultivate trust.
        Create an environment that is open and honest - ideas and differences
        can be freely exchanged.
        Create a compelling vision in which all the people are willing to
        rally around.
        Provide a safe environment. If the environment is unsafe people will
        put up walls and barriers.


        >
        > We often debate the finer points of what Agile is on these
        forums.
        > This question is different - it's to ask about experiences folks
        > might of had in overcoming "me mentality."
        >
        > The group I'm working with right now is very new to Scurm.
        They're
        > on their 3rd sprint now - and while some team members are doing
        well
        > with updating their status on our information radiator (we use an
        > electronic one - RallyDev) others have to be constantly pushed or
        > reminded to update their status. It's important that members
        update
        > their stories because the team is geographically separated (US and
        > UK). [I've coached another team, at the same company, and never
        had
        > a problem like this with them.]
        >
        > I've noticed that the people who are best at updating their story
        > cards are the ones more social and naturally team oriented, while
        the
        > lone gun-slinger developers (lone wolf or "my code doesn't stink"
        > types) tend to not update anything unless you prod them. They
        feel
        > they're too busy (and implying too important) to spend time
        updating
        > their stories.
        >
        > Now it'd be great to say "well those are the wrong kind of people
        you
        > want on your team," but the reality is they're on the team.
        Anyone
        > have run into this problem before and how did you overcome it?
        I'm
        > trying to think of ways to get the people away from the "me
        > mentality" and only worrying about their own tasks and get them to
        > more actively own the sprint as a whole, as a team.
        >
        >
        > -Nick
        >
      • Brent Barton
        One thing that started to make a difference right away was: We formed a process Scrum team made of an executive sponsor, middle managers, team members. They
        Message 3 of 11 , Sep 2, 2006
          One thing that started to make a difference right away was:
           
          We formed a process Scrum team made of an executive sponsor, middle managers, team members.  They represented people in all stages of transition the organization was in. 
          The definition of done was an improvement that could be agreed to and implemented at the end of each 2 week Sprint.
           
          One of the many outputs was a cutlure statement that said:

          Everyone is part of a cross-functional team, fully responsible and with decision authority to complete the iteration successfully. 

          Anyone on the team who is struggling shall ask the team for help. 

          The team must commit to helping.

           
          Topics of amazing interest came up and people were very open to talk about career path solutions and team assessment.
           
          In retrospect, this was one of the key trainsitions in our organization.  We were already doing Scrum and Agile techniques but this seems to have become a pivotal transition.
           
          Over time, the team members migrated in and out, but we kept up the presentations to all and each time invited anyone who was interested to be involved as an oberver or as a team member.  After a quarter or so, it was time to move on and we disbanded.  Much of this has "stuck," almost two years later.
           
          Brent


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of urpenguin
          Sent: Saturday, September 02, 2006 10:52 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: Getting Team Members Out of "Me Mentality"

          --- In scrumdevelopment@ yahoogroups. com, Nicholas Cancelliere
          <nicholas@.. .> wrote:

          >

          Do you really have a team or do you have a number of individuals
          assigned to work in a group?

          How was the team formed? Did they go through the team formation
          stages, "forming", "storming", "norming", "performing" ? How do they
          manage conflict? Do the individuals trust the other people in the
          group?

          Until the group comes together as a team it will just be individuals
          working together as a group. A team embodies the concept of self-
          sacrifice. If people are more concerned about their own interests
          then results of the team then it won't be a true team.

          Cultivate trust.
          Create an environment that is open and honest - ideas and differences
          can be freely exchanged.
          Create a compelling vision in which all the people are willing to
          rally around.
          Provide a safe environment. If the environment is unsafe people will
          put up walls and barriers.

          >
          > We often debate the finer points of what Agile is on these
          forums.
          > This question is different - it's to ask about experiences folks
          > might of had in overcoming "me mentality."
          >
          > The group
          I'm working with right now is very new to Scurm.
          They're
          > on their
          3rd sprint now - and while some team members are doing
          well
          > with
          updating their status on our information radiator (we use an
          > electronic
          one - RallyDev) others have to be constantly pushed or
          > reminded to
          update their status. It's important that members
          update
          > their
          stories because the team is geographically separated (US and
          > UK). [I've
          coached another team, at the same company, and never
          had
          > a problem
          like this with them.]
          >
          > I've noticed that the people who are best
          at updating their story
          > cards are the ones more social and naturally
          team oriented, while
          the
          > lone gun-slinger developers (lone wolf or
          "my code doesn't stink"
          > types) tend to not update anything unless you
          prod them. They
          feel
          > they're too busy (and implying too important)
          to spend time
          updating
          > their stories.
          >
          > Now it'd be
          great to say "well those are the wrong kind of people
          you
          > want on
          your team," but the reality is they're on the team.
          Anyone
          > have run
          into this problem before and how did you overcome it?
          I'm
          > trying to
          think of ways to get the people away from the "me
          > mentality" and only
          worrying about their own tasks and get them to
          > more actively own the
          sprint as a whole, as a team.
          >
          >
          >
          -Nick
          >

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