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

Re: [scrumdevelopment] Re:Measuring Perfomance on SCRUM

Expand Messages
  • Jayanthan Bhattathiripad
    +1
    Message 1 of 37 , Jun 3, 2009
    • 0 Attachment
      +1

      Kathy Adams wrote:
      >
      >
      > What a hotbed of a topic. Bottom line, my view is that individuals on
      > a team self-adjust so they can perform to the level of the higher
      > performers. Interestingly enough, the team doesn’t sink to the lowest
      > common denominator if the team is truly focused on sustainable pace.
      > So monitoring individual performance is really not necessary. For the
      > entire team, you can track story points estimated and then story
      > points delivered for iteration after iteration and see if the team is
      > getting better (i. e. the difference between estimate and delivered
      > points goes down). Early in a team’s life cycle it is easy to
      > under-estimate on what work is needed to complete a task, and to over
      > estimate what you can deliver in an iteration. The team may have to
      > remove stories or tasks towards the end of the sprint to finish in the
      > time-box. If the team is tackling higher technical risk items in early
      > iterations, there is more chance for risks to materialize and slow
      > down completion of early deliverables, or necessitate splitting them
      > into more sprints than planned. As time goes by, and the team adapts
      > as they learn , the difference between the estimated story points for
      > an iteration and the delivered story points start to go down.
      >
      > My experience to support this: When we started scrumming, I had two of
      > the four developers who consistently had almost nothing to report as
      > completed, compared to the other two who estimated well and delivered
      > fairly consistently. One of the two who had almost nothing to report
      > as done for a week, finally realized that he was not being diligent
      > about noting all the work he really had to do in order to complete a
      > story. He was motivated by peer pressure in wanting to be able to
      > report work done (by the way, he was one of our more senior developers
      > and was well-respected as a go-to person for questions, so it was not
      > a matter of skill at coding that impacted his perceived lower
      > productivity). He started adding more tasks to his story estimates to
      > reflect what he was really doing. So, thus both his estimating and his
      > delivery improved. The other developer who had little to report day
      > after day found that he had over-estimated his capacity, as he was
      > also doing maintenance for another system (Yes, we know Agile calls
      > for dedicated teams, but we can’t always do that in our environment).
      > By adjusting capacity for this person (and where possible, assigning
      > him shorter tasks) he was able to report completed tasks more
      > consistently.
      >
      > At one point, early on in the project, I had my own private individual
      > burn down chart for each person on the team. I never showed it to
      > anyone. I just used it to coach people as I noticed that they were
      > weaker links in the chain. As the individuals started self-regulating,
      > I found that there had been little need for me to do the burn-down by
      > person. The team members figured it out on their own.
      >
      > My bottom line – you don’t need to do individual performance
      > monitoring if you have properly empowered the team, worked for
      > sustainable pace and are learning and adapting as you go.
      >
      > *P*** ****Please consider the environment before printing this email**
      >
      > ------------------------------------------------------------------------
      >
      > **Kathy Adams, PMP**
      > //Senior Project Manager//
      >
      > kadams@...
      > (703) 841-5391 (Phone (W))
      > (703) 368-7546 (Phone (M, T, Th, F)
      > (703) 402-9551 (Mobile)
      > (703) 276-0713 (Fax)
      >
      > **nature.org <http://nature.org/>**
      >
      >
      >
      >
      >
      > **The Nature Conservancy**
      > **World Office**
      > 4245 N. Fairfax Drive
      > Suite 100
      > Arlington, VA 22203
      >
      >
      >
      >
      >
      >
    • Jayanthan Bhattathiripad
      +1
      Message 37 of 37 , Jun 3, 2009
      • 0 Attachment
        +1

        Kathy Adams wrote:
        >
        >
        > What a hotbed of a topic. Bottom line, my view is that individuals on
        > a team self-adjust so they can perform to the level of the higher
        > performers. Interestingly enough, the team doesn’t sink to the lowest
        > common denominator if the team is truly focused on sustainable pace.
        > So monitoring individual performance is really not necessary. For the
        > entire team, you can track story points estimated and then story
        > points delivered for iteration after iteration and see if the team is
        > getting better (i. e. the difference between estimate and delivered
        > points goes down). Early in a team’s life cycle it is easy to
        > under-estimate on what work is needed to complete a task, and to over
        > estimate what you can deliver in an iteration. The team may have to
        > remove stories or tasks towards the end of the sprint to finish in the
        > time-box. If the team is tackling higher technical risk items in early
        > iterations, there is more chance for risks to materialize and slow
        > down completion of early deliverables, or necessitate splitting them
        > into more sprints than planned. As time goes by, and the team adapts
        > as they learn , the difference between the estimated story points for
        > an iteration and the delivered story points start to go down.
        >
        > My experience to support this: When we started scrumming, I had two of
        > the four developers who consistently had almost nothing to report as
        > completed, compared to the other two who estimated well and delivered
        > fairly consistently. One of the two who had almost nothing to report
        > as done for a week, finally realized that he was not being diligent
        > about noting all the work he really had to do in order to complete a
        > story. He was motivated by peer pressure in wanting to be able to
        > report work done (by the way, he was one of our more senior developers
        > and was well-respected as a go-to person for questions, so it was not
        > a matter of skill at coding that impacted his perceived lower
        > productivity). He started adding more tasks to his story estimates to
        > reflect what he was really doing. So, thus both his estimating and his
        > delivery improved. The other developer who had little to report day
        > after day found that he had over-estimated his capacity, as he was
        > also doing maintenance for another system (Yes, we know Agile calls
        > for dedicated teams, but we can’t always do that in our environment).
        > By adjusting capacity for this person (and where possible, assigning
        > him shorter tasks) he was able to report completed tasks more
        > consistently.
        >
        > At one point, early on in the project, I had my own private individual
        > burn down chart for each person on the team. I never showed it to
        > anyone. I just used it to coach people as I noticed that they were
        > weaker links in the chain. As the individuals started self-regulating,
        > I found that there had been little need for me to do the burn-down by
        > person. The team members figured it out on their own.
        >
        > My bottom line – you don’t need to do individual performance
        > monitoring if you have properly empowered the team, worked for
        > sustainable pace and are learning and adapting as you go.
        >
        > *P*** ****Please consider the environment before printing this email**
        >
        > ------------------------------------------------------------------------
        >
        > **Kathy Adams, PMP**
        > //Senior Project Manager//
        >
        > kadams@...
        > (703) 841-5391 (Phone (W))
        > (703) 368-7546 (Phone (M, T, Th, F)
        > (703) 402-9551 (Mobile)
        > (703) 276-0713 (Fax)
        >
        > **nature.org <http://nature.org/>**
        >
        >
        >
        >
        >
        > **The Nature Conservancy**
        > **World Office**
        > 4245 N. Fairfax Drive
        > Suite 100
        > Arlington, VA 22203
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.