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

Re: [scrumdevelopment] Auditing struggling teams

Expand Messages
  • Don Gray
    Scott, Do you work in the same organization as the manager and team? What do you do when you audit a team? ... I like to watch the team and review their
    Message 1 of 8 , Feb 3 11:10 AM
    • 0 Attachment
      Scott,

      Do you work in the same organization as the manager and team?

      What do you do when you audit a team?

      > Are there other valuable approaches?

      I like to watch the team and review their artifacts. Walk lightly. Build
      trust. Encourage simple small experiments. This might be helpful:
      http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=100

      And be sure to come to Agile Coach Camp in March to let us know how
      things turn out. http://wiki.agilecoachcamp.org/tiki-index.php

      --
      Don Gray (336)414-4645
      http://www.donaldegray.com

      Traditions are group efforts to keep the unexpected from happening.
      Barbara Tober

      Break tradition at the AYE Conference Nov 7-11, 2010
      AYE: Exploring Human Systems in Action http:\\www.AYEconference.com
    • Alan Dayley
      ... To me audit is a very command and control sort of term. - An accounting audit is a check for mistakes, missing information and malfeasance. - A tax audit
      Message 2 of 8 , Feb 3 12:35 PM
      • 0 Attachment
        On Wed, Feb 3, 2010 at 10:28 AM, Scott <swk@...> 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?
        >

        To me "audit" is a very command and control sort of term.

        - An accounting audit is a check for mistakes, missing information and
        malfeasance.
        - A tax audit is not something that can be avoided nor is it pleasant
        and has dire consequences.
        - I know very few people who welcome a visit of anyone with the word
        "auditor" in their title.

        Using that term in this context feels like one is going to step in,
        scrutinize every action and practice, tell all the things wrong and
        provide all the answers. That would not be Agile. I can imagine
        extreme cases where such may be necessary but that would be
        exceptional.

        Starting with a retrospective is a good thing. I think, though, that
        some skills of trust and honesty may be missing. Coming in with an
        "Auditor" badge will not help! The team may need to learn some basic
        skills before they can make the retrospective productive enough to
        help.

        I would start with nearly silent observation of a sprint, or just a
        first few days of one, right at the transition point between sprints.
        For example, attend the Sprint Review, Retrospective and Planning just
        to see and maybe ask a few questions. Then, start filling in the gaps
        of knowledge and practices that appear to be present.

        - Do they know how to have conflicts or do they avoid them?
        - Do they know how to make conflicts constructive?
        - Are they passive aggressive against Agile or each other or the product?
        - Is someone dominating the team? What are practices that can help
        diffuse that?
        And so on.

        You are there to help the team improve by being an outside voice of
        guidance. If you step in to audit and command fixes, they have a much
        smaller chance of working after you are gone.

        Alan
      • 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 3 of 8 , Feb 4 7:41 PM
        • 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 4 of 8 , Feb 5 12:42 PM
          • 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 5 of 8 , Feb 5 1:08 PM
            • 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.