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

Re: [scrumdevelopment] Auditing struggling teams

Expand Messages
  • George Dinwiddie
    Scott, If the team is struggling, then how much confidence do you have that they ll be able to bring up the important issues in a retrospective? I would go
    Message 1 of 8 , Feb 3, 2010
    • 0 Attachment
      Scott,

      If the team is struggling, then how much confidence do you have that
      they'll be able to bring up the important issues in a retrospective?

      I would go with doing a bunch of one-on-one interviews with a broad
      cross-section of the team and surrounding organization. You might find
      http://blog.gdinwiddie.com/2008/11/09/aye-2008-unearthing-the-data-you-need/
      and
      http://ayeconference.com/wiki/scribble.cgi?read=InterviewTipsandTrapsforAssessments
      useful.

      - George

      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?
      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • 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 2 of 8 , Feb 3, 2010
      • 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 3 of 8 , Feb 3, 2010
        • 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 4 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 5 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 6 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.