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

Re: [scrumdevelopment] Love/Hate Agile Metrics - was Re: Jeff Sutherland's paper on Distributed Scru...

Expand Messages
  • mike.dwyer1@comcast.net
    Deb; metrics in Agile and Scrum are simple. DONE (what was promised was delivered and accepted) or NOT. NOT drives one question What can we do to do better
    Message 1 of 20 , Mar 30, 2006
    • 0 Attachment
      Deb;
      metrics in Agile and Scrum are simple.
       
      DONE (what was promised was delivered and accepted)
      or NOT.
       
      NOT drives one question  What can we do to do better here
       
      DONE drives one question  What do we need to do to make this better.
      Money spent on NOT is an investment on improvement or it is lost  (money is not reusable)
       
      Money spent on DONE is value added.  This could include the money lost on NOT if the DONE was based on the investment in improvement
       
      Anything else is feed for a chicken meeting.
      --
      Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


      The greatest oak was once a little nut who held its ground. ~Author Unknown
       
      -------------- Original message --------------
      From: "Deb" <deborah@...>

      > --- In scrumdevelopment@yahoogroups.com, Steven Farlie wrote:
      > >
      > > Metrics are usually so hard to do right and give such a false sense of
      > > security that I would only recommend it to people that hate metrics. At
      > > least they have the right level of skepticism about them.
      > > --
      > > Steven
      > >
      >
      > Yes, I like this too.
      >
      > When my colleagues sceptically ask me "why on earth" I was writing on
      > metrics recently, my answer embodied this sentiment, though you've
      > crystallized it much better than I did when I replied: "if we don't
      > write the basics on Agile metrics now, people who worship metrics will
      > grab the subject and bury us in meaningless metrics recommendations".
      >
      > For me, the basics of Agile metrics seem to be:
      >
      > 1. Measure value delivered
      > 2. Figure out how to produce more value (this might require local
      > diagnostics like velocity, defect count, whatever a team thinks will help)
      > 3. Figure out what doesn't matter any more (and stop measuring it)
      > 4. Deliver some value
      > 5. Iterate
      >
      > Your recommendation to include "people who hate metrics" in the
      > metrics development process seems very wise to me. It's not going to
      > be a pleasant role, but a necessary one. An agile practitioner with
      > the maturity to play this role well would be an asset on any team
      > (development team, management team) thinking about what to start/stop
      > measuring. I specify "agile practitioner" because I think that a deep
      > understanding of the Agile Values does inform metrics choices in a
      > particular way that enables and protects our teams.
      >
      > Let's not leave metrics to the metrics-minded!
      > (That's why this dyslexic, number-phobic gal is writing on metrics.
      > Now, how twisted is that? :-)
      >
      > ciao
      > deb
      >
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
    • Brad Appleton
      I use lines-of-code for metrics all the time. I just dont use it to measure productivity. I use it to measure sizes of things, like * number of lines
      Message 2 of 20 , Mar 30, 2006
      • 0 Attachment
        I use lines-of-code for metrics all the time. I just dont use it to
        measure productivity. I use it to measure sizes of things, like
        * number of lines added/removed/changed per commit
        * number of lines merged when merge conflict occurs
        * number of lines of merged -vs- "original" code per "commit"
        * number of defects per lines of code
        * lines of code per file
        * lines of code per method
        * lines of code changed per day, week
        * lines of code added/changed/removed between labeled builds

        For a given project, these eventually indicate trends in activity that
        give me a clue about the likely complexity of a merge/commit, and
        possible relationships between merge complexity and change-size and
        integration/build frequency, and defects.
        --
        Brad Appleton <brad {AT} bradapp.net>
        Agile CM Environments (http://blog.bradapp.net/)
        & Software CM Patterns (www.scmpatterns.com)
        "And miles to go before I sleep" -- Robert Frost
      • Deb
        ... So, Mike: Are chicken meetings less important? If the organization is well-aligned, everyone s meetings should be about delivering value, right? Ok,
        Message 3 of 20 , Mar 31, 2006
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
          >
          > Deb;
          > metrics in Agile and Scrum are simple.
          > ...
          >
          > Anything else is feed for a chicken meeting.
          > --

          So, Mike:

          Are "chicken meetings" less important? If the organization is
          well-aligned, everyone's meetings should be about delivering value,
          right? Ok, those in the non-agile parts of the organization may have
          waaaay more waste... but it can't be constructive to look down our
          noses at them (yes, it is tempting :-).

          Let's simply assume they don't know any better yet. And, if we can
          clearly show them the progress we are making, perhaps we can model a
          different approach to them? This would be my hope in increasing
          transparency through careful use of *value* metrics outside the team.

          Eventual goal: break down the us/them wall and all get on with
          delivering value...

          deb
          (someone's got to dream)
        • Mike Dwyer
          As to the us them issue. Chickens IMO self identify by not taking responsibility and committing to deliver or not engaging. I have never - repeat never - seen
          Message 4 of 20 , Apr 1 12:34 PM
          • 0 Attachment
            As to the us them issue.

            Chickens IMO self identify by not taking responsibility and committing to
            deliver or not engaging. I have never - repeat never - seen anyone who
            committed to getting things DONE not considered a Pig and treated as such,
            even to the point of people calling in on their own dime. It is has been my
            experience to see vendors enter the ring of commitment.

            At the same time I have repeatedly seen people whose names were on the
            masthead of a program and a project always have someplace else to be.

            The Scrum we practice has taken the high road on this. We chose to consider
            people to be chickens or pigs based on their actions and priorities and it
            is working well.

            People who show up, prepared, and working in, people who don't show up are
            out. People who show up to be seen - are. But no words are listened to.

            We commit to respectin everyone's priorities including our own. You don't
            show up prepared, then we assume that you don't have a desire to contribute
            and we also assume that you are OK with what we are doing and that you have
            nothing of priority concerning you. We commit to the rest of the team not
            to generate muda by trying to guess what you need so we work on only those
            things that the people present think are important.

            It comes down to it being respectful to all of us all of the time.

            Michael F. Dwyer

            "Planning constantly peers into the future for indications as to where a
            solution may emerge."
            "A Plan is a complex situation, adapting to an emerging solution."

            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com
            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Deb
            Sent: Friday, March 31, 2006 4:01 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Love/Hate Agile Metrics - was Re: Jeff
            Sutherland's paper on Distributed Scru...

            --- In scrumdevelopment@yahoogroups.com, mike.dwyer1@... wrote:
            >
            > Deb;
            > metrics in Agile and Scrum are simple.
            > ...
            >
            > Anything else is feed for a chicken meeting.
            > --

            So, Mike:

            Are "chicken meetings" less important? If the organization is
            well-aligned, everyone's meetings should be about delivering value,
            right? Ok, those in the non-agile parts of the organization may have
            waaaay more waste... but it can't be constructive to look down our
            noses at them (yes, it is tempting :-).

            Let's simply assume they don't know any better yet. And, if we can
            clearly show them the progress we are making, perhaps we can model a
            different approach to them? This would be my hope in increasing
            transparency through careful use of *value* metrics outside the team.

            Eventual goal: break down the us/them wall and all get on with
            delivering value...

            deb
            (someone's got to dream)





            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • Alexey Krivitsky
            Although the article was interested (provoking) in some aspects, I also have some skepticism, particularly about the inter-team Scrum meeting duration. It
            Message 5 of 20 , Apr 2 6:25 AM
            • 0 Attachment
              Although the article was interested (provoking) in some aspects, I also have some skepticism, particularly about the inter-team Scrum meeting duration.  It seems to me it is impossible to make this meeting within even half an hour for 50 pigs, even if the answers are prepared in a written form, which is yet another point I am sceptical with.

              Another point is:
              Being a ScrumMaster for a project with 6 developers, at some stage we have had problems making Scrum meetings interested for all pigs since the guys were working on different subsystems and didn't care what was happening in the neighbor subsystem. Now it has been improved since we share the task pool (via the Sprint Backlog) which made the guys collaborate tightly sharing the tasks and hence became interested in other's progress.
              For the project described in the article, did all the dev teams share the same Sprint Backlog, if not, then I can't actually see why to have the inter-team Scrum meetings?
              But if indeed they shared the same Sprint Backlog, then I would wonder by means of what practices it was made possible for 50 people (distributed around the globe) to do that: what the Sprint planning meetings looked like? what the retrospective meetings looked like? simply, how the developers from the distributed teams collaborate to sign up for tasks from the Sprint backlog? etc.

              Thanks.

              //Alexey

              On 3/28/06, Steven Gordon <sgordonphd@...> wrote:
              Mike and Jeff,

              Thanks for posting this paper and allowing it to be posted, respectively.

              I remain skeptical of the conclusions for 3 reasons:
              • Lines of code are not a reliable performance measure,
              • One cannot infer this is a better way to scale agile from a single example (the developers might be extraordinary rather than the configuration)
              • I just do not see how the geographically disperse teams cause much of a boost over crossfunctional colocated teams, given that the developers in the two locations appear to overlap in time about an hour a day, not providing enough time to pair-program or do collaborative design to make much of a difference.  They just appear to be two distinct teams that share a backlog and synch up once a day.  The speed up might just be due to each team being able to code 14-16 hours a day rather than Scrum++.

              Steven Gordon

              On 3/27/06, Mike Cohn < mike@...> wrote:
              If you want to read the paper that started the firestorm of
              discussions about Type A, B, and C Scrum, Jeff Sutherland has agreed
              to make that paper available on the Scrum Alliance website. It is
              available at

              http://www.scrumalliance.org/index.php/scrum_alliance/for_everyone/
              resources/scrum_articles
              or
              http://tinyurl.com/p9otd

              (The latter expands to the same URL but has been made tiny.)

              Regards,
              Mike Cohn
              Author:
                 Agile Estimating and Planning
                 User Stories Applied
              www.mountaingoatsoftware.com




              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
              Yahoo! Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/scrumdevelopment/

              <*> To unsubscribe from this group, send an email to:
                   scrumdevelopment-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                   http://docs.yahoo.com/info/terms/







              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




              SPONSORED LINKS
              Scrum


              YAHOO! GROUPS LINKS




            • Ken Schwaber
              Another way to make their work interesting is to require that it integrates and passes an integration test at least daily. For worldwide meetings, a really
              Message 6 of 20 , Apr 2 10:44 AM
              • 0 Attachment

                Another way to make their work interesting is to require that it integrates and passes an integration test at least daily. For worldwide meetings, a really good idea is to have at least one person from each location be at a central location for the review and planning,

                Ken

                 


                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Alexey Krivitsky
                Sent: Sunday, April 02, 2006 9:25 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: Re: [scrumdevelopment] Jeff Sutherland's paper on Distributed Scrum now on ScrumAlliance.org

                 

                Although the article was interested (provoking) in some aspects, I also have some skepticism, particularly about the inter-team Scrum meeting duration.  It seems to me it is impossible to make this meeting within even half an hour for 50 pigs, even if the answers are prepared in a written form, which is yet another point I am sceptical with.

                Another point is:
                Being a ScrumMaster for a project with 6 developers, at some stage we have had problems making Scrum meetings interested for all pigs since the guys were working on different subsystems and didn't care what was happening in the neighbor subsystem. Now it has been improved since we share the task pool (via the Sprint Backlog) which made the guys collaborate tightly sharing the tasks and hence became interested in other's progress.
                For the project described in the article, did all the dev teams share the same Sprint Backlog, if not, then I can't actually see why to have the inter-team Scrum meetings?
                But if indeed they shared the same Sprint Backlog, then I would wonder by means of what practices it was made possible for 50 people (distributed around the globe) to do that: what the Sprint planning meetings looked like? what the retrospective meetings looked like? simply, how the developers from the distributed teams collaborate to sign up for tasks from the Sprint backlog? etc.

                Thanks.

                //Alexey

                On 3/28/06, Steven Gordon <sgordonphd@...> wrote:

                Mike and Jeff,

                Thanks for posting this paper and allowing it to be posted, respectively.

                I remain skeptical of the conclusions for 3 reasons:

                • Lines of code are not a reliable performance measure,
                • One cannot infer this is a better way to scale agile from a single example (the developers might be extraordinary rather than the configuration)
                • I just do not see how the geographically disperse teams cause much of a boost over crossfunctional colocated teams, given that the developers in the two locations appear to overlap in time about an hour a day, not providing enough time to pair-program or do collaborative design to make much of a difference.  They just appear to be two distinct teams that share a backlog and synch up once a day.  The speed up might just be due to each team being able to code 14-16 hours a day rather than Scrum++.


                Steven Gordon

                On 3/27/06, Mike Cohn < mike@...> wrote:

                If you want to read the paper that started the firestorm of
                discussions about Type A, B, and C Scrum, Jeff Sutherland has agreed
                to make that paper available on the Scrum Alliance website. It is
                available at

                http://www.scrumalliance.org/index.php/scrum_alliance/for_everyone/
                resources/scrum_articles
                or
                http://tinyurl.com/p9otd

                (The latter expands to the same URL but has been made tiny.)

                Regards,
                Mike Cohn
                Author:
                   Agile Estimating and Planning
                   User Stories Applied
                www.mountaingoatsoftware.com




                To Post a message, send it to:   scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                    http://groups.yahoo.com/group/scrumdevelopment/

                <*> To unsubscribe from this group, send an email to:
                     scrumdevelopment-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                     http://docs.yahoo.com/info/terms/



                 



                To Post a message, send it to:   scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


                SPONSORED LINKS

                Scrum

                 


                YAHOO! GROUPS LINKS

                 

                 




              • Øystein Mehus
                ... My understanding is that there were 5 teams, of which 3 had members from the St. Petersburg office and that each team had separate scrum meetings. ... The
                Message 7 of 20 , Apr 2 11:26 AM
                • 0 Attachment
                  On 2006-04-02 15:25, Alexey Krivitsky wrote:
                  > Although the article was interested (provoking) in some aspects, I also
                  > have some skepticism, particularly about the inter-team Scrum meeting
                  > duration. It seems to me it is impossible to make this meeting within
                  > even half an hour for 50 pigs, even if the answers are prepared in a
                  > written form, which is yet another point I am sceptical with.

                  My understanding is that there were 5 teams, of which 3 had members from
                  the St. Petersburg office and that each team had separate scrum meetings.

                  > For the project described in the article, did all the dev teams share
                  > the same Sprint Backlog, if not, then I can't actually see why to have
                  > the inter-team Scrum meetings?

                  The teams were split across functional areas of the library (catalogue,
                  serials, circulation, search, reporting), so the backlog would most
                  likely be split among teams, which doesn't preclude the PO's to keep a
                  global large backlog, though. The article mentions that any team member
                  on a team, independent of geographical location, could work on any of
                  that team's tasks; maybe that's what confused you?
                  --
                  Øystein
                • Hubert Smits
                  Alexey, You can do this kind of stand-up meeting, seen it (for 2 years) done it (for 9 months) got the t-shirt. No written preps, just everybody being there
                  Message 8 of 20 , Apr 3 12:35 PM
                  • 0 Attachment
                    Alexey,

                    You can do this kind of stand-up meeting, seen it (for 2 years) done it (for 9 months) got the t-shirt. No written preps, just everybody being there (on time) and an "uber scrummaster" who measured barely 5' but refused to let to the team go of-track (had nothing to do with the whip in her handbag of course.)

                    --Hubert

                    On 4/2/06, Alexey Krivitsky <alexeykrivitsky@...> wrote:
                    Although the article was interested (provoking) in some aspects, I also have some skepticism, particularly about the inter-team Scrum meeting duration.  It seems to me it is impossible to make this meeting within even half an hour for 50 pigs, even if the answers are prepared in a written form, which is yet another point I am sceptical with.

                    Another point is:
                    Being a ScrumMaster for a project with 6 developers, at some stage we have had problems making Scrum meetings interested for all pigs since the guys were working on different subsystems and didn't care what was happening in the neighbor subsystem. Now it has been improved since we share the task pool (via the Sprint Backlog) which made the guys collaborate tightly sharing the tasks and hence became interested in other's progress.
                    For the project described in the article, did all the dev teams share the same Sprint Backlog, if not, then I can't actually see why to have the inter-team Scrum meetings?
                    But if indeed they shared the same Sprint Backlog, then I would wonder by means of what practices it was made possible for 50 people (distributed around the globe) to do that: what the Sprint planning meetings looked like? what the retrospective meetings looked like? simply, how the developers from the distributed teams collaborate to sign up for tasks from the Sprint backlog? etc.

                    Thanks.

                    //Alexey


                    On 3/28/06, Steven Gordon <sgordonphd@... > wrote:
                    Mike and Jeff,

                    Thanks for posting this paper and allowing it to be posted, respectively.

                    I remain skeptical of the conclusions for 3 reasons:
                    • Lines of code are not a reliable performance measure,
                    • One cannot infer this is a better way to scale agile from a single example (the developers might be extraordinary rather than the configuration)
                    • I just do not see how the geographically disperse teams cause much of a boost over crossfunctional colocated teams, given that the developers in the two locations appear to overlap in time about an hour a day, not providing enough time to pair-program or do collaborative design to make much of a difference.  They just appear to be two distinct teams that share a backlog and synch up once a day.  The speed up might just be due to each team being able to code 14-16 hours a day rather than Scrum++.

                    Steven Gordon

                    On 3/27/06, Mike Cohn <mike@...> wrote:
                    If you want to read the paper that started the firestorm of
                    discussions about Type A, B, and C Scrum, Jeff Sutherland has agreed
                    to make that paper available on the Scrum Alliance website. It is
                    available at

                    http://www.scrumalliance.org/index.php/scrum_alliance/for_everyone/
                    resources/scrum_articles
                    or
                    http://tinyurl.com/p9otd

                    (The latter expands to the same URL but has been made tiny.)

                    Regards,
                    Mike Cohn
                    Author:
                       Agile Estimating and Planning
                       User Stories Applied
                    www.mountaingoatsoftware.com




                    To Post a message, send it to:   scrumdevelopment@...
                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                    Yahoo! Groups Links

                    <*> To visit your group on the web, go to:
                        http://groups.yahoo.com/group/scrumdevelopment/

                    <*> To unsubscribe from this group, send an email to:
                         scrumdevelopment-unsubscribe@yahoogroups.com

                    <*> Your use of Yahoo! Groups is subject to:
                        http://docs.yahoo.com/info/terms/







                    To Post a message, send it to:   scrumdevelopment@...
                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                    SPONSORED LINKS
                    Scrum


                    YAHOO! GROUPS LINKS






                    To Post a message, send it to:   scrumdevelopment@...
                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                    YAHOO! GROUPS LINKS






                    --

                    All opinions in this message are my own, and are not necessarily shared by my employer.
                  Your message has been successfully submitted and would be delivered to recipients shortly.