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

Getting Team Members Out of "Me Mentality"

Expand Messages
  • Nicholas Cancelliere
    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
    Message 1 of 11 , Aug 29, 2006
    • 0 Attachment
      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
    • Steve Ropa
      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
      Message 2 of 11 , Aug 29, 2006
      • 0 Attachment
        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

        Nicholas Cancelliere wrote:


        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


      • Bob Schatz
        This is the core of why agile takes so much work to get right. The approach I ve always used is to constantly work with the team to become a TEAM There is a
        Message 3 of 11 , Aug 29, 2006
        • 0 Attachment
          This is the core of why agile takes so much work to get right.

          The approach I've always used is to constantly work with the team to
          become a TEAM There is a set of stages a team goes through, each
          with it's own "test". This is where a good ScrumMaster is critical.
          Someone who is a good leader that will teach the team and work with
          them through exercises and observe their behavior so that they begin
          the journey to high-performance.

          The team, Product Owner, and the ScrumMaster (if they don't know
          this already), have to be coached and taught to become one unit
          working towards common goals, trusting each other, and depending on
          each other. Most importantly, they need to learn to resolve conflict.

          One only has to put themselves into the shoes of another person on a
          new Scrum team to understand the "me mentality". It's perfectly
          natural, but pushing isn't the answer...pulling is.

          Bob Schatz
          Agile Infusion LLC
          www.agileinfusion.com
          bobschatz@...
        • Abrachan
          Hi Nicolas, Once I was in a similar situation, in a very high profile team, where some of the team members were very cold to the team norms. What helped me
          Message 4 of 11 , Aug 29, 2006
          • 0 Attachment
            Hi Nicolas,

            Once I was in a similar situation, in a very high profile team,
            where some of the team members were very cold to the team norms.
            What helped me was, the practice of servant leadership. I started
            with the following famous 12 questions to my team members
            individually. I asked them to fill it up individually, and then
            based on these questions, we had periodic one to one meetings, where
            the focus was only on 'What we can do to improve the rating on the
            questionnaire?'. No work related stuff was discussed. At the end of
            the meeting commitments were obtained / given... Over a period of
            time, the teaming improved, primarily bacuase the trust levels were
            very high.

            The questionnaire we used;


            1) Do I know what is expected of me at work?

            2) Do I have the materials and equipment I need to do my work right?

            3) At work do I have the opportunity to do what I do best every day?

            4) In the last seven days, have I received recognition or praise for
            good work?

            5) Does my supervisor, or someone at work, seem to care about me as
            a person?

            6) Is there someone at work, who encourages my development?

            7) At work, do my opinions seem to count?

            8) Does the mission / purpose of my project make me feel like my
            work is important?

            9) Are my co-workers committed to do quality work?

            10) Do I have the best friend at work?

            11) In the last six months, have I talked with someone about my
            progress?

            12) At work, have I had opportunities to learn and grow?

            Iam sure that this approach will work in any knowledge worker team.


            I took these questions from the famous book 'First break all rules'
            by Marcus Buckingam and Curt Coffman

            Regards

            Abrachan
            www.abrachan.org









            --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
            <nicholas@...> wrote:
            >
            >
            > 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
            >
          • Tobias Mayer
            Hi Nick, Who is the updated status intended for? The team themselves, the Scrummaster, or some management group? If it is for the team (as it should be) are
            Message 5 of 11 , Aug 29, 2006
            • 0 Attachment
              Hi Nick,

              Who is the updated status intended for? The team themselves, the
              Scrummaster, or some management group? If it is for the team (as it
              should be) are the team members complaining about this? If so, why
              not let them figure out the solution for themselves? If this means
              a sprint failure or two then so be it. Failure, followed by healthy
              retrospective leads to improvement. On the other hand, if it is you
              (the Scrummaster, I am guessing) who is the only one concerned, then
              let it go. See what happens.

              I find it helpful to think of the sprint as a black box. Its input
              is a set of stories and its output is the product increment (working
              software). How the team gets from the input to the output is their
              business. Maybe they have ways of working that don't require tasks
              or status updates. Observe, and reflect back at the retrospetive.

              Teams improve by making their own mistakes, and in my experience
              they don't make many and they rarely repeat mistakes if allowed to
              resolve the problems themselves. If a team feel managed or
              directed, they take much, much longer to reach the "Performing"
              phase, and may actually never get there.

              I could be way off base here, as I don't know all the details of
              your reporting structure and your relationship to the team, etc. I
              simply offer this as an alternative way to look at the situation.

              Regards,
              Tobias


              --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere wrote:
              >
              >
              > 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
              >
            • Tobias Mayer
              Oops... ... they don t make many... That didn t come out right :-)). In my experience teams actually make loads of mistakes -- to begin with. And that s a
              Message 6 of 11 , Aug 29, 2006
              • 0 Attachment

                Oops...

                > Teams improve by making their own mistakes, and in my experience
                they don't make many...

                That didn't come out right :-)).  In my experience teams actually make loads of mistakes -- to begin with.  And that's a good thing.  But they quickly reduce the number  and the seriousness of their mistakes if they are allowed to inspect and adapt their own process as a self-organized, trusted, management-free team.

                Tobias


                --- In scrumdevelopment@yahoogroups.com, "Tobias Mayer" <tobyanon@...> wrote:
                >
                > Hi Nick,
                >
                > Who is the updated status intended for? The team themselves, the
                > Scrummaster, or some management group? If it is for the team (as it
                > should be) are the team members complaining about this? If so, why
                > not let them figure out the solution for themselves? If this means
                > a sprint failure or two then so be it. Failure, followed by healthy
                > retrospective leads to improvement. On the other hand, if it is you
                > (the Scrummaster, I am guessing) who is the only one concerned, then
                > let it go. See what happens.
                >
                > I find it helpful to think of the sprint as a black box. Its input
                > is a set of stories and its output is the product increment (working
                > software). How the team gets from the input to the output is their
                > business. Maybe they have ways of working that don't require tasks
                > or status updates. Observe, and reflect back at the retrospetive.
                >
                > Teams improve by making their own mistakes, and in my experience
                > they don't make many and they rarely repeat mistakes if allowed to
                > resolve the problems themselves. If a team feel managed or
                > directed, they take much, much longer to reach the "Performing"
                > phase, and may actually never get there.
                >
                > I could be way off base here, as I don't know all the details of
                > your reporting structure and your relationship to the team, etc. I
                > simply offer this as an alternative way to look at the situation.
                >
                > Regards,
                > Tobias
                >
                >
                ...

              • Thomas Eyde
                As a person who down-prioritize anything related to paperwork, I wonder: How inconvinient are these updates? Do they happen often? Are they too bureaucratic? A
                Message 7 of 11 , Aug 30, 2006
                • 0 Attachment
                  As a person who down-prioritize anything related to paperwork, I wonder:

                  How inconvinient are these updates?
                  Do they happen often?
                  Are they too bureaucratic?
                  A real pain to do?
                  Are they valuable to team the members?

                  --
                  Thomas

                  On 8/29/06, Nicholas Cancelliere <nicholas@...> wrote:


                  > 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).
                • 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 8 of 11 , Aug 30, 2006
                  • 0 Attachment

                    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 9 of 11 , Sep 2 8:53 AM
                    • 0 Attachment
                      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 10 of 11 , Sep 2 10:52 AM
                      • 0 Attachment
                        --- 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 11 of 11 , Sep 2 1:55 PM
                        • 0 Attachment
                          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.