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

Re: [XP] Team values

Expand Messages
  • Paul Beckford
    Hi, I ve experienced the same thing and had the same frustrations. Someone in the team said to me that you ve got to allow people to make their own mistakes.
    Message 1 of 45 , Dec 28, 2005
    • 0 Attachment
      Hi,

      I've experienced the same thing and had the same frustrations. Someone
      in the team said to me that you've got to allow people to make their own
      mistakes. So I did this, and people made mistakes and some learned from
      them, some didn't.Some people even ended up leaving. Some people just
      aren't comfortable with close scrutiny from their peers. Those who
      stayed became closer and began to develop a common understanding, mainly
      through pairing and retrospectives, much as Kent Beck recommends in his
      post.

      We did a team code walk through once - using a projector. But I'm sure
      that some saw this as a witch hunt and it my have hurried their leaving.

      Those who stayed became more tolerant of each other. I think this was a
      trust thing. People began to trust that everyone was doing their best
      for the team. Believing in this made us all able to give each other time
      and space to try out ideas, even when we didn't agree. BTW socialising
      as a team helped a lot too.

      Frustrating at times, but things have worked out. When the disgrutled
      people left, things got a lot easier.

      Paul.

      Fernando A. Cuenca wrote:

      >Hi,
      >
      >I'm leading a team into the adoption of agile practices. As expected, we are finding different challenges as we go along, but overall the situation is encouraging. I hope one day I'll be able to say that we are "fully XP compliant" (whatever that means! :-) but we are certainly not there yet.
      >
      >This week we faced a situation that has become a recurrent issue and that I'm still uncertain on how to handle it, so I was hoping that maybe somebody in this group could share some insight.
      >
      >This week's iteration included two stories about implementing some default initialization rules in a couple of custom controls we use in our web pages. Two developers decided to pair to work in one of the stories, and a third developer took the other, deciding to work alone (pair programming is a practice that hasn't been accepted for many members of the team.)
      >
      >This was the first time we needed to implement this kind of business rules, so they decided to have a quick meeting to discuss this problem and brainstorm ideas as to how to deal with it. But then, after that, each group went on its way, implementing its story in the way each of them thought it was best. At the end of the meeting there was no agreement on the design approach to use, nor was that their intention. We ended up with two perfectly valid designs for the same kind of artifact.
      >
      >My issue with this was conceptual integrity: similar artifacts in a system should be dealt with in similar ways. When I pointed out this to the team, it sparked one of those "my design vs. your design" debates, everybody got emotional and defensive, and of course we didn't reach any solution at the end.
      >
      >This is not the first time this happens. It's evident to me that we, as a team, don't have a shared pool of design values. In particular, about conceptual integrity. The developer who decided to work alone is particularly prone to create its own niche when he has a chance, but the rest of the team doesn't challenge his behaviour, in part because they are not that concerned anyway, and in part because they prefer to avoid the conflict as well.
      >
      >In other cases when I've been involved in stale-mate design discussions with this team, I've pulled out rank on them to break the stale-mate. Most of the cases, it meant rejecting ideas from this "solitary" developer, who now (and with reason) feels alienated.
      >
      >My initial take into this particular situation was to try to determine who the keeper of conceptual integrity in an agile, self managed team should be. Eventually, though, I realized that it was the wrong question to ask.
      >
      >The keeper of the system's conceptual integrity (and any other values as well) should be the team as a whole. The real question is what's the best way of developing a shared pool of values, minimizing the development of an ugly Big Ball of Mud in the process.
      >
      >
      >Saludos!
      >Fernando.
      >
      >
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
    • Paul Beckford
      Hi, I ve experienced the same thing and had the same frustrations. Someone in the team said to me that you ve got to allow people to make their own mistakes.
      Message 45 of 45 , Dec 28, 2005
      • 0 Attachment
        Hi,

        I've experienced the same thing and had the same frustrations. Someone
        in the team said to me that you've got to allow people to make their own
        mistakes. So I did this, and people made mistakes and some learned from
        them, some didn't.Some people even ended up leaving. Some people just
        aren't comfortable with close scrutiny from their peers. Those who
        stayed became closer and began to develop a common understanding, mainly
        through pairing and retrospectives, much as Kent Beck recommends in his
        post.

        We did a team code walk through once - using a projector. But I'm sure
        that some saw this as a witch hunt and it my have hurried their leaving.

        Those who stayed became more tolerant of each other. I think this was a
        trust thing. People began to trust that everyone was doing their best
        for the team. Believing in this made us all able to give each other time
        and space to try out ideas, even when we didn't agree. BTW socialising
        as a team helped a lot too.

        Frustrating at times, but things have worked out. When the disgrutled
        people left, things got a lot easier.

        Paul.

        Fernando A. Cuenca wrote:

        >Hi,
        >
        >I'm leading a team into the adoption of agile practices. As expected, we are finding different challenges as we go along, but overall the situation is encouraging. I hope one day I'll be able to say that we are "fully XP compliant" (whatever that means! :-) but we are certainly not there yet.
        >
        >This week we faced a situation that has become a recurrent issue and that I'm still uncertain on how to handle it, so I was hoping that maybe somebody in this group could share some insight.
        >
        >This week's iteration included two stories about implementing some default initialization rules in a couple of custom controls we use in our web pages. Two developers decided to pair to work in one of the stories, and a third developer took the other, deciding to work alone (pair programming is a practice that hasn't been accepted for many members of the team.)
        >
        >This was the first time we needed to implement this kind of business rules, so they decided to have a quick meeting to discuss this problem and brainstorm ideas as to how to deal with it. But then, after that, each group went on its way, implementing its story in the way each of them thought it was best. At the end of the meeting there was no agreement on the design approach to use, nor was that their intention. We ended up with two perfectly valid designs for the same kind of artifact.
        >
        >My issue with this was conceptual integrity: similar artifacts in a system should be dealt with in similar ways. When I pointed out this to the team, it sparked one of those "my design vs. your design" debates, everybody got emotional and defensive, and of course we didn't reach any solution at the end.
        >
        >This is not the first time this happens. It's evident to me that we, as a team, don't have a shared pool of design values. In particular, about conceptual integrity. The developer who decided to work alone is particularly prone to create its own niche when he has a chance, but the rest of the team doesn't challenge his behaviour, in part because they are not that concerned anyway, and in part because they prefer to avoid the conflict as well.
        >
        >In other cases when I've been involved in stale-mate design discussions with this team, I've pulled out rank on them to break the stale-mate. Most of the cases, it meant rejecting ideas from this "solitary" developer, who now (and with reason) feels alienated.
        >
        >My initial take into this particular situation was to try to determine who the keeper of conceptual integrity in an agile, self managed team should be. Eventually, though, I realized that it was the wrong question to ask.
        >
        >The keeper of the system's conceptual integrity (and any other values as well) should be the team as a whole. The real question is what's the best way of developing a shared pool of values, minimizing the development of an ugly Big Ball of Mud in the process.
        >
        >
        >Saludos!
        >Fernando.
        >
        >
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        >ad-free courtesy of objectmentor.com
        >Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.