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

Jeff Sutherland's paper on Distributed Scrum now on ScrumAlliance.org

Expand Messages
  • Mike Cohn
    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
    Message 1 of 20 , Mar 27 3:28 PM
    • 0 Attachment
      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
    • Steven Gordon
      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
      Message 2 of 20 , Mar 27 7:59 PM
      • 0 Attachment
        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/





      • Steven Farlie
        ... The key to understanding metrics is to know when they are meaningless. I ve used LOC as a metric before, but it is only useful when comparing two very
        Message 3 of 20 , Mar 29 3:56 AM
        • 0 Attachment
          Ron Jeffries wrote:
          > On Wednesday, March 29, 2006, at 7:07:01 AM, mpkirby@... wrote:
          >
          >> I have seen evidence, however, that lines of code is a reasonable
          >> approximation of complexity, so as a measure of how quickly the
          >> team produces "complexity" it's pretty useful. Of course much of
          >> what agile is about is reducing complexity, so that's pretty
          >> worthless in its own :-)
          >
          > In the past couple of weeks, Chet and I produced a number of
          > different solutions to exactly the same problem. The largest was
          > about five times larger than the smallest.
          >
          > We wrote more code ... were we five times more productive in the
          > larger case?

          The key to understanding metrics is to know when they are meaningless.
          I've used LOC as a metric before, but it is only useful when comparing
          two very similar projects using the same tech. Even then it is only a
          single data point which doesn't tell much by itself. It is definitely
          not a good basis for measuring such an abstract concept as "productivity".

          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
        • mpkirby@frontiernet.net
          ... For a good argument in support this, see: http://martinfowler.com/bliki/CannotMeasureProductivity.html I have seen evidence, however, that lines of code is
          Message 4 of 20 , Mar 29 4:07 AM
          • 0 Attachment
            On 27 Mar 2006 at 20:59, Steven Gordon wrote:

            > I remain skeptical of the conclusions for 3 reasons:
            >
            > Lines of code are not a reliable performance measure,

            For a good argument in support this, see:

            http://martinfowler.com/bliki/CannotMeasureProductivity.html

            I have seen evidence, however, that lines of code is a reasonable approximation of
            complexity, so as a measure of how quickly the team produces "complexity" it's pretty useful.
            Of course much of what agile is about is reducing complexity, so that's pretty worthless in its
            own :-)

            Mike

            ---
            mpkirby@...
          • Ken Schwaber
            Metrics are such a slippery slope and the possibility for suboptimal metrics is tremendous. Even when well intended, the moment something is measured in this
            Message 5 of 20 , Mar 29 4:31 AM
            • 0 Attachment

              Metrics are such a slippery slope and the possibility for suboptimal metrics is tremendous. Even when well intended, the moment something is measured in this way, it is perverted,

              Ken

               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mpkirby@...
              Sent: Wednesday, March 29, 2006 7:07 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Jeff Sutherland's paper on Distributed Scrum now on ScrumAlliance.org

               



              On 27 Mar 2006 at 20:59, Steven Gordon wrote:

              > I remain skeptical of the conclusions for 3 reasons:
              >
              > Lines of code are not a reliable performance measure,

              For a good argument in support this, see:

              http://martinfowler.com/bliki/CannotMeasureProductivity.html

              I have seen evidence, however, that lines of code is a reasonable approximation of
              complexity, so as a measure of how quickly the team produces "complexity" it's pretty useful. 
              Of course much of what agile is about is reducing complexity, so that's pretty worthless in its
              own :-)

              Mike

              ---
              mpkirby@...


            • Ron Jeffries
              ... In the past couple of weeks, Chet and I produced a number of different solutions to exactly the same problem. The largest was about five times larger than
              Message 6 of 20 , Mar 29 4:39 AM
              • 0 Attachment
                On Wednesday, March 29, 2006, at 7:07:01 AM, mpkirby@... wrote:

                > I have seen evidence, however, that lines of code is a reasonable
                > approximation of complexity, so as a measure of how quickly the
                > team produces "complexity" it's pretty useful. Of course much of
                > what agile is about is reducing complexity, so that's pretty
                > worthless in its own :-)

                In the past couple of weeks, Chet and I produced a number of
                different solutions to exactly the same problem. The largest was
                about five times larger than the smallest.

                We wrote more code ... were we five times more productive in the
                larger case?

                Ron Jeffries
                www.XProgramming.com
                If you want to garden, you have to bend down and touch the soil.
                Gardening is a practice, not an idea.
                -- Thich Nhat Hanh
              • Ron Jeffries
                ... Yes. What is interesting about the case I mentioned is that it was the same programmers solving the same problem with the same language, on a few
                Message 7 of 20 , Mar 29 5:02 AM
                • 0 Attachment
                  On Wednesday, March 29, 2006, at 6:56:31 AM, Steven Farlie wrote:

                  > Ron Jeffries wrote:
                  >> On Wednesday, March 29, 2006, at 7:07:01 AM, mpkirby@... wrote:
                  >>
                  >>> I have seen evidence, however, that lines of code is a reasonable
                  >>> approximation of complexity, so as a measure of how quickly the
                  >>> team produces "complexity" it's pretty useful. Of course much of
                  >>> what agile is about is reducing complexity, so that's pretty
                  >>> worthless in its own :-)
                  >>
                  >> In the past couple of weeks, Chet and I produced a number of
                  >> different solutions to exactly the same problem. The largest was
                  >> about five times larger than the smallest.
                  >>
                  >> We wrote more code ... were we five times more productive in the
                  >> larger case?

                  > The key to understanding metrics is to know when they are meaningless.
                  > I've used LOC as a metric before, but it is only useful when comparing
                  > two very similar projects using the same tech. Even then it is only a
                  > single data point which doesn't tell much by itself. It is definitely
                  > not a good basis for measuring such an abstract concept as "productivity".

                  > 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.

                  Yes. What is interesting about the case I mentioned is that it was
                  the same programmers solving the same problem with the same
                  language, on a few consecutive days.

                  And a factor of five or more in code size. Most peculiar.

                  Ron Jeffries
                  www.XProgramming.com
                  Do I contradict myself? Very well then I contradict myself.
                  (I am large, I contain multitudes.) --Walt Whitman
                • jay_conne
                  ... meaningless. ... sense of ... metrics. At ... Steven, This is exquisite - I m going to quote you in my training classes and my coaching. It ll be a
                  Message 8 of 20 , Mar 29 10:31 AM
                  • 0 Attachment
                    --- In scrumdevelopment@yahoogroups.com, Steven Farlie <steven@...>
                    wrote:
                    >
                    > The key to understanding metrics is to know when they are
                    meaningless.

                    <snip>

                    > 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
                    >

                    Steven,

                    This is exquisite - I'm going to quote you in my training classes
                    and my coaching. It'll be a slide in 5 minutes. May I use your
                    full name in the reference?

                    Thanks,

                    Jay Conne
                  • Deb
                    ... 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
                    Message 9 of 20 , Mar 30 5:11 AM
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, Steven Farlie <steven@...> 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
                    • 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 10 of 20 , Mar 30 5:52 AM
                      • 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/
                        >
                        >
                        >
                      • Carol Wellington
                        I am a strong advocate for metrics and I agree that skepticism is one of the best attributes of someone who is gathering or looking at metrics. I like your
                        Message 11 of 20 , Mar 30 6:54 AM
                        • 0 Attachment
                          I am a strong advocate for metrics and I agree that skepticism is
                          one of the best attributes of someone who is gathering or looking at
                          metrics. I like your "basics." They are in line with agile metrics
                          philosophies I've been working on:

                          It is very easy for the activity of gathering metrics to take on a
                          life of its own. In keeping with agile philosophies, we need to keep
                          our metrics activities as lightweight as possible. We don't want to
                          spend a lot of time gathering data, analyzing the data, or sifting
                          through results. These guidelines will help keep our metrics
                          activities in check:
                          - Napkin metrics – Every metric should be simple enough that you can
                          explain its computation on a napkin in the cafeteria. Anything more
                          complicated than that is likely to be gathered incorrectly or
                          misunderstood and therefore used incorrectly. If your metrics become
                          too complex, take a step back and re-think!
                          - Simplify data gathering – Most data that you need for metrics can
                          be gathered as a part of other activities. Valuable data can be
                          found in your Accounting Department, your defect database, your
                          customer service center, and your configuration management system.
                          See if your build process, your defect-tracking tool, or your
                          planning process can gather the data for you. If you're interested
                          in the rate at which the system (or any part of it) is changing, put
                          a script into the build process. If you want to track the time spent
                          on each task, make it easy for the engineer to jot a value down when
                          she's marking the task complete instead of making her track it
                          through the week to put it in a report at the end of the week.
                          - Rough numbers are good enough – Always think about the precision
                          (or lack of precision) that you need in the data you gather. Often,
                          it's easier to gather coarser data without distorting the
                          conclusions you draw. For example, a car speedometer has a 10% error
                          rate, but it's good enough to keep us from speeding out of control.
                          Engineers can report time spent to the half-hour a lot more easily
                          than to the minute. If your estimation granularity is to the half-
                          day or even to the hour, then reporting time spent to the half-hour
                          is quite sufficient.

                          - If it isn't changing, who cares? – When you initially pick a
                          metric whose goal is to change some behavior, its value should
                          change. However, at some point, the team will have done all it can
                          on that particular issue and then the metric will level out. At that
                          point, there's no longer any point in gathering and tracking that
                          metric (though you may want to bring it back again at a later date).
                          Similarly, metrics whose values are always 0 or 100% aren't useful
                          either.

                          >
                          > 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
                          >
                        • Ken Schwaber
                          A test that I heard someone apply was, what does that have to do with code? I think every metric should be zero sum, with an expiration date of 3 months.
                          Message 12 of 20 , Mar 30 7:27 AM
                          • 0 Attachment

                            A test that I heard someone apply was, “what does that have to do with code?”  I think every metric should be zero sum, with an expiration date of 3 months. Make the justification greater than the collection.

                            Ken

                             


                            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Carol Wellington
                            Sent: Thursday, March 30, 2006 9:54 AM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: [scrumdevelopment] Love/Hate Agile Metrics - was Re: Jeff Sutherland's paper on Distributed Scru...

                             

                            I am a strong advocate for metrics and I agree that skepticism is
                            one of the best attributes of someone who is gathering or looking at
                            metrics.  I like your "basics."  They are in line with agile metrics
                            philosophies I've been working on:

                            It is very easy for the activity of gathering metrics to take on a
                            life of its own. In keeping with agile philosophies, we need to keep
                            our metrics activities as lightweight as possible. We don't want to
                            spend a lot of time gathering data, analyzing the data, or sifting
                            through results. These guidelines will help keep our metrics
                            activities in check:
                            - Napkin metrics – Every metric should be simple enough that you can
                            explain its computation on a napkin in the cafeteria. Anything more
                            complicated than that is likely to be gathered incorrectly or
                            misunderstood and therefore used incorrectly. If your metrics become
                            too complex, take a step back and re-think!
                            - Simplify data gathering – Most data that you need for metrics can
                            be gathered as a part of other activities. Valuable data can be
                            found in your Accounting Department, your defect database, your
                            customer service center, and your configuration management system. 
                            See if your build process, your defect-tracking tool, or your
                            planning process can gather the data for you. If you're interested
                            in the rate at which the system (or any part of it) is changing, put
                            a script into the build process. If you want to track the time spent
                            on each task, make it easy for the engineer to jot a value down when
                            she's marking the task complete instead of making her track it
                            through the week to put it in a report at the end of the week.
                            - Rough numbers are good enough – Always think about the precision
                            (or lack of precision) that you need in the data you gather. Often,
                            it's easier to gather coarser data without distorting the
                            conclusions you draw. For example, a car speedometer has a 10% error
                            rate, but it's good enough to keep us from speeding out of control.
                            Engineers can report time spent to the half-hour a lot more easily
                            than to the minute. If your estimation granularity is to the half-
                            day or even to the hour, then reporting time spent to the half-hour
                            is quite sufficient.

                            - If it isn't changing, who cares? – When you initially pick a
                            metric whose goal is to change some behavior, its value should
                            change. However, at some point, the team will have done all it can
                            on that particular issue and then the metric will level out. At that
                            point, there's no longer any point in gathering and tracking that
                            metric (though you may want to bring it back again at a later date).
                            Similarly, metrics whose values are always 0 or 100% aren't useful
                            either.

                            >
                            > 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
                            >






                          • Deb
                            ... Ken, I think this is a good start, but it is only useful if the organization is also watching out for what does that code have to do with making money /
                            Message 13 of 20 , Mar 30 11:46 AM
                            • 0 Attachment
                              --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                              <ken.schwaber@...> wrote:
                              >
                              > A test that I heard someone apply was, "what does that have to do with
                              > code?" ...
                              >
                              > Ken
                              >

                              Ken, I think this is a good start, but it is only useful if the
                              organization is also watching out for "what does that code have to do
                              with making money / gaining new customers / (whatever our prime metric
                              is)".

                              Too many groups I've seen are cranking out code that the organization
                              does not need or even really know about. The days of geek-driven
                              development are hopefully numbered... I think that's why so many of
                              us are thinking about Scrum in the Enterprise.

                              Developers should (somehow) be able to see that their work is directly
                              or indirectly earning/creating value for the organization. For one
                              thing, this improves their job security, and hence morale and quality!
                              But there are many good reasons to do this. Like, making money /
                              gaining new customers / ...

                              :-)
                              deb
                            • 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 14 of 20 , Mar 30 11:12 PM
                              • 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 15 of 20 , Mar 31 1:00 PM
                                • 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 16 of 20 , Apr 1, 2006
                                  • 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 17 of 20 , Apr 2, 2006
                                    • 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 18 of 20 , Apr 2, 2006
                                      • 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 19 of 20 , Apr 2, 2006
                                        • 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 20 of 20 , Apr 3, 2006
                                          • 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.