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

Re: Scrum Master measurements/objectives

Expand Messages
  • jiri_lundak
    Does the team deliver high-quality service on each sprint? Et voilà... you have a good team, and most probably a good ScrumMaster. So it essentially boils
    Message 1 of 7 , Mar 2 7:44 AM
    • 0 Attachment
      Does the team deliver high-quality service on each sprint? Et voilà... you have a good team, and most probably a good ScrumMaster.

      So it essentially boils down to: go and see for yourself what the situation of the team is.

      But what if you just startet using Scrum some months ago and have still big trouble delivering? No metric will help you. Follow the ScrumMaster around for some time. See what he does, how people react to him. What his team says about him. If you do this for a while, you will have a pretty good impression about how good he is.

      As a bonus you will know, where some of the big problems in your organization are.

      Cheers.
      Jiri

      --- In scrumdevelopment@yahoogroups.com, "Jhered" <jhered@...> wrote:
      >
      > What are some good ways to measure and track the success of a ScrumMaster or agile Coach?
      >
      > thanks,
      >
    • tim_s_wise
      I agree with Jiri on this issue, though I would like to add a few things as well. Your scrum master should have an impediments list. This list should radiate
      Message 2 of 7 , Mar 3 5:02 AM
      • 0 Attachment
        I agree with Jiri on this issue, though I would like to add a few things as well.

        Your scrum master should have an impediments list.  This list should radiate throughout the organization in my opinion.  Check and see how the scrum master is facilitating removal of impediments or directly fixing them.

        My feeling is that you want concrete measurable metrics.  Maybe for bonus structures?  Be careful with those.  Know what the incentives are for your scrum master and think about how that incentive either helps the team succeed or hurts them.  Personally, I hate bonus structures.

        In the traditional management of goal setting you want a goal that is clearly defined, within a certain time period, and measurable.
        You might consider team based goals (but again be careful).  I have my teams work toward setting their own goals to get as close to reality as they can (going over or under) and coach them on improving quality. 

        If I can get the team to own it, I've won most of the battle anyway.

        Here's a pretty good checklist for things scrum master's can do from Michael James at CollabNet

        Take Care,
        Tim

        --- In scrumdevelopment@yahoogroups.com, "jiri_lundak" <jiri.lundak@...> wrote:
        >
        > Does the team deliver high-quality service on each sprint? Et voilà... you have a good team, and most probably a good ScrumMaster.
        >
        > So it essentially boils down to: go and see for yourself what the situation of the team is.
        >
        > But what if you just startet using Scrum some months ago and have still big trouble delivering? No metric will help you. Follow the ScrumMaster around for some time. See what he does, how people react to him. What his team says about him. If you do this for a while, you will have a pretty good impression about how good he is.
        >
        > As a bonus you will know, where some of the big problems in your organization are.
        >
        > Cheers.
        > Jiri
        >
        > --- In scrumdevelopment@yahoogroups.com, "Jhered" jhered@ wrote:
        > >
        > > What are some good ways to measure and track the success of a ScrumMaster or agile Coach?
        > >
        > > thanks,
        > >
        >
      • Hariprakash Agrawal
        Hi Jhered (Not sure about your name as you did not have any signature hence picked your email-id), I suggest that you define why in first place you decided to
        Message 3 of 7 , Mar 3 8:27 PM
        • 0 Attachment
          Hi Jhered (Not sure about your name as you did not have any signature hence picked your email-id),

          I suggest that you define why in first place you decided to go for Agile. List down those objectives and check against them whether it is achieved or not. Divide these objectives for PO and SM as per its applicability and observe/measure improvements.

          I also felt that top/senior mgmt is not interested in agile per say and they shared some issues, challenges and was interested in improving them. I had discussions with CEO, Senior managers, senior developers/testers to understand their challenges and came up with few common objectives, which were/are:

          1. To reduce bugs found by internal testing team in the product
          2. To improve commitment to schedules / deadlines by improving  estimation capability of involved stakeholders
          3. To define clear roles and responsibilities to improve accountability among employees
          4. To utilize expertise of employees by equally loading them all the time
          5. To enable managers as mentors by reducing time spent on tracking subordinates
          6. To improve quality of code further to reuse same code base in multiple products
          7. To strengthen reviews process to improve overall product quality
          8. To deploy unit testing for all components
          9. To improve test cases and product quality
          10. To improve build and release process
          11. There can be many more depending on your organization / context

          All above objectives can be measured. Now, the questions is how do we measure it. You may like to read the case study to know one of the way to measure it.


          Regards,
          Hariprakash Agrawal (Hari),
          Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
          Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing
          )


          On Thu, Mar 3, 2011 at 6:32 PM, tim_s_wise <timswise@...> wrote:
           

          I agree with Jiri on this issue, though I would like to add a few things as well.

          Your scrum master should have an impediments list.  This list should radiate throughout the organization in my opinion.  Check and see how the scrum master is facilitating removal of impediments or directly fixing them.

          My feeling is that you want concrete measurable metrics.  Maybe for bonus structures?  Be careful with those.  Know what the incentives are for your scrum master and think about how that incentive either helps the team succeed or hurts them.  Personally, I hate bonus structures.

          In the traditional management of goal setting you want a goal that is clearly defined, within a certain time period, and measurable.
          You might consider team based goals (but again be careful).  I have my teams work toward setting their own goals to get as close to reality as they can (going over or under) and coach them on improving quality. 

          If I can get the team to own it, I've won most of the battle anyway.

          Here's a pretty good checklist for things scrum master's can do from Michael James at CollabNet

          Take Care,
          Tim

          --- In scrumdevelopment@yahoogroups.com, "jiri_lundak" <jiri.lundak@...> wrote:
          >
          > Does the team deliver high-quality service on each sprint? Et voilà... you have a good team, and most probably a good ScrumMaster.
          >
          > So it essentially boils down to: go and see for yourself what the situation of the team is.
          >
          > But what if you just startet using Scrum some months ago and have still big trouble delivering? No metric will help you. Follow the ScrumMaster around for some time. See what he does, how people react to him. What his team says about him. If you do this for a while, you will have a pretty good impression about how good he is.
          >
          > As a bonus you will know, where some of the big problems in your organization are.
          >
          > Cheers.
          > Jiri
          >
          > --- In scrumdevelopment@yahoogroups.com, "Jhered" jhered@ wrote:
          > >
          > > What are some good ways to measure and track the success of a ScrumMaster or agile Coach?
          > >
          > > thanks,
          > >
          >

        • tim_s_wise
          Hariprakash, Thanks for sharing. A good many, if not all, of the measurements are based off of a feeling that things have changed by the group. In other
          Message 4 of 7 , Mar 4 6:09 AM
          • 0 Attachment
            Hariprakash,

            Thanks for sharing.

            A good many, if not all, of the measurements are based off of a feeling that things have changed by the group. In other words, how did the team know that they were more accountable or that requirements were more detailed? How did they know that they improved estimation? I would value this survey, but only as one part of the story as much of it is not concrete.

            Also, with the PO's serving as managers, the team could feel obligated to state yes on many of these questions simply because of the PO being their direct manager.

            Take Care,
            Tim

            --- In scrumdevelopment@yahoogroups.com, Hariprakash Agrawal <haricha@...> wrote:
            >
            > Hi Jhered (Not sure about your name as you did not have any signature hence
            > picked your email-id),
            >
            > I suggest that you define why in first place you decided to go for Agile.
            > List down those objectives and check against them whether it is achieved or
            > not. Divide these objectives for PO and SM as per its applicability and
            > observe/measure improvements.
            >
            > I also felt that top/senior mgmt is not interested in agile per say and they
            > shared some issues, challenges and was interested in improving them. I had
            > discussions with CEO, Senior managers, senior developers/testers to
            > understand their challenges and came up with few common objectives, which
            > were/are:
            >
            > 1. To reduce bugs found by internal testing team in the product
            > 2. To improve commitment to schedules / deadlines by improving estimation
            > capability of involved stakeholders
            > 3. To define clear roles and responsibilities to improve accountability
            > among employees
            > 4. To utilize expertise of employees by equally loading them all the time
            > 5. To enable managers as mentors by reducing time spent on tracking
            > subordinates
            > 6. To improve quality of code further to reuse same code base in multiple
            > products
            > 7. To strengthen reviews process to improve overall product quality
            > 8. To deploy unit testing for all components
            > 9. To improve test cases and product quality
            > 10. To improve build and release process
            > 11. There can be many more depending on your organization / context
            >
            > All above objectives can be measured. Now, the questions is how do we
            > measure it. You may like to read the case
            > study<http://opcord.com/Data/Case%20Study%20-%20Agile%20Consulting.pdf>to
            > know one of the way to measure it.
            >
            >
            > Regards,
            > Hariprakash Agrawal (Hari),
            > Managing Director | Agile Coach | http://opcord.com |
            > http://www.linkedin.com/in/hariprakash
            > Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java
            > Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project
            > Management, Software Testing)
            >
            >
            > On Thu, Mar 3, 2011 at 6:32 PM, tim_s_wise <timswise@...> wrote:
            >
            > >
            > >
            > > I agree with Jiri on this issue, though I would like to add a few things as
            > > well.
            > >
            > > Your scrum master should have an impediments list. This list should
            > > radiate throughout the organization in my opinion. Check and see how the
            > > scrum master is facilitating removal of impediments or directly fixing them.
            > >
            > > My feeling is that you want concrete measurable metrics. Maybe for bonus
            > > structures? Be careful with those. Know what the incentives are for your
            > > scrum master and think about how that incentive either helps the team
            > > succeed or hurts them. Personally, I hate bonus structures.
            > >
            > > In the traditional management of goal setting you want a goal that is
            > > clearly defined, within a certain time period, and measurable.
            > > You might consider team based goals (but again be careful). I have my
            > > teams work toward setting their own goals to get as close to reality as they
            > > can (going over or under) and coach them on improving quality.
            > >
            > > If I can get the team to own it, I've won most of the battle anyway.
            > >
            > > Here's a pretty good checklist for things scrum master's can do from
            > > Michael James at CollabNet
            > >
            > > http://blogs.collab.net/agile/files/2010/06/ScrumMasterChecklist_4_061710.pdf
            > >
            > >
            > > Take Care,
            > > Tim
            > >
            > > --- In scrumdevelopment@yahoogroups.com, "jiri_lundak" <jiri.lundak@>
            > > wrote:
            > > >
            > > > Does the team deliver high-quality service on each sprint? Et voilà...
            > > you have a good team, and most probably a good ScrumMaster.
            > > >
            > > > So it essentially boils down to: go and see for yourself what the
            > > situation of the team is.
            > > >
            > > > But what if you just startet using Scrum some months ago and have still
            > > big trouble delivering? No metric will help you. Follow the ScrumMaster
            > > around for some time. See what he does, how people react to him. What his
            > > team says about him. If you do this for a while, you will have a pretty good
            > > impression about how good he is.
            > > >
            > > > As a bonus you will know, where some of the big problems in your
            > > organization are.
            > > >
            > > > Cheers.
            > > > Jiri
            > > >
            > > > --- In scrumdevelopment@yahoogroups.com, "Jhered" jhered@ wrote:
            > > > >
            > > > > What are some good ways to measure and track the success of a
            > > ScrumMaster or agile Coach?
            > > > >
            > > > > thanks,
            > > > >
            > > >
            > >
            > >
            >
          • Hariprakash Agrawal
            Hi Tim, On Accountability: Scrum has at least 2 practices which improves accountability, Clearly defined roles, like, PO/SM/Team and daily standup meeting.
            Message 5 of 7 , Mar 5 12:46 AM
            • 0 Attachment
              Hi Tim,

              On Accountability: Scrum has at least 2 practices which improves accountability, Clearly defined roles, like, PO/SM/Team and daily standup meeting. Also, team felt that they own delivery now and they only have estimated for it hence they feel more empowered. Nobody is micro-managing hence everyone felt that they have become more accountable than before.

              On Requirements: I explained them PO is responsible for requirements and he needs to detail it as much as possible and prepare/update product backlog using user stories. Due to this push, reqmts were more detailed and after 2-3 sprints, everyone felt improvement in reqmts.

              On estimation: I focus on estimation and explain that team should be able to estimate and must own that estimates. In first sprint, team failed to deliver what they committed to deliver in the demo and reqmts had to be de-scoped. In subsequent sprints, team did improve on estimates and were able to deliver better on with done definition.

              PO as managers: As an external agile coach, I had full support of CEO and everyone including PO was well aware of that. It was very well informed to team that they can discuss with me anything any time. The survey was taken independently from each involved and CEO had set the expectation with everyone that each individual must take it seriously and mark improvement only if it has improved. My part payments were linked to this survey hence it was a very serious exercise.

              I personally think that unless each individual improves, we do not get desired benefits. Process should help everyone involved instead only a deptt, mgmt etc. Hence best measure is customer/employee experience survey provided one asks right questions.


              Regards,
              Hariprakash Agrawal (Hari),
              Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
              Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing
              )


              On Fri, Mar 4, 2011 at 7:39 PM, tim_s_wise <timswise@...> wrote:
               

              Hariprakash,

              Thanks for sharing.

              A good many, if not all, of the measurements are based off of a feeling that things have changed by the group. In other words, how did the team know that they were more accountable or that requirements were more detailed? How did they know that they improved estimation? I would value this survey, but only as one part of the story as much of it is not concrete.

              Also, with the PO's serving as managers, the team could feel obligated to state yes on many of these questions simply because of the PO being their direct manager.

              Take Care,
              Tim



              --- In scrumdevelopment@yahoogroups.com, Hariprakash Agrawal <haricha@...> wrote:
              >
              > Hi Jhered (Not sure about your name as you did not have any signature hence
              > picked your email-id),
              >
              > I suggest that you define why in first place you decided to go for Agile.
              > List down those objectives and check against them whether it is achieved or
              > not. Divide these objectives for PO and SM as per its applicability and
              > observe/measure improvements.
              >
              > I also felt that top/senior mgmt is not interested in agile per say and they
              > shared some issues, challenges and was interested in improving them. I had
              > discussions with CEO, Senior managers, senior developers/testers to
              > understand their challenges and came up with few common objectives, which
              > were/are:
              >
              > 1. To reduce bugs found by internal testing team in the product
              > 2. To improve commitment to schedules / deadlines by improving estimation
              > capability of involved stakeholders
              > 3. To define clear roles and responsibilities to improve accountability
              > among employees
              > 4. To utilize expertise of employees by equally loading them all the time
              > 5. To enable managers as mentors by reducing time spent on tracking
              > subordinates
              > 6. To improve quality of code further to reuse same code base in multiple
              > products
              > 7. To strengthen reviews process to improve overall product quality
              > 8. To deploy unit testing for all components
              > 9. To improve test cases and product quality
              > 10. To improve build and release process
              > 11. There can be many more depending on your organization / context
              >
              > All above objectives can be measured. Now, the questions is how do we
              > measure it. You may like to read the case
              > study<http://opcord.com/Data/Case%20Study%20-%20Agile%20Consulting.pdf>to

              > know one of the way to measure it.
              >
              >
              > Regards,
              > Hariprakash Agrawal (Hari),
              > Managing Director | Agile Coach | http://opcord.com |
              > http://www.linkedin.com/in/hariprakash
              > Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java
              > Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project
              > Management, Software Testing)
              >
              >
              > On Thu, Mar 3, 2011 at 6:32 PM, tim_s_wise <timswise@...> wrote:
              >
              > >
              > >
              > > I agree with Jiri on this issue, though I would like to add a few things as
              > > well.
              > >
              > > Your scrum master should have an impediments list. This list should
              > > radiate throughout the organization in my opinion. Check and see how the
              > > scrum master is facilitating removal of impediments or directly fixing them.
              > >
              > > My feeling is that you want concrete measurable metrics. Maybe for bonus
              > > structures? Be careful with those. Know what the incentives are for your
              > > scrum master and think about how that incentive either helps the team
              > > succeed or hurts them. Personally, I hate bonus structures.
              > >
              > > In the traditional management of goal setting you want a goal that is
              > > clearly defined, within a certain time period, and measurable.
              > > You might consider team based goals (but again be careful). I have my
              > > teams work toward setting their own goals to get as close to reality as they
              > > can (going over or under) and coach them on improving quality.
              > >
              > > If I can get the team to own it, I've won most of the battle anyway.
              > >
              > > Here's a pretty good checklist for things scrum master's can do from
              > > Michael James at CollabNet
              > >
              > > http://blogs.collab.net/agile/files/2010/06/ScrumMasterChecklist_4_061710.pdf
              > >
              > >
              > > Take Care,
              > > Tim
              > >
              > > --- In scrumdevelopment@yahoogroups.com, "jiri_lundak" <jiri.lundak@>
              > > wrote:
              > > >
              > > > Does the team deliver high-quality service on each sprint? Et voilà...
              > > you have a good team, and most probably a good ScrumMaster.
              > > >
              > > > So it essentially boils down to: go and see for yourself what the
              > > situation of the team is.
              > > >
              > > > But what if you just startet using Scrum some months ago and have still
              > > big trouble delivering? No metric will help you. Follow the ScrumMaster
              > > around for some time. See what he does, how people react to him. What his
              > > team says about him. If you do this for a while, you will have a pretty good
              > > impression about how good he is.
              > > >
              > > > As a bonus you will know, where some of the big problems in your
              > > organization are.
              > > >
              > > > Cheers.
              > > > Jiri
              > > >
              > > > --- In scrumdevelopment@yahoogroups.com, "Jhered" jhered@ wrote:
              > > > >
              > > > > What are some good ways to measure and track the success of a
              > > ScrumMaster or agile Coach?
              > > > >
              > > > > thanks,
              > > > >
              > > >
              > >
              > >
              >


            Your message has been successfully submitted and would be delivered to recipients shortly.