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

Re: [scrumdevelopment] Auditing struggling teams

Expand Messages
  • Cory Foy
    Hi Scott, First, kill the word audit. The team will become defensive. Especially if things are going poorly. I ve done a retrospective of a struggling team. We
    Message 1 of 8 , Feb 4, 2010
    • 0 Attachment
      Hi Scott,

      First, kill the word audit. The team will become defensive. Especially
      if things are going poorly.

      I've done a retrospective of a struggling team. We covered 18 months of
      work in a day. It was brutal, and revealed a lot of great things. But
      there were a lot of dysfunctions I had to carefully facilitate around.

      The real value came in the one-on-one sessions I had with developers and
      small groups. Those revealed additional team dynamics the retrospective
      brought out.

      But many times I find that the real dysfunction goes beyond the team
      into the organization as a whole. I know of one team that had a problem
      with rework - bugs were closed, but still found later in the system, and
      the bug was never reopened.

      It turned out that the testers were metric'd on how many *new* bugs they
      opened. And developers were metric'd on how long bugs stayed open.

      One other thing I like to start with on teams is a discussion of their
      workflow. How does something get from a customer request to being
      shipped? That might help pull a lot of good information about pain points.

      Doing all that in one day is going to be tough. I agree with George with
      the one-on-ones - I think I would do a short meeting with everyone to
      understand the overall workflow (watching for interesting dynamics) and
      then do a series of one-on-ones or small group discussions to dig further.

      And I'd pick up the books Agile Retrospectives, 5 Dysfunctions of a
      Team, and Crucial Conversations to start.

      --
      Cory Foy
      http://www.coryfoy.com
      http://twitter.com/cory_foy



      Scott wrote:
      > Last week I had a frantic manager contact me about a struggling agile team that worked under her. I agreed to do an audit of the team and coach them into better health.
      > I’ve got a good idea of how I want to go about auditing the team and its practices, principles and values, but I thought I might cast a net out and reel in the wisdom of this group. Certainly some of you have dealt with this before.
      >
      > My thinking is to begin the day long audit by collecting everyone on the team into a room and starting with a retrospective. This should light the path and focus further work during the day. Some questions:
      >
      > Are there other valuable approaches?
      > What retrospective techniques or exercises have you found particularly valuable with struggling teams?
      > What insights or experiences can you share from similar agile audits with struggling teams?
      >
      > - Regards,
      > Scott Killen
      > Founder & President of Agile Austin
      > Sent via BlackBerry by AT&T
    • ScottK
      Thanks for the insight Cory. Use of the term audit is interesting. The word was chosen because the frantic manager is a dyed-in-the-wool PMP. Yet, she is
      Message 2 of 8 , Feb 5, 2010
      • 0 Attachment
        Thanks for the insight Cory.

        Use of the term "audit" is interesting. The word was chosen because the frantic manager is a dyed-in-the-wool PMP. Yet, she is open minded enough that, instead of pulling the plug on "this agile experiment" and going back to waterfall, she called me to see if the team was not following acceptible practices. A very open minded approach that I appreciated. I simply chose a word that made her comfortable. But your point is taken. A bad word to use around the team.

        This team has a history about about 10 weeks. Thank goodness it is not 18 months.

        The workflow discussion is a great idea. Thanks for that.

        I've read Agile Retrospectives. It's a good one. The other two are on my reading list.

        Appreciate your viewpoint.

        - Scott Killen

        --- In scrumdevelopment@yahoogroups.com, Cory Foy <usergroup@...> wrote:
        >
        > Hi Scott,
        >
        > First, kill the word audit. The team will become defensive. Especially
        > if things are going poorly.
        >
        > I've done a retrospective of a struggling team. We covered 18 months of
        > work in a day. It was brutal, and revealed a lot of great things. But
        > there were a lot of dysfunctions I had to carefully facilitate around.
        >
        > The real value came in the one-on-one sessions I had with developers and
        > small groups. Those revealed additional team dynamics the retrospective
        > brought out.
        >
        > But many times I find that the real dysfunction goes beyond the team
        > into the organization as a whole. I know of one team that had a problem
        > with rework - bugs were closed, but still found later in the system, and
        > the bug was never reopened.
        >
        > It turned out that the testers were metric'd on how many *new* bugs they
        > opened. And developers were metric'd on how long bugs stayed open.
        >
        > One other thing I like to start with on teams is a discussion of their
        > workflow. How does something get from a customer request to being
        > shipped? That might help pull a lot of good information about pain points.
        >
        > Doing all that in one day is going to be tough. I agree with George with
        > the one-on-ones - I think I would do a short meeting with everyone to
        > understand the overall workflow (watching for interesting dynamics) and
        > then do a series of one-on-ones or small group discussions to dig further.
        >
        > And I'd pick up the books Agile Retrospectives, 5 Dysfunctions of a
        > Team, and Crucial Conversations to start.
        >
        > --
        > Cory Foy
        > http://www.coryfoy.com
        > http://twitter.com/cory_foy
        >
        >
        >
        > Scott wrote:
        > > Last week I had a frantic manager contact me about a struggling agile team that worked under her. I agreed to do an audit of the team and coach them into better health.
        > > I've got a good idea of how I want to go about auditing the team and its practices, principles and values, but I thought I might cast a net out and reel in the wisdom of this group. Certainly some of you have dealt with this before.
        > >
        > > My thinking is to begin the day long audit by collecting everyone on the team into a room and starting with a retrospective. This should light the path and focus further work during the day. Some questions:
        > >
        > > Are there other valuable approaches?
        > > What retrospective techniques or exercises have you found particularly valuable with struggling teams?
        > > What insights or experiences can you share from similar agile audits with struggling teams?
        > >
        > > - Regards,
        > > Scott Killen
        > > Founder & President of Agile Austin
        > > Sent via BlackBerry by AT&T
        >
      • John
        Hi Scott, I m intrigued by she called me to see if the team was not following acceptible practices . What is the deliverable from the review? I d second
        Message 3 of 8 , Feb 5, 2010
        • 0 Attachment
          Hi Scott,
          I'm intrigued by "she called me to see if the team was not following
          acceptible practices". What is the deliverable from the review?

          I'd second Cory's idea to led the team through a discussion on their
          development cycle, a fairly neutral topic that almost everyone will have
          thoughts on what is good and what could be better.

          John


          --- In scrumdevelopment@yahoogroups.com, "ScottK" <swk@...> wrote:
          >
          > Thanks for the insight Cory.
          >
          > Use of the term "audit" is interesting. The word was chosen because
          the frantic manager is a dyed-in-the-wool PMP. Yet, she is open minded
          enough that, instead of pulling the plug on "this agile experiment" and
          going back to waterfall, she called me to see if the team was not
          following acceptible practices. A very open minded approach that I
          appreciated. I simply chose a word that made her comfortable. But your
          point is taken. A bad word to use around the team.
          >
          > This team has a history about about 10 weeks. Thank goodness it is
          not 18 months.
          >
          > The workflow discussion is a great idea. Thanks for that.
          >
          > I've read Agile Retrospectives. It's a good one. The other two are
          on my reading list.
          >
          > Appreciate your viewpoint.
          >
          > - Scott Killen
          >
          > --- In scrumdevelopment@yahoogroups.com, Cory Foy usergroup@ wrote:
          > >
          > > Hi Scott,
          > >
          > > First, kill the word audit. The team will become defensive.
          Especially
          > > if things are going poorly.
          > >
          > > I've done a retrospective of a struggling team. We covered 18 months
          of
          > > work in a day. It was brutal, and revealed a lot of great things.
          But
          > > there were a lot of dysfunctions I had to carefully facilitate
          around.
          > >
          > > The real value came in the one-on-one sessions I had with developers
          and
          > > small groups. Those revealed additional team dynamics the
          retrospective
          > > brought out.
          > >
          > > But many times I find that the real dysfunction goes beyond the team
          > > into the organization as a whole. I know of one team that had a
          problem
          > > with rework - bugs were closed, but still found later in the system,
          and
          > > the bug was never reopened.
          > >
          > > It turned out that the testers were metric'd on how many *new* bugs
          they
          > > opened. And developers were metric'd on how long bugs stayed open.
          > >
          > > One other thing I like to start with on teams is a discussion of
          their
          > > workflow. How does something get from a customer request to being
          > > shipped? That might help pull a lot of good information about pain
          points.
          > >
          > > Doing all that in one day is going to be tough. I agree with George
          with
          > > the one-on-ones - I think I would do a short meeting with everyone
          to
          > > understand the overall workflow (watching for interesting dynamics)
          and
          > > then do a series of one-on-ones or small group discussions to dig
          further.
          > >
          > > And I'd pick up the books Agile Retrospectives, 5 Dysfunctions of a
          > > Team, and Crucial Conversations to start.
          > >
          > > --
          > > Cory Foy
          > > http://www.coryfoy.com
          > > http://twitter.com/cory_foy
          > >
          > >
          > >
          > > Scott wrote:
          > > > Last week I had a frantic manager contact me about a struggling
          agile team that worked under her. I agreed to do an audit of the team
          and coach them into better health.
          > > > I've got a good idea of how I want to go about auditing the team
          and its practices, principles and values, but I thought I might cast a
          net out and reel in the wisdom of this group. Certainly some of you
          have dealt with this before.
          > > >
          > > > My thinking is to begin the day long audit by collecting everyone
          on the team into a room and starting with a retrospective. This should
          light the path and focus further work during the day. Some questions:
          > > >
          > > > Are there other valuable approaches?
          > > > What retrospective techniques or exercises have you found
          particularly valuable with struggling teams?
          > > > What insights or experiences can you share from similar agile
          audits with struggling teams?
          > > >
          > > > - Regards,
          > > > Scott Killen
          > > > Founder & President of Agile Austin
          > > > Sent via BlackBerry by AT&T
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.