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

Re: Getting Team Members Out of "Me Mentality"

Expand Messages
  • Lowell Lindstrom
    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
    Message 1 of 11 , Aug 30, 2006

      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.

      Re: Getting Team Members Out of "Me Mentality"

      Posted by: "Steve Ropa" theropas2@...   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

       

       

       

    • 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 2 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 3 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 4 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.