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

Re: How popular is SCRUM and agile?

Expand Messages
  • Adam Feldman
    ... Re: How popular is SCRUM and agile? All, I have recently joined this group and followed the discussions quite closely. It is great to find such an active
    Message 1 of 22 , Jul 28, 2009
    • 0 Attachment
      Re: How popular is SCRUM and agile?
      All,

      I have recently joined this group and followed the discussions quite closely. It is great to find such an active group.

      I am currently putting together a business case for one of our clients and I am looking for some cold, hard facts.  Have any of you seen or even written papers, studies, surveys etc. on how popular Agile and SCRUM really is?

      I have seen some things like “SCRUM was used by X% of the world in 2007, X+1 in 2008 and X+100 in 2009”. I am looking for stuff like this, from a quotable source?

      Any ideas?

      Thanks!

      Adam

    • George Dinwiddie
      ... Perhaps http://biblio.gdinwiddie.com/biblio/SurveyResults will help. -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software
      Message 2 of 22 , Jul 28, 2009
      • 0 Attachment
        Adam Feldman wrote:
        > I have seen some things like “SCRUM was used by X% of the world in
        > 2007, X+1 in 2008 and X+100 in 2009”. I am looking for stuff like
        > this, from a quotable source?

        Perhaps http://biblio.gdinwiddie.com/biblio/SurveyResults will help.

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Adam Feldman
        George - Thanks for sending this link my way, very helpful, much appreciated.
        Message 3 of 22 , Jul 29, 2009
        • 0 Attachment
          George - Thanks for sending this link my way, very helpful, much
          appreciated.


          On 28/07/2009 13:03, "George Dinwiddie" <lists@...> wrote:

          > Adam Feldman wrote:
          >> I have seen some things like ³SCRUM was used by X% of the world in
          >> 2007, X+1 in 2008 and X+100 in 2009². I am looking for stuff like
          >> this, from a quotable source?
          >
          > Perhaps http://biblio.gdinwiddie.com/biblio/SurveyResults will help.
        • George Dinwiddie
          Adam, If you find other interesting published figures, please add them to that bibliography. - George ... -- ... * George Dinwiddie *
          Message 4 of 22 , Jul 29, 2009
          • 0 Attachment
            Adam,

            If you find other interesting published figures, please add them to that
            bibliography.

            - George

            Adam Feldman wrote:
            > George - Thanks for sending this link my way, very helpful, much
            > appreciated.
            >
            >
            > On 28/07/2009 13:03, "George Dinwiddie" <lists@...> wrote:
            >
            >> Adam Feldman wrote:
            >>> I have seen some things like ³SCRUM was used by X% of the world in
            >>> 2007, X+1 in 2008 and X+100 in 2009². I am looking for stuff like
            >>> this, from a quotable source?
            >> Perhaps http://biblio.gdinwiddie.com/biblio/SurveyResults will help.

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Peter Stevens (cal)
            Hi Adam, According to statistics quoted by Ken Schwaber at the Zurich Lean Agile Scrum Conference this june, more than half of all projects surveyed claimed to
            Message 5 of 22 , Jul 30, 2009
            • 0 Attachment
              Hi Adam,

              According to statistics quoted by Ken Schwaber at the Zurich Lean Agile Scrum Conference this june, more than half of all projects surveyed claimed to be doing agile in 2008. Of those, 84% claim to be doing Scrum. See page 3 of his presentation.

              Cheers,

              Peter





              Adam Feldman wrote:
               


              All,

              I have recently joined this group and followed the discussions quite closely. It is great to find such an active group.

              I am currently putting together a business case for one of our clients and I am looking for some cold, hard facts.  Have any of you seen or even written papers, studies, surveys etc. on how popular Agile and SCRUM really is?

              I have seen some things like “SCRUM was used by X% of the world in 2007, X+1 in 2008 and X+100 in 2009”. I am looking for stuff like this, from a quotable source?

              Any ideas?

              Thanks!

              Adam


            • Adam Sroka
              Ken s numbers match my experience, but I wonder how many of those 84% are doing some kind of Scrum-but with absolutely none of the Agile engineering
              Message 6 of 22 , Jul 30, 2009
              • 0 Attachment
                Ken's numbers match my experience, but I wonder how many of those 84%
                are doing some kind of Scrum-but with absolutely none of the Agile
                "engineering practices." And, of those who claim to be doing some form
                of Agile that isn't Scrum, I wonder how many are actually doing
                anything that would remotely resemble Agile to you or I.

                Also, as an aside, I've noticed that nearly every job description now
                says "Experience with agile methodologies - especially Scrum or XP -
                is desirable," or something quite similar. It makes using the job
                boards more difficult, because nine out of ten of the results for
                "agile," "XP," and "Scrum," are false positives (For my purposes.)

                On Thu, Jul 30, 2009 at 7:49 PM, Peter Stevens (cal)<peterstev@...> wrote:
                >
                >
                > Hi Adam,
                >
                > According to statistics quoted by Ken Schwaber at the Zurich Lean Agile
                > Scrum Conference this june, more than half of all projects surveyed claimed
                > to be doing agile in 2008. Of those, 84% claim to be doing Scrum. See page 3
                > of his presentation.
                >
                > Cheers,
                >
                > Peter
                >
                >
                >
                >
                >
                > Adam Feldman wrote:
                >
                >
                >
                > All,
                >
                > I have recently joined this group and followed the discussions quite
                > closely. It is great to find such an active group.
                >
                > I am currently putting together a business case for one of our clients and I
                > am looking for some cold, hard facts.  Have any of you seen or even written
                > papers, studies, surveys etc. on how popular Agile and SCRUM really is?
                >
                > I have seen some things like “SCRUM was used by X% of the world in 2007, X+1
                > in 2008 and X+100 in 2009”. I am looking for stuff like this, from a
                > quotable source?
                >
                > Any ideas?
                >
                > Thanks!
                >
                > Adam
                >
                >
                >
              • Peter Stevens (cal)
                Hi Adam, That s the problem with any self-reporting and lack of branding. What the asker of a question means with the question and how the respondent
                Message 7 of 22 , Jul 31, 2009
                • 0 Attachment
                  Hi Adam,

                  That's the problem with any self-reporting and lack of branding. What the asker of a question means with the question and how the respondent interprets the question can be two entirely different things.

                  At last year's Agile Business Conference in London, keynote speaker Rob Thomsett defined Agile as a set of values, not as a set of practices: Openness, Trust, Honesty, Courage and Fiscal Responsibility. So projects using everything from Scrum to XP to DSDM to RUP could claim to be Agile.

                  I conducted a poll last summer asking the 8 questions of the Nokia test. "Is anybody really doing Scrum?" 3/4th of the respondents scored 7 or less. Because of the tool used to collect the data, I couldn't tell how many satisfied Nokia's definition of Agile (First 3 questions). The number of respondents was also rather small -- 47 -- so one might question how representative this poll was. Since then, Robin Dymond has been started a project to get 1000 respondents to answer an extended version of the test. Last I heard, he had 360 respondents, so he hasn't published any results yet.

                  The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO of tilllate.com, described his company's getting started with Scrum. When he started, he didn't believe that Scrum would work in his company, so he changed it. Pretty dramatically. For instance, time boxes yes, fixed length iterations no. At the beginning of his talk, I wondered if we could even call his process Scrum. He definitely broke a lot of rules of Scrum. But he stayed true to inspect and adapt. That process brought him closer to Scrum by the book (adding retrospectives, daily scrums, ready to try again with fixed length iterations, etc).

                  The talk was a real eye opener. If your top management gets the principles of Scrum, the practices are less of an issue. If they don't, well, it can be tough.

                  Scrum doesn't actually specify any engineering practices. It specifies three constraints:
                  • work committed at the beginning of a sprint must have value to the customer or user
                  • work committed at the beginning of a sprint must be finished at the end of the sprint.
                  • the team must complete the work according to a formal definition of done
                  These constraints drive most teams to move towards XP engineering practices (even though there is no requirement to do so).  I am not aware of any evidence which shows that doing agile engineering leads companies to adopt agile management practices, so Scrum is the place to start.

                  So, coming back to your original post, I think you've got the numbers and messages you need:
                  1. > 50% of all IT projects are doing (or trying to do) agile.
                  2. 84% of them do (or are trying to do) Scrum -- and this is the place to start.
                  3. Scrum is hard, so management buy in and commitment are essential.
                  Now it's time for management to self organize: "How do you convince yourselves the Scrum and Agile are worthy of serious commitment? How do you learn to walk the walk?"

                  Cheers,

                  Peter



                  Adam Sroka wrote:
                  Ken's numbers match my experience, but I wonder how many of those 84%
                  are doing some kind of Scrum-but with absolutely none of the Agile
                  "engineering practices." And, of those who claim to be doing some form
                  of Agile that isn't Scrum, I wonder how many are actually doing
                  anything that would remotely resemble Agile to you or I.
                  
                  Also, as an aside, I've noticed that nearly every job description now
                  says "Experience with agile methodologies - especially Scrum or XP -
                  is desirable," or something quite similar. It makes using the job
                  boards more difficult, because nine out of ten of the results for
                  "agile," "XP," and "Scrum," are false positives (For my purposes.)
                    

                • Dan Rawsthorne
                  I love what you wrote, especially about the principles and values of scrum, but I disagree with all of your constraints :) * work committed at the beginning of
                  Message 8 of 22 , Jul 31, 2009
                  • 0 Attachment
                    I love what you wrote, especially about the principles and values of
                    scrum, but I disagree with all of your constraints :)

                    * work committed at the beginning of a sprint must have value to the
                    customer or user - I disagree. There are many sorts of value.
                    Scrum is silent on which ones to use. All you know is that the PO
                    prioritized it

                    * work committed at the beginning of a sprint must be finished at
                    the end of the sprint. - I disagree. There is a commitment. It is
                    unclear what that commitment means. If there is pressure to finish
                    nomatter what, technical debt and unsustainable pace naturally
                    follow. So, again, what do you value?

                    * the team must complete the work according to a formal definition
                    of done - I nearly agree.I only disagree with the word "formal"
                    here. I say "agreed to" definition of done

                    The main think I know about scrum is once you get past the basics of
                    "inspect and adapt" for both your product and process, virtually
                    everything is malleable. That's on purpose, I think, because the purpose
                    is to maximize what your organization values, whatever that is.

                    Dan Rawsthorne, PhD, CST
                    Senior Coach, Danube Technologies
                    dan@..., 425-269-8628



                    Peter Stevens (cal) wrote:
                    >
                    >
                    > Hi Adam,
                    >
                    > That's the problem with any self-reporting and lack of branding. What
                    > the asker of a question means with the question and how the respondent
                    > interprets the question can be two entirely different things.
                    >
                    > At last year's Agile Business Conference in London, keynote speaker
                    > Rob Thomsett defined Agile as a set of values, not as a set of
                    > practices: Openness, Trust, Honesty, Courage and Fiscal
                    > Responsibility. So projects using everything from Scrum to XP to DSDM
                    > to RUP could claim to be Agile.
                    >
                    > I conducted a poll last summer asking the 8 questions of the Nokia
                    > test. "Is anybody really doing Scrum
                    > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?"
                    > 3/4th of the respondents scored 7 or less. Because of the tool used to
                    > collect the data, I couldn't tell how many satisfied Nokia's
                    > definition of Agile (First 3 questions). The number of respondents was
                    > also rather small -- 47 -- so one might question how representative
                    > this poll was. Since then, Robin Dymond has been started a project to
                    > get 1000 respondents to answer an extended version of the test. Last I
                    > heard, he had 360 respondents, so he hasn't published any results yet.
                    >
                    > The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
                    > of tilllate.com, described his company's getting started with Scrum.
                    > When he started, he didn't believe that Scrum would work in his
                    > company, so he changed it. Pretty dramatically. For instance, time
                    > boxes yes, fixed length iterations no. At the beginning of his talk, I
                    > wondered if we could even call his process Scrum. He definitely broke
                    > a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                    > process brought him closer to Scrum by the book (adding
                    > retrospectives, daily scrums, ready to try again with fixed length
                    > iterations, etc).
                    >
                    > The talk was a real eye opener. If your top management gets the
                    > principles of Scrum, the practices are less of an issue. If they
                    > don't, well, it can be tough.
                    >
                    > Scrum doesn't actually specify any engineering practices. It specifies
                    > three constraints:
                    >
                    > * work committed at the beginning of a sprint must have value to
                    > the customer or user
                    > * work committed at the beginning of a sprint must be finished at
                    > the end of the sprint.
                    > * the team must complete the work according to a formal definition
                    > of done
                    >
                    > These constraints drive most teams to move towards XP engineering
                    > practices (even though there is no requirement to do so). I am not
                    > aware of any evidence which shows that doing agile engineering leads
                    > companies to adopt agile management practices, so Scrum is the place
                    > to start.
                    >
                    > So, coming back to your original post, I think you've got the numbers
                    > and messages you need:
                    >
                    > 1. > 50% of all IT projects are doing (or trying to do) agile.
                    > 2. 84% of them do (or are trying to do) Scrum -- and this is the
                    > place to start.
                    > 3. Scrum is hard, so management buy in and commitment are essential.
                    >
                    > Now it's time for management to self organize: "How do you convince
                    > yourselves the Scrum and Agile are worthy of serious commitment? How
                    > do you learn to walk the walk?"
                    >
                    > Cheers,
                    >
                    > Peter
                    >
                    >
                    >
                    > Adam Sroka wrote:
                    >> Ken's numbers match my experience, but I wonder how many of those 84%
                    >> are doing some kind of Scrum-but with absolutely none of the Agile
                    >> "engineering practices." And, of those who claim to be doing some form
                    >> of Agile that isn't Scrum, I wonder how many are actually doing
                    >> anything that would remotely resemble Agile to you or I.
                    >>
                    >> Also, as an aside, I've noticed that nearly every job description now
                    >> says "Experience with agile methodologies - especially Scrum or XP -
                    >> is desirable," or something quite similar. It makes using the job
                    >> boards more difficult, because nine out of ten of the results for
                    >> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                    >>
                    >
                    >
                  • Adam Sroka
                    On Fri, Jul 31, 2009 at 9:47 AM, Dan ... The focus on *Customer* value is part of what makes it Agile (See Manifesto). It is true that Scrum doesn t say we
                    Message 9 of 22 , Jul 31, 2009
                    • 0 Attachment
                      On Fri, Jul 31, 2009 at 9:47 AM, Dan
                      Rawsthorne<dan.rawsthorne@...> wrote:
                      > I love what you wrote, especially about the principles and values of
                      > scrum, but I disagree with all of your constraints :)
                      >
                      >    * work committed at the beginning of a sprint must have value to the
                      >      customer or user - I disagree. There are many sorts of value.
                      >      Scrum is silent on which ones to use. All you know is that the PO
                      >      prioritized it
                      >

                      The focus on *Customer* value is part of what makes it Agile (See
                      Manifesto). It is true that Scrum doesn't say we have to focus on
                      customer value per se. Thus, it might be possible to be doing Scrum
                      and not doing Agile Software Development. That's fine, but I think you
                      need to be explicit about it. There are too many teams who think that
                      what they are doing is Agile but it is not, and they don't really have
                      any idea why.

                      >    * work committed at the beginning of a sprint must be finished at
                      >      the end of the sprint. - I disagree. There is a commitment. It is
                      >      unclear what that commitment means. If there is pressure to finish
                      >      nomatter what, technical debt and unsustainable pace naturally
                      >      follow. So, again, what do you value?
                      >

                      I suppose the "no matter what" part is problematic. Certainly we may
                      feel the need to inspect-and-adapt during the Sprint, and that should
                      be okay. However, shouldn't we at least be making an honest attempt to
                      commit to what we thing we can do and then do it? (Absent unforeseen
                      external pressures.)

                      >    * the team must complete the work according to a formal definition
                      >      of done - I nearly agree.I only disagree with the word "formal"
                      >      here. I say "agreed to" definition of done
                      >

                      +1

                      > The main think I know about scrum is once you get past the basics of
                      > "inspect and adapt" for both your product and process, virtually
                      > everything is malleable. That's on purpose, I think, because the purpose
                      > is to maximize what your organization values, whatever that is.
                      >
                      > Dan Rawsthorne, PhD, CST
                      > Senior Coach, Danube Technologies
                      > dan@..., 425-269-8628
                      >
                      >
                      >
                      > Peter Stevens (cal) wrote:
                      >>
                      >>
                      >> Hi Adam,
                      >>
                      >> That's the problem with any self-reporting and lack of branding. What
                      >> the asker of a question means with the question and how the respondent
                      >> interprets the question can be two entirely different things.
                      >>
                      >> At last year's Agile Business Conference in London, keynote speaker
                      >> Rob Thomsett defined Agile as a set of values, not as a set of
                      >> practices: Openness, Trust, Honesty, Courage and Fiscal
                      >> Responsibility. So projects using everything from Scrum to XP to DSDM
                      >> to RUP could claim to be Agile.
                      >>
                      >> I conducted a poll last summer asking the 8 questions of the Nokia
                      >> test. "Is anybody really doing Scrum
                      >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?"
                      >> 3/4th of the respondents scored 7 or less. Because of the tool used to
                      >> collect the data, I couldn't tell how many satisfied Nokia's
                      >> definition of Agile (First 3 questions). The number of respondents was
                      >> also rather small -- 47 -- so one might question how representative
                      >> this poll was. Since then, Robin Dymond has been started a project to
                      >> get 1000 respondents to answer an extended version of the test. Last I
                      >> heard, he had 360 respondents, so he hasn't published any results yet.
                      >>
                      >> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
                      >> of tilllate.com, described his company's getting started with Scrum.
                      >> When he started, he didn't believe that Scrum would work in his
                      >> company, so he changed it. Pretty dramatically. For instance, time
                      >> boxes yes, fixed length iterations no. At the beginning of his talk, I
                      >> wondered if we could even call his process Scrum. He definitely broke
                      >> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                      >> process brought him closer to Scrum by the book (adding
                      >> retrospectives, daily scrums, ready to try again with fixed length
                      >> iterations, etc).
                      >>
                      >> The talk was a real eye opener. If your top management gets the
                      >> principles of Scrum, the practices are less of an issue. If they
                      >> don't, well, it can be tough.
                      >>
                      >> Scrum doesn't actually specify any engineering practices. It specifies
                      >> three constraints:
                      >>
                      >>     * work committed at the beginning of a sprint must have value to
                      >>       the customer or user
                      >>     * work committed at the beginning of a sprint must be finished at
                      >>       the end of the sprint.
                      >>     * the team must complete the work according to a formal definition
                      >>       of done
                      >>
                      >> These constraints drive most teams to move towards XP engineering
                      >> practices (even though there is no requirement to do so).  I am not
                      >> aware of any evidence which shows that doing agile engineering leads
                      >> companies to adopt agile management practices, so Scrum is the place
                      >> to start.
                      >>
                      >> So, coming back to your original post, I think you've got the numbers
                      >> and messages you need:
                      >>
                      >>    1. > 50% of all IT projects are doing (or trying to do) agile.
                      >>    2. 84% of them do (or are trying to do) Scrum -- and this is the
                      >>       place to start.
                      >>    3. Scrum is hard, so management buy in and commitment are essential.
                      >>
                      >> Now it's time for management to self organize: "How do you convince
                      >> yourselves the Scrum and Agile are worthy of serious commitment? How
                      >> do you learn to walk the walk?"
                      >>
                      >> Cheers,
                      >>
                      >> Peter
                      >>
                      >>
                      >>
                      >> Adam Sroka wrote:
                      >>> Ken's numbers match my experience, but I wonder how many of those 84%
                      >>> are doing some kind of Scrum-but with absolutely none of the Agile
                      >>> "engineering practices." And, of those who claim to be doing some form
                      >>> of Agile that isn't Scrum, I wonder how many are actually doing
                      >>> anything that would remotely resemble Agile to you or I.
                      >>>
                      >>> Also, as an aside, I've noticed that nearly every job description now
                      >>> says "Experience with agile methodologies - especially Scrum or XP -
                      >>> is desirable," or something quite similar. It makes using the job
                      >>> boards more difficult, because nine out of ten of the results for
                      >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                      >>>
                      >>
                      >>
                      >
                      >
                      > ------------------------------------
                      >
                      > To Post a message, send it to:   scrumdevelopment@...
                      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      >
                      >
                      >
                      >
                    • jmilunsky
                      I am not sure I buy the comment that you can be doing Scrum and not be doing Agile Software Development. Jack blog.agilebuddy.com www.agilebuddy.com
                      Message 10 of 22 , Jul 31, 2009
                      • 0 Attachment
                        I am not sure I buy the comment that you can be doing Scrum and not be doing Agile Software Development.

                        Jack
                        blog.agilebuddy.com
                        www.agilebuddy.com
                        twitter.com/agilebuddy


                        --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                        >
                        > On Fri, Jul 31, 2009 at 9:47 AM, Dan
                        > Rawsthorne<dan.rawsthorne@...> wrote:
                        > > I love what you wrote, especially about the principles and values of
                        > > scrum, but I disagree with all of your constraints :)
                        > >
                        > > � �* work committed at the beginning of a sprint must have value to the
                        > > � � �customer or user - I disagree. There are many sorts of value.
                        > > � � �Scrum is silent on which ones to use. All you know is that the PO
                        > > � � �prioritized it
                        > >
                        >
                        > The focus on *Customer* value is part of what makes it Agile (See
                        > Manifesto). It is true that Scrum doesn't say we have to focus on
                        > customer value per se. Thus, it might be possible to be doing Scrum
                        > and not doing Agile Software Development. That's fine, but I think you
                        > need to be explicit about it. There are too many teams who think that
                        > what they are doing is Agile but it is not, and they don't really have
                        > any idea why.
                        >
                        > > � �* work committed at the beginning of a sprint must be finished at
                        > > � � �the end of the sprint. - I disagree. There is a commitment. It is
                        > > � � �unclear what that commitment means. If there is pressure to finish
                        > > � � �nomatter what, technical debt and unsustainable pace naturally
                        > > � � �follow. So, again, what do you value?
                        > >
                        >
                        > I suppose the "no matter what" part is problematic. Certainly we may
                        > feel the need to inspect-and-adapt during the Sprint, and that should
                        > be okay. However, shouldn't we at least be making an honest attempt to
                        > commit to what we thing we can do and then do it? (Absent unforeseen
                        > external pressures.)
                        >
                        > > � �* the team must complete the work according to a formal definition
                        > > � � �of done - I nearly agree.I only disagree with the word "formal"
                        > > � � �here. I say "agreed to" definition of done
                        > >
                        >
                        > +1
                        >
                        > > The main think I know about scrum is once you get past the basics of
                        > > "inspect and adapt" for both your product and process, virtually
                        > > everything is malleable. That's on purpose, I think, because the purpose
                        > > is to maximize what your organization values, whatever that is.
                        > >
                        > > Dan Rawsthorne, PhD, CST
                        > > Senior Coach, Danube Technologies
                        > > dan@..., 425-269-8628
                        > >
                        > >
                        > >
                        > > Peter Stevens (cal) wrote:
                        > >>
                        > >>
                        > >> Hi Adam,
                        > >>
                        > >> That's the problem with any self-reporting and lack of branding. What
                        > >> the asker of a question means with the question and how the respondent
                        > >> interprets the question can be two entirely different things.
                        > >>
                        > >> At last year's Agile Business Conference in London, keynote speaker
                        > >> Rob Thomsett defined Agile as a set of values, not as a set of
                        > >> practices: Openness, Trust, Honesty, Courage and Fiscal
                        > >> Responsibility. So projects using everything from Scrum to XP to DSDM
                        > >> to RUP could claim to be Agile.
                        > >>
                        > >> I conducted a poll last summer asking the 8 questions of the Nokia
                        > >> test. "Is anybody really doing Scrum
                        > >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?"
                        > >> 3/4th of the respondents scored 7 or less. Because of the tool used to
                        > >> collect the data, I couldn't tell how many satisfied Nokia's
                        > >> definition of Agile (First 3 questions). The number of respondents was
                        > >> also rather small -- 47 -- so one might question how representative
                        > >> this poll was. Since then, Robin Dymond has been started a project to
                        > >> get 1000 respondents to answer an extended version of the test. Last I
                        > >> heard, he had 360 respondents, so he hasn't published any results yet.
                        > >>
                        > >> The speaker at last month's the Scrum Breakfast, Silvan M�hlemann, CTO
                        > >> of tilllate.com, described his company's getting started with Scrum.
                        > >> When he started, he didn't believe that Scrum would work in his
                        > >> company, so he changed it. Pretty dramatically. For instance, time
                        > >> boxes yes, fixed length iterations no. At the beginning of his talk, I
                        > >> wondered if we could even call his process Scrum. He definitely broke
                        > >> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                        > >> process brought him closer to Scrum by the book (adding
                        > >> retrospectives, daily scrums, ready to try again with fixed length
                        > >> iterations, etc).
                        > >>
                        > >> The talk was a real eye opener. If your top management gets the
                        > >> principles of Scrum, the practices are less of an issue. If they
                        > >> don't, well, it can be tough.
                        > >>
                        > >> Scrum doesn't actually specify any engineering practices. It specifies
                        > >> three constraints:
                        > >>
                        > >> � � * work committed at the beginning of a sprint must have value to
                        > >> � � � the customer or user
                        > >> � � * work committed at the beginning of a sprint must be finished at
                        > >> � � � the end of the sprint.
                        > >> � � * the team must complete the work according to a formal definition
                        > >> � � � of done
                        > >>
                        > >> These constraints drive most teams to move towards XP engineering
                        > >> practices (even though there is no requirement to do so). �I am not
                        > >> aware of any evidence which shows that doing agile engineering leads
                        > >> companies to adopt agile management practices, so Scrum is the place
                        > >> to start.
                        > >>
                        > >> So, coming back to your original post, I think you've got the numbers
                        > >> and messages you need:
                        > >>
                        > >> � �1. > 50% of all IT projects are doing (or trying to do) agile.
                        > >> � �2. 84% of them do (or are trying to do) Scrum -- and this is the
                        > >> � � � place to start.
                        > >> � �3. Scrum is hard, so management buy in and commitment are essential.
                        > >>
                        > >> Now it's time for management to self organize: "How do you convince
                        > >> yourselves the Scrum and Agile are worthy of serious commitment? How
                        > >> do you learn to walk the walk?"
                        > >>
                        > >> Cheers,
                        > >>
                        > >> Peter
                        > >>
                        > >>
                        > >>
                        > >> Adam Sroka wrote:
                        > >>> Ken's numbers match my experience, but I wonder how many of those 84%
                        > >>> are doing some kind of Scrum-but with absolutely none of the Agile
                        > >>> "engineering practices." And, of those who claim to be doing some form
                        > >>> of Agile that isn't Scrum, I wonder how many are actually doing
                        > >>> anything that would remotely resemble Agile to you or I.
                        > >>>
                        > >>> Also, as an aside, I've noticed that nearly every job description now
                        > >>> says "Experience with agile methodologies - especially Scrum or XP -
                        > >>> is desirable," or something quite similar. It makes using the job
                        > >>> boards more difficult, because nine out of ten of the results for
                        > >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                        > >>>
                        > >>
                        > >>
                        > >
                        > >
                        > > ------------------------------------
                        > >
                        > > To Post a message, send it to: � scrumdevelopment@...
                        > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                        > >
                        > >
                        > >
                        > >
                        >
                      • Tobias Mayer
                        Jack wrote: I am not sure I buy the comment that you can be doing Scrum and not be doing Agile Software Development. Well, you can be doing Scrum and not doing
                        Message 11 of 22 , Jul 31, 2009
                        • 0 Attachment

                          Jack wrote:  I am not sure I buy the comment that you can be doing Scrum and not be doing Agile Software Development.

                          Well, you can be doing Scrum and not doing software development at all, so I guess the rest follows.

                          Tobias
                        • Dan Rawsthorne
                          Response 1: But scrum isn t about Agilily, it s about agility. I think that most teams should value the Agile Manifesto (and other stuff, as I ve posted
                          Message 12 of 22 , Jul 31, 2009
                          • 0 Attachment
                            Response 1: But scrum isn't about Agilily, it's about agility. I think
                            that most teams should value the Agile Manifesto (and other stuff, as
                            I've posted before), but it's not part of scrum. Scrum isn't restricted
                            to software, after all :)

                            Response 2: This is an interesting question, and is the reason kanban's
                            WIP is gaining traction. The force (in a patterns sense) of commitment
                            often leads to bad stuff. Scrum requires commitment, but is largely
                            silent on what that means. I'd like to have a 2-3 hour discussion on
                            this sometime, just to see if there some "there" there.

                            Dan Rawsthorne, PhD, CST
                            Senior Coach, Danube Technologies
                            dan@..., 425-269-8628



                            Adam Sroka wrote:
                            >
                            >
                            > On Fri, Jul 31, 2009 at 9:47 AM, Dan
                            > Rawsthorne<dan.rawsthorne@...
                            > <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
                            > > I love what you wrote, especially about the principles and values of
                            > > scrum, but I disagree with all of your constraints :)
                            > >
                            > > * work committed at the beginning of a sprint must have value to the
                            > > customer or user - I disagree. There are many sorts of value.
                            > > Scrum is silent on which ones to use. All you know is that the PO
                            > > prioritized it
                            > >
                            >
                            > The focus on *Customer* value is part of what makes it Agile (See
                            > Manifesto). It is true that Scrum doesn't say we have to focus on
                            > customer value per se. Thus, it might be possible to be doing Scrum
                            > and not doing Agile Software Development. That's fine, but I think you
                            > need to be explicit about it. There are too many teams who think that
                            > what they are doing is Agile but it is not, and they don't really have
                            > any idea why.
                            >
                            > > * work committed at the beginning of a sprint must be finished at
                            > > the end of the sprint. - I disagree. There is a commitment. It is
                            > > unclear what that commitment means. If there is pressure to finish
                            > > nomatter what, technical debt and unsustainable pace naturally
                            > > follow. So, again, what do you value?
                            > >
                            >
                            > I suppose the "no matter what" part is problematic. Certainly we may
                            > feel the need to inspect-and-adapt during the Sprint, and that should
                            > be okay. However, shouldn't we at least be making an honest attempt to
                            > commit to what we thing we can do and then do it? (Absent unforeseen
                            > external pressures.)
                            >
                            > > * the team must complete the work according to a formal definition
                            > > of done - I nearly agree.I only disagree with the word "formal"
                            > > here. I say "agreed to" definition of done
                            > >
                            >
                            > +1
                            >
                            > > The main think I know about scrum is once you get past the basics of
                            > > "inspect and adapt" for both your product and process, virtually
                            > > everything is malleable. That's on purpose, I think, because the purpose
                            > > is to maximize what your organization values, whatever that is.
                            > >
                            > > Dan Rawsthorne, PhD, CST
                            > > Senior Coach, Danube Technologies
                            > > dan@... <mailto:dan%40danube.com>, 425-269-8628
                            > >
                            > >
                            > >
                            > > Peter Stevens (cal) wrote:
                            > >>
                            > >>
                            > >> Hi Adam,
                            > >>
                            > >> That's the problem with any self-reporting and lack of branding. What
                            > >> the asker of a question means with the question and how the respondent
                            > >> interprets the question can be two entirely different things.
                            > >>
                            > >> At last year's Agile Business Conference in London, keynote speaker
                            > >> Rob Thomsett defined Agile as a set of values, not as a set of
                            > >> practices: Openness, Trust, Honesty, Courage and Fiscal
                            > >> Responsibility. So projects using everything from Scrum to XP to DSDM
                            > >> to RUP could claim to be Agile.
                            > >>
                            > >> I conducted a poll last summer asking the 8 questions of the Nokia
                            > >> test. "Is anybody really doing Scrum
                            > >>
                            > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                            > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>?"
                            > >> 3/4th of the respondents scored 7 or less. Because of the tool used to
                            > >> collect the data, I couldn't tell how many satisfied Nokia's
                            > >> definition of Agile (First 3 questions). The number of respondents was
                            > >> also rather small -- 47 -- so one might question how representative
                            > >> this poll was. Since then, Robin Dymond has been started a project to
                            > >> get 1000 respondents to answer an extended version of the test. Last I
                            > >> heard, he had 360 respondents, so he hasn't published any results yet.
                            > >>
                            > >> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
                            > >> of tilllate.com, described his company's getting started with Scrum.
                            > >> When he started, he didn't believe that Scrum would work in his
                            > >> company, so he changed it. Pretty dramatically. For instance, time
                            > >> boxes yes, fixed length iterations no. At the beginning of his talk, I
                            > >> wondered if we could even call his process Scrum. He definitely broke
                            > >> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                            > >> process brought him closer to Scrum by the book (adding
                            > >> retrospectives, daily scrums, ready to try again with fixed length
                            > >> iterations, etc).
                            > >>
                            > >> The talk was a real eye opener. If your top management gets the
                            > >> principles of Scrum, the practices are less of an issue. If they
                            > >> don't, well, it can be tough.
                            > >>
                            > >> Scrum doesn't actually specify any engineering practices. It specifies
                            > >> three constraints:
                            > >>
                            > >> * work committed at the beginning of a sprint must have value to
                            > >> the customer or user
                            > >> * work committed at the beginning of a sprint must be finished at
                            > >> the end of the sprint.
                            > >> * the team must complete the work according to a formal definition
                            > >> of done
                            > >>
                            > >> These constraints drive most teams to move towards XP engineering
                            > >> practices (even though there is no requirement to do so). I am not
                            > >> aware of any evidence which shows that doing agile engineering leads
                            > >> companies to adopt agile management practices, so Scrum is the place
                            > >> to start.
                            > >>
                            > >> So, coming back to your original post, I think you've got the numbers
                            > >> and messages you need:
                            > >>
                            > >> 1. > 50% of all IT projects are doing (or trying to do) agile.
                            > >> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                            > >> place to start.
                            > >> 3. Scrum is hard, so management buy in and commitment are essential.
                            > >>
                            > >> Now it's time for management to self organize: "How do you convince
                            > >> yourselves the Scrum and Agile are worthy of serious commitment? How
                            > >> do you learn to walk the walk?"
                            > >>
                            > >> Cheers,
                            > >>
                            > >> Peter
                            > >>
                            > >>
                            > >>
                            > >> Adam Sroka wrote:
                            > >>> Ken's numbers match my experience, but I wonder how many of those 84%
                            > >>> are doing some kind of Scrum-but with absolutely none of the Agile
                            > >>> "engineering practices." And, of those who claim to be doing some form
                            > >>> of Agile that isn't Scrum, I wonder how many are actually doing
                            > >>> anything that would remotely resemble Agile to you or I.
                            > >>>
                            > >>> Also, as an aside, I've noticed that nearly every job description now
                            > >>> says "Experience with agile methodologies - especially Scrum or XP -
                            > >>> is desirable," or something quite similar. It makes using the job
                            > >>> boards more difficult, because nine out of ten of the results for
                            > >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                            > >>>
                            > >>
                            > >>
                            > >
                            > >
                            > > ------------------------------------
                            > >
                            > > To Post a message, send it to: scrumdevelopment@...
                            > <mailto:scrumdevelopment%40eGroups.com>
                            > > To Unsubscribe, send a blank message to:
                            > scrumdevelopment-unsubscribe@...
                            > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                            > >
                            > >
                            > >
                            > >
                            >
                            >
                          • Dan Rawsthorne
                            Well. since scrum isn t for software, how could you object to the statement? By definition, scrum is A team-based framework to develop complex systems and
                            Message 13 of 22 , Jul 31, 2009
                            • 0 Attachment
                              Well. since scrum isn't for software, how could you object to the
                              statement? By definition, scrum is "A team-based framework to develop
                              complex systems and products." It would be reasonable for you to say "I
                              think that when using scrum to develop software, it should be an Agile
                              Development," but I'd still disagree with you.

                              Scrum is for developing complex systems and products to meet
                              organizational goals and values. I agree that software organizations
                              *should* value the Agile Manifesto, as they *should* value delivering
                              value to customers, but it's certainly not required. The Agile Manifesto
                              is a moral statement, a statement of preferred values, and scrum is
                              merely a tool. Any team can use scrum to provide what its organization
                              values.

                              Dan Rawsthorne, PhD, CST
                              Senior Coach, Danube Technologies
                              dan@..., 425-269-8628



                              jmilunsky wrote:
                              >
                              >
                              > I am not sure I buy the comment that you can be doing Scrum and not be
                              > doing Agile Software Development.
                              >
                              > Jack
                              > blog.agilebuddy.com
                              > www.agilebuddy.com
                              > twitter.com/agilebuddy
                              >
                              > --- In scrumdevelopment@yahoogroups.com
                              > <mailto:scrumdevelopment%40yahoogroups.com>, Adam Sroka
                              > <adam.sroka@...> wrote:
                              > >
                              > > On Fri, Jul 31, 2009 at 9:47 AM, Dan
                              > > Rawsthorne<dan.rawsthorne@...> wrote:
                              > > > I love what you wrote, especially about the principles and values of
                              > > > scrum, but I disagree with all of your constraints :)
                              > > >
                              > > > � �* work committed at the beginning of a sprint must have
                              > value to the
                              > > > � � �customer or user - I disagree. There are many sorts of
                              > value.
                              > > > � � �Scrum is silent on which ones to use. All you know is
                              > that the PO
                              > > > � � �prioritized it
                              > > >
                              > >
                              > > The focus on *Customer* value is part of what makes it Agile (See
                              > > Manifesto). It is true that Scrum doesn't say we have to focus on
                              > > customer value per se. Thus, it might be possible to be doing Scrum
                              > > and not doing Agile Software Development. That's fine, but I think you
                              > > need to be explicit about it. There are too many teams who think that
                              > > what they are doing is Agile but it is not, and they don't really have
                              > > any idea why.
                              > >
                              > > > � �* work committed at the beginning of a sprint must be
                              > finished at
                              > > > � � �the end of the sprint. - I disagree. There is a
                              > commitment. It is
                              > > > � � �unclear what that commitment means. If there is
                              > pressure to finish
                              > > > � � �nomatter what, technical debt and unsustainable pace
                              > naturally
                              > > > � � �follow. So, again, what do you value?
                              > > >
                              > >
                              > > I suppose the "no matter what" part is problematic. Certainly we may
                              > > feel the need to inspect-and-adapt during the Sprint, and that should
                              > > be okay. However, shouldn't we at least be making an honest attempt to
                              > > commit to what we thing we can do and then do it? (Absent unforeseen
                              > > external pressures.)
                              > >
                              > > > � �* the team must complete the work according to a formal
                              > definition
                              > > > � � �of done - I nearly agree.I only disagree with the word
                              > "formal"
                              > > > � � �here. I say "agreed to" definition of done
                              > > >
                              > >
                              > > +1
                              > >
                              > > > The main think I know about scrum is once you get past the basics of
                              > > > "inspect and adapt" for both your product and process, virtually
                              > > > everything is malleable. That's on purpose, I think, because the
                              > purpose
                              > > > is to maximize what your organization values, whatever that is.
                              > > >
                              > > > Dan Rawsthorne, PhD, CST
                              > > > Senior Coach, Danube Technologies
                              > > > dan@..., 425-269-8628
                              > > >
                              > > >
                              > > >
                              > > > Peter Stevens (cal) wrote:
                              > > >>
                              > > >>
                              > > >> Hi Adam,
                              > > >>
                              > > >> That's the problem with any self-reporting and lack of branding. What
                              > > >> the asker of a question means with the question and how the
                              > respondent
                              > > >> interprets the question can be two entirely different things.
                              > > >>
                              > > >> At last year's Agile Business Conference in London, keynote speaker
                              > > >> Rob Thomsett defined Agile as a set of values, not as a set of
                              > > >> practices: Openness, Trust, Honesty, Courage and Fiscal
                              > > >> Responsibility. So projects using everything from Scrum to XP to DSDM
                              > > >> to RUP could claim to be Agile.
                              > > >>
                              > > >> I conducted a poll last summer asking the 8 questions of the Nokia
                              > > >> test. "Is anybody really doing Scrum
                              > > >>
                              > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                              > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>?"
                              > > >> 3/4th of the respondents scored 7 or less. Because of the tool
                              > used to
                              > > >> collect the data, I couldn't tell how many satisfied Nokia's
                              > > >> definition of Agile (First 3 questions). The number of
                              > respondents was
                              > > >> also rather small -- 47 -- so one might question how representative
                              > > >> this poll was. Since then, Robin Dymond has been started a project to
                              > > >> get 1000 respondents to answer an extended version of the test.
                              > Last I
                              > > >> heard, he had 360 respondents, so he hasn't published any results
                              > yet.
                              > > >>
                              > > >> The speaker at last month's the Scrum Breakfast, Silvan
                              > M�hlemann, CTO
                              > > >> of tilllate.com, described his company's getting started with Scrum.
                              > > >> When he started, he didn't believe that Scrum would work in his
                              > > >> company, so he changed it. Pretty dramatically. For instance, time
                              > > >> boxes yes, fixed length iterations no. At the beginning of his
                              > talk, I
                              > > >> wondered if we could even call his process Scrum. He definitely broke
                              > > >> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                              > That
                              > > >> process brought him closer to Scrum by the book (adding
                              > > >> retrospectives, daily scrums, ready to try again with fixed length
                              > > >> iterations, etc).
                              > > >>
                              > > >> The talk was a real eye opener. If your top management gets the
                              > > >> principles of Scrum, the practices are less of an issue. If they
                              > > >> don't, well, it can be tough.
                              > > >>
                              > > >> Scrum doesn't actually specify any engineering practices. It
                              > specifies
                              > > >> three constraints:
                              > > >>
                              > > >> � � * work committed at the beginning of a sprint must have
                              > value to
                              > > >> � � � the customer or user
                              > > >> � � * work committed at the beginning of a sprint must be
                              > finished at
                              > > >> � � � the end of the sprint.
                              > > >> � � * the team must complete the work according to a formal
                              > definition
                              > > >> � � � of done
                              > > >>
                              > > >> These constraints drive most teams to move towards XP engineering
                              > > >> practices (even though there is no requirement to do so). �I am not
                              > > >> aware of any evidence which shows that doing agile engineering leads
                              > > >> companies to adopt agile management practices, so Scrum is the place
                              > > >> to start.
                              > > >>
                              > > >> So, coming back to your original post, I think you've got the numbers
                              > > >> and messages you need:
                              > > >>
                              > > >> � �1. > 50% of all IT projects are doing (or trying to do) agile.
                              > > >> � �2. 84% of them do (or are trying to do) Scrum -- and this
                              > is the
                              > > >> � � � place to start.
                              > > >> � �3. Scrum is hard, so management buy in and commitment are
                              > essential.
                              > > >>
                              > > >> Now it's time for management to self organize: "How do you convince
                              > > >> yourselves the Scrum and Agile are worthy of serious commitment? How
                              > > >> do you learn to walk the walk?"
                              > > >>
                              > > >> Cheers,
                              > > >>
                              > > >> Peter
                              > > >>
                              > > >>
                              > > >>
                              > > >> Adam Sroka wrote:
                              > > >>> Ken's numbers match my experience, but I wonder how many of
                              > those 84%
                              > > >>> are doing some kind of Scrum-but with absolutely none of the Agile
                              > > >>> "engineering practices." And, of those who claim to be doing
                              > some form
                              > > >>> of Agile that isn't Scrum, I wonder how many are actually doing
                              > > >>> anything that would remotely resemble Agile to you or I.
                              > > >>>
                              > > >>> Also, as an aside, I've noticed that nearly every job
                              > description now
                              > > >>> says "Experience with agile methodologies - especially Scrum or XP -
                              > > >>> is desirable," or something quite similar. It makes using the job
                              > > >>> boards more difficult, because nine out of ten of the results for
                              > > >>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                              > > >>>
                              > > >>
                              > > >>
                              > > >
                              > > >
                              > > > ------------------------------------
                              > > >
                              > > > To Post a message, send it to: � scrumdevelopment@...
                              > > > To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@...! Groups Links
                              > > >
                              > > >
                              > > >
                              > > >
                              > >
                              >
                              >
                            • Peter Stevens (cal)
                              Hi Dan, I agree with your summary, but am puzzled by your disagreement on the constraints. * value to the user or customer - what exactly should the product
                              Message 14 of 22 , Jul 31, 2009
                              • 0 Attachment
                                Hi Dan,

                                I agree with your summary, but am puzzled by your disagreement on the constraints.

                                * value to the user or customer -> what exactly should the product owner prioritize which doesn't have value to the customer or user?

                                * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too stong. The team commits to do its best to meet the sprint goal and backlog commitments. Timebox and Quality (Definition of Done) are more important than Scope.

                                * definition of done. I agree that the definition is agreed betweeen P-O and Team (or perhaps even part of a departmental or company-wide standard, but that is advanced magic ;-) ), but what is the problem of the word 'formal'? You have X points, and the team commits to satisfying all X points before presenting the result to the P-O.

                                I have seen some variation of how the definition of done is taught. Most CST's that I have seen thought of the definition of done as a collection of quality checks, e.g. we have checked in the SW, done a code review,  all unit tests green, etc. Ken Schwaber (I had the honor of attending his CSM course in Zürich last month) presented a template defining all the tasks needed to complete a product backlog item. His goal was to prevent 'undone' work:

                                Developer: It's done.
                                P-O: OK, so we can release it.
                                Dev: Uh, no.
                                P-O: Why not?
                                Dev: Because we have to...

                                Anything after the ellipses was undone work. As teams mature, the amount of undone work after a sprint should approach zero. So you get a rather long template for assuring that all PBI's are completed to satisfaction.

                                Cheers,

                                Peter


                                Dan Rawsthorne wrote:
                                I love what you wrote, especially about the principles and values of 
                                scrum, but I disagree with all of your constraints :)
                                
                                    * work committed at the beginning of a sprint must have value to the
                                      customer or user - I disagree. There are many sorts of value.
                                      Scrum is silent on which ones to use. All you know is that the PO
                                      prioritized it
                                
                                    * work committed at the beginning of a sprint must be finished at
                                      the end of the sprint. - I disagree. There is a commitment. It is
                                      unclear what that commitment means. If there is pressure to finish
                                      nomatter what, technical debt and unsustainable pace naturally
                                      follow. So, again, what do you value?
                                
                                    * the team must complete the work according to a formal definition
                                      of done - I nearly agree.I only disagree with the word "formal"
                                      here. I say "agreed to" definition of done
                                
                                The main think I know about scrum is once you get past the basics of 
                                "inspect and adapt" for both your product and process, virtually 
                                everything is malleable. That's on purpose, I think, because the purpose 
                                is to maximize what your organization values, whatever that is.
                                
                                Dan Rawsthorne, PhD, CST
                                Senior Coach, Danube Technologies
                                dan@..., 425-269-8628
                                
                                
                                
                                Peter Stevens (cal) wrote:
                                  
                                 
                                
                                Hi Adam,
                                
                                That's the problem with any self-reporting and lack of branding. What 
                                the asker of a question means with the question and how the respondent 
                                interprets the question can be two entirely different things.
                                
                                At last year's Agile Business Conference in London, keynote speaker 
                                Rob Thomsett defined Agile as a set of values, not as a set of 
                                practices: Openness, Trust, Honesty, Courage and Fiscal 
                                Responsibility. So projects using everything from Scrum to XP to DSDM 
                                to RUP could claim to be Agile.
                                
                                I conducted a poll last summer asking the 8 questions of the Nokia 
                                test. "Is anybody really doing Scrum 
                                <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?" 
                                3/4th of the respondents scored 7 or less. Because of the tool used to 
                                collect the data, I couldn't tell how many satisfied Nokia's 
                                definition of Agile (First 3 questions). The number of respondents was 
                                also rather small -- 47 -- so one might question how representative 
                                this poll was. Since then, Robin Dymond has been started a project to 
                                get 1000 respondents to answer an extended version of the test. Last I 
                                heard, he had 360 respondents, so he hasn't published any results yet.
                                
                                The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO 
                                of tilllate.com, described his company's getting started with Scrum. 
                                When he started, he didn't believe that Scrum would work in his 
                                company, so he changed it. Pretty dramatically. For instance, time 
                                boxes yes, fixed length iterations no. At the beginning of his talk, I 
                                wondered if we could even call his process Scrum. He definitely broke 
                                a lot of rules of Scrum. But he stayed true to inspect and adapt. That 
                                process brought him closer to Scrum by the book (adding 
                                retrospectives, daily scrums, ready to try again with fixed length 
                                iterations, etc).
                                
                                The talk was a real eye opener. If your top management gets the 
                                principles of Scrum, the practices are less of an issue. If they 
                                don't, well, it can be tough.
                                
                                Scrum doesn't actually specify any engineering practices. It specifies 
                                three constraints:
                                
                                    * work committed at the beginning of a sprint must have value to
                                      the customer or user
                                    * work committed at the beginning of a sprint must be finished at
                                      the end of the sprint.
                                    * the team must complete the work according to a formal definition
                                      of done
                                
                                These constraints drive most teams to move towards XP engineering 
                                practices (even though there is no requirement to do so).  I am not 
                                aware of any evidence which shows that doing agile engineering leads 
                                companies to adopt agile management practices, so Scrum is the place 
                                to start.
                                
                                So, coming back to your original post, I think you've got the numbers 
                                and messages you need:
                                
                                   1. > 50% of all IT projects are doing (or trying to do) agile.
                                   2. 84% of them do (or are trying to do) Scrum -- and this is the
                                      place to start.
                                   3. Scrum is hard, so management buy in and commitment are essential.
                                
                                Now it's time for management to self organize: "How do you convince 
                                yourselves the Scrum and Agile are worthy of serious commitment? How 
                                do you learn to walk the walk?"
                                
                                Cheers,
                                
                                Peter
                                
                                
                                
                                Adam Sroka wrote:
                                    
                                Ken's numbers match my experience, but I wonder how many of those 84%
                                are doing some kind of Scrum-but with absolutely none of the Agile
                                "engineering practices." And, of those who claim to be doing some form
                                of Agile that isn't Scrum, I wonder how many are actually doing
                                anything that would remotely resemble Agile to you or I.
                                
                                Also, as an aside, I've noticed that nearly every job description now
                                says "Experience with agile methodologies - especially Scrum or XP -
                                is desirable," or something quite similar. It makes using the job
                                boards more difficult, because nine out of ten of the results for
                                "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                  
                                      
                                    
                                
                                ------------------------------------
                                
                                To Post a message, send it to:   scrumdevelopment@...
                                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                
                                <*> To visit your group on the web, go to:
                                    http://groups.yahoo.com/group/scrumdevelopment/
                                
                                <*> Your email settings:
                                    Individual Email | Traditional
                                
                                <*> To change settings online go to:
                                    http://groups.yahoo.com/group/scrumdevelopment/join
                                    (Yahoo! ID required)
                                
                                <*> To change settings via email:
                                    mailto:scrumdevelopment-digest@yahoogroups.com 
                                    mailto:scrumdevelopment-fullfeatured@yahoogroups.com
                                
                                <*> 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/
                                
                                  

                              • jmilunsky
                                Yeah, point taken. I wasn t reading it like that :-) Jack www.agilebuddy.com blog.agilebuddy.com twitter.com/agilebuddy
                                Message 15 of 22 , Jul 31, 2009
                                • 0 Attachment
                                  Yeah, point taken. I wasn't reading it like that :-)

                                  Jack
                                  www.agilebuddy.com
                                  blog.agilebuddy.com
                                  twitter.com/agilebuddy
                                • Dan Rawsthorne
                                  * value to the user or customer - what exactly should the product owner prioritize which doesn t have value to the customer or user? Lots of things, including
                                  Message 16 of 22 , Jul 31, 2009
                                  • 0 Attachment
                                    * value to the user or customer -> what exactly should the product owner
                                    prioritize which doesn't have value to the customer or user? Lots of
                                    things, including things that have value to the business, the
                                    organization, the team, the product...

                                    Dan Rawsthorne, PhD, CST
                                    Senior Coach, Danube Technologies
                                    dan@..., 425-269-8628



                                    Peter Stevens (cal) wrote:
                                    >
                                    >
                                    > Hi Dan,
                                    >
                                    > I agree with your summary, but am puzzled by your disagreement on the
                                    > constraints.
                                    >
                                    > * value to the user or customer -> what exactly should the product
                                    > owner prioritize which doesn't have value to the customer or user?
                                    >
                                    > * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                    > stong. The team commits to do its best to meet the sprint goal and
                                    > backlog commitments. Timebox and Quality (Definition of Done) are more
                                    > important than Scope.
                                    >
                                    > * definition of done. I agree that the definition is agreed betweeen
                                    > P-O and Team (or perhaps even part of a departmental or company-wide
                                    > standard, but that is advanced magic ;-) ), but what is the problem of
                                    > the word 'formal'? You have X points, and the team commits to
                                    > satisfying all X points before presenting the result to the P-O.
                                    >
                                    > I have seen some variation of how the definition of done is taught.
                                    > Most CST's that I have seen thought of the definition of done as a
                                    > collection of quality checks, e.g. we have checked in the SW, done a
                                    > code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                    > of attending his CSM course in Zürich last month) presented a template
                                    > defining all the tasks needed to complete a product backlog item. His
                                    > goal was to prevent 'undone' work:
                                    >
                                    > Developer: It's done.
                                    > P-O: OK, so we can release it.
                                    > Dev: Uh, no.
                                    > P-O: Why not?
                                    > Dev: Because we have to...
                                    >
                                    > Anything after the ellipses was undone work. As teams mature, the
                                    > amount of undone work after a sprint should approach zero. So you get
                                    > a rather long template for assuring that all PBI's are completed to
                                    > satisfaction.
                                    >
                                    > Cheers,
                                    >
                                    > Peter
                                    >
                                    >
                                    > Dan Rawsthorne wrote:
                                    >
                                    >> I love what you wrote, especially about the principles and values of
                                    >> scrum, but I disagree with all of your constraints :)
                                    >>
                                    >> * work committed at the beginning of a sprint must have value to the
                                    >> customer or user - I disagree. There are many sorts of value.
                                    >> Scrum is silent on which ones to use. All you know is that the PO
                                    >> prioritized it
                                    >>
                                    >> * work committed at the beginning of a sprint must be finished at
                                    >> the end of the sprint. - I disagree. There is a commitment. It is
                                    >> unclear what that commitment means. If there is pressure to finish
                                    >> nomatter what, technical debt and unsustainable pace naturally
                                    >> follow. So, again, what do you value?
                                    >>
                                    >> * the team must complete the work according to a formal definition
                                    >> of done - I nearly agree.I only disagree with the word "formal"
                                    >> here. I say "agreed to" definition of done
                                    >>
                                    >> The main think I know about scrum is once you get past the basics of
                                    >> "inspect and adapt" for both your product and process, virtually
                                    >> everything is malleable. That's on purpose, I think, because the purpose
                                    >> is to maximize what your organization values, whatever that is.
                                    >>
                                    >> Dan Rawsthorne, PhD, CST
                                    >> Senior Coach, Danube Technologies
                                    >> dan@..., 425-269-8628
                                    >>
                                    >>
                                    >>
                                    >> Peter Stevens (cal) wrote:
                                    >>
                                    >>>
                                    >>>
                                    >>> Hi Adam,
                                    >>>
                                    >>> That's the problem with any self-reporting and lack of branding. What
                                    >>> the asker of a question means with the question and how the respondent
                                    >>> interprets the question can be two entirely different things.
                                    >>>
                                    >>> At last year's Agile Business Conference in London, keynote speaker
                                    >>> Rob Thomsett defined Agile as a set of values, not as a set of
                                    >>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                    >>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                    >>> to RUP could claim to be Agile.
                                    >>>
                                    >>> I conducted a poll last summer asking the 8 questions of the Nokia
                                    >>> test. "Is anybody really doing Scrum
                                    >>> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?"
                                    >>> 3/4th of the respondents scored 7 or less. Because of the tool used to
                                    >>> collect the data, I couldn't tell how many satisfied Nokia's
                                    >>> definition of Agile (First 3 questions). The number of respondents was
                                    >>> also rather small -- 47 -- so one might question how representative
                                    >>> this poll was. Since then, Robin Dymond has been started a project to
                                    >>> get 1000 respondents to answer an extended version of the test. Last I
                                    >>> heard, he had 360 respondents, so he hasn't published any results yet.
                                    >>>
                                    >>> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
                                    >>> of tilllate.com, described his company's getting started with Scrum.
                                    >>> When he started, he didn't believe that Scrum would work in his
                                    >>> company, so he changed it. Pretty dramatically. For instance, time
                                    >>> boxes yes, fixed length iterations no. At the beginning of his talk, I
                                    >>> wondered if we could even call his process Scrum. He definitely broke
                                    >>> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                                    >>> process brought him closer to Scrum by the book (adding
                                    >>> retrospectives, daily scrums, ready to try again with fixed length
                                    >>> iterations, etc).
                                    >>>
                                    >>> The talk was a real eye opener. If your top management gets the
                                    >>> principles of Scrum, the practices are less of an issue. If they
                                    >>> don't, well, it can be tough.
                                    >>>
                                    >>> Scrum doesn't actually specify any engineering practices. It specifies
                                    >>> three constraints:
                                    >>>
                                    >>> * work committed at the beginning of a sprint must have value to
                                    >>> the customer or user
                                    >>> * work committed at the beginning of a sprint must be finished at
                                    >>> the end of the sprint.
                                    >>> * the team must complete the work according to a formal definition
                                    >>> of done
                                    >>>
                                    >>> These constraints drive most teams to move towards XP engineering
                                    >>> practices (even though there is no requirement to do so). I am not
                                    >>> aware of any evidence which shows that doing agile engineering leads
                                    >>> companies to adopt agile management practices, so Scrum is the place
                                    >>> to start.
                                    >>>
                                    >>> So, coming back to your original post, I think you've got the numbers
                                    >>> and messages you need:
                                    >>>
                                    >>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                    >>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                    >>> place to start.
                                    >>> 3. Scrum is hard, so management buy in and commitment are essential.
                                    >>>
                                    >>> Now it's time for management to self organize: "How do you convince
                                    >>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                    >>> do you learn to walk the walk?"
                                    >>>
                                    >>> Cheers,
                                    >>>
                                    >>> Peter
                                    >>>
                                    >>>
                                    >>>
                                    >>> Adam Sroka wrote:
                                    >>>
                                    >>>> Ken's numbers match my experience, but I wonder how many of those 84%
                                    >>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                    >>>> "engineering practices." And, of those who claim to be doing some form
                                    >>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                    >>>> anything that would remotely resemble Agile to you or I.
                                    >>>>
                                    >>>> Also, as an aside, I've noticed that nearly every job description now
                                    >>>> says "Experience with agile methodologies - especially Scrum or XP -
                                    >>>> is desirable," or something quite similar. It makes using the job
                                    >>>> boards more difficult, because nine out of ten of the results for
                                    >>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                    >>>>
                                    >>>>
                                    >>>
                                    >>
                                    >>
                                    >> ------------------------------------
                                    >>
                                    >> To Post a message, send it to: scrumdevelopment@...
                                    >> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                    >>
                                    >>
                                    >>
                                    >>
                                    >
                                    >
                                  • Michael James
                                    I find Dan technically correct in the hairsplitting contest, but I sympathize more with Peter -- especially on the need to prioritize with a customer-centric
                                    Message 17 of 22 , Jul 31, 2009
                                    • 0 Attachment
                                      I find Dan technically correct in the hairsplitting contest, but I
                                      sympathize more with Peter -- especially on the need to prioritize
                                      with a customer-centric focus instead of appeasing all the internal
                                      organizational crud that builds up as companies scale.

                                      If we're brought in to transform organizations, what's the point of
                                      emphasizing loopholes that encourage them to keep doing what they've
                                      been doing?

                                      --mj


                                      On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...> wrote:
                                      > * value to the user or customer -> what exactly should the product owner
                                      > prioritize which doesn't have value to the customer or user? Lots of
                                      > things, including things that have value to the business, the
                                      > organization, the team, the product...
                                      >
                                      > Dan Rawsthorne, PhD, CST
                                      > Senior Coach, Danube Technologies
                                      > dan@..., 425-269-8628
                                      >
                                      >
                                      >
                                      > Peter Stevens (cal) wrote:
                                      >>
                                      >>
                                      >> Hi Dan,
                                      >>
                                      >> I agree with your summary, but am puzzled by your disagreement on the
                                      >> constraints.
                                      >>
                                      >> * value to the user or customer -> what exactly should the product
                                      >> owner prioritize which doesn't have value to the customer or user?
                                      >>
                                      >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                      >> stong. The team commits to do its best to meet the sprint goal and
                                      >> backlog commitments. Timebox and Quality (Definition of Done) are more
                                      >> important than Scope.
                                      >>
                                      >> * definition of done. I agree that the definition is agreed betweeen
                                      >> P-O and Team (or perhaps even part of a departmental or company-wide
                                      >> standard, but that is advanced magic ;-) ), but what is the problem of
                                      >> the word 'formal'? You have X points, and the team commits to
                                      >> satisfying all X points before presenting the result to the P-O.
                                      >>
                                      >> I have seen some variation of how the definition of done is taught.
                                      >> Most CST's that I have seen thought of the definition of done as a
                                      >> collection of quality checks, e.g. we have checked in the SW, done a
                                      >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                      >> of attending his CSM course in Zürich last month) presented a template
                                      >> defining all the tasks needed to complete a product backlog item. His
                                      >> goal was to prevent 'undone' work:
                                      >>
                                      >> Developer: It's done.
                                      >> P-O: OK, so we can release it.
                                      >> Dev: Uh, no.
                                      >> P-O: Why not?
                                      >> Dev: Because we have to...
                                      >>
                                      >> Anything after the ellipses was undone work. As teams mature, the
                                      >> amount of undone work after a sprint should approach zero. So you get
                                      >> a rather long template for assuring that all PBI's are completed to
                                      >> satisfaction.
                                      >>
                                      >> Cheers,
                                      >>
                                      >> Peter
                                      >>
                                      >>
                                      >> Dan Rawsthorne wrote:
                                      >>
                                      >>> I love what you wrote, especially about the principles and values of
                                      >>> scrum, but I disagree with all of your constraints :)
                                      >>>
                                      >>> * work committed at the beginning of a sprint must have value to the
                                      >>> customer or user - I disagree. There are many sorts of value.
                                      >>> Scrum is silent on which ones to use. All you know is that the PO
                                      >>> prioritized it
                                      >>>
                                      >>> * work committed at the beginning of a sprint must be finished at
                                      >>> the end of the sprint. - I disagree. There is a commitment. It is
                                      >>> unclear what that commitment means. If there is pressure to finish
                                      >>> nomatter what, technical debt and unsustainable pace naturally
                                      >>> follow. So, again, what do you value?
                                      >>>
                                      >>> * the team must complete the work according to a formal definition
                                      >>> of done - I nearly agree.I only disagree with the word "formal"
                                      >>> here. I say "agreed to" definition of done
                                      >>>
                                      >>> The main think I know about scrum is once you get past the basics of
                                      >>> "inspect and adapt" for both your product and process, virtually
                                      >>> everything is malleable. That's on purpose, I think, because the purpose
                                      >>> is to maximize what your organization values, whatever that is.
                                      >>>
                                      >>> Dan Rawsthorne, PhD, CST
                                      >>> Senior Coach, Danube Technologies
                                      >>> dan@..., 425-269-8628
                                      >>>
                                      >>>
                                      >>>
                                      >>> Peter Stevens (cal) wrote:
                                      >>>
                                      >>>>
                                      >>>>
                                      >>>> Hi Adam,
                                      >>>>
                                      >>>> That's the problem with any self-reporting and lack of branding. What
                                      >>>> the asker of a question means with the question and how the respondent
                                      >>>> interprets the question can be two entirely different things.
                                      >>>>
                                      >>>> At last year's Agile Business Conference in London, keynote speaker
                                      >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                      >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                      >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                      >>>> to RUP could claim to be Agile.
                                      >>>>
                                      >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                      >>>> test. "Is anybody really doing Scrum
                                      >>>> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>?"
                                      >>>>
                                      >>>> 3/4th of the respondents scored 7 or less. Because of the tool used to
                                      >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                      >>>> definition of Agile (First 3 questions). The number of respondents was
                                      >>>> also rather small -- 47 -- so one might question how representative
                                      >>>> this poll was. Since then, Robin Dymond has been started a project to
                                      >>>> get 1000 respondents to answer an extended version of the test. Last I
                                      >>>> heard, he had 360 respondents, so he hasn't published any results yet.
                                      >>>>
                                      >>>> The speaker at last month's the Scrum Breakfast, Silvan Mühlemann, CTO
                                      >>>> of tilllate.com, described his company's getting started with Scrum.
                                      >>>> When he started, he didn't believe that Scrum would work in his
                                      >>>> company, so he changed it. Pretty dramatically. For instance, time
                                      >>>> boxes yes, fixed length iterations no. At the beginning of his talk, I
                                      >>>> wondered if we could even call his process Scrum. He definitely broke
                                      >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt. That
                                      >>>> process brought him closer to Scrum by the book (adding
                                      >>>> retrospectives, daily scrums, ready to try again with fixed length
                                      >>>> iterations, etc).
                                      >>>>
                                      >>>> The talk was a real eye opener. If your top management gets the
                                      >>>> principles of Scrum, the practices are less of an issue. If they
                                      >>>> don't, well, it can be tough.
                                      >>>>
                                      >>>> Scrum doesn't actually specify any engineering practices. It specifies
                                      >>>> three constraints:
                                      >>>>
                                      >>>> * work committed at the beginning of a sprint must have value to
                                      >>>> the customer or user
                                      >>>> * work committed at the beginning of a sprint must be finished at
                                      >>>> the end of the sprint.
                                      >>>> * the team must complete the work according to a formal definition
                                      >>>> of done
                                      >>>>
                                      >>>> These constraints drive most teams to move towards XP engineering
                                      >>>> practices (even though there is no requirement to do so). I am not
                                      >>>> aware of any evidence which shows that doing agile engineering leads
                                      >>>> companies to adopt agile management practices, so Scrum is the place
                                      >>>> to start.
                                      >>>>
                                      >>>> So, coming back to your original post, I think you've got the numbers
                                      >>>> and messages you need:
                                      >>>>
                                      >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                      >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                      >>>> place to start.
                                      >>>> 3. Scrum is hard, so management buy in and commitment are essential.
                                      >>>>
                                      >>>> Now it's time for management to self organize: "How do you convince
                                      >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                      >>>> do you learn to walk the walk?"
                                      >>>>
                                      >>>> Cheers,
                                      >>>>
                                      >>>> Peter
                                      >>>>
                                      >>>>
                                      >>>>
                                      >>>> Adam Sroka wrote:
                                      >>>>
                                      >>>>> Ken's numbers match my experience, but I wonder how many of those 84%
                                      >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                      >>>>> "engineering practices." And, of those who claim to be doing some form
                                      >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                      >>>>> anything that would remotely resemble Agile to you or I.
                                      >>>>>
                                      >>>>> Also, as an aside, I've noticed that nearly every job description now
                                      >>>>> says "Experience with agile methodologies - especially Scrum or XP -
                                      >>>>> is desirable," or something quite similar. It makes using the job
                                      >>>>> boards more difficult, because nine out of ten of the results for
                                      >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                      >>>>>
                                      >>>>>
                                      >>>>
                                      >>>
                                      >>>
                                      >>> ------------------------------------
                                      >>>
                                      >>> To Post a message, send it to: scrumdevelopment@...
                                      >>> To Unsubscribe, send a blank message to:
                                      >>> scrumdevelopment-unsubscribe@...! Groups Links
                                      >>>
                                      >>>
                                      >>>
                                      >>>
                                      >>
                                      >>
                                      >
                                      >
                                      > ------------------------------------
                                      >
                                      > To Post a message, send it to: scrumdevelopment@...
                                      > To Unsubscribe, send a blank message to:
                                      > scrumdevelopment-unsubscribe@...! Groups Links
                                      >
                                      >
                                      >
                                      >

                                      --
                                      Sent from my mobile device
                                    • Dan Rawsthorne
                                      Ah, MJ, I agree with you. But I think that hairsplitting is important on this group, because if we don t know exactly what we re talking about here, how can we
                                      Message 18 of 22 , Jul 31, 2009
                                      • 0 Attachment
                                        Ah, MJ, I agree with you. But I think that hairsplitting is important on
                                        this group, because if we don't know exactly what we're talking about
                                        here, how can we expect to explain it to others? The fact that I do
                                        split hairs has allowed me to have conversations like "yes, you're doing
                                        something like scrum, but you're not really Agile", and "yes, you're
                                        using C++, but you're not object oriented." I think that bad behavior
                                        hides in the mushiness, if we allow it.

                                        And, MJ, of course you should prioritize with a customer-centric focus.
                                        But that does not mean that you prioritize only things that have
                                        customer value. I know, more hair-splitting... but I've seen and heard
                                        of a lot of teams that have a hard time justifying something that
                                        obviously needs to be done (like rearranging the team room) because it
                                        doesn't have "customer value." The good news is that it's the SM's job
                                        to question all this and ask "why is this valuable again?" and "don't we
                                        need to do this?" when working with the PO. It's all about the
                                        conversations, remember... there really aren't that many rules.

                                        Dan Rawsthorne, PhD, CST
                                        Senior Coach, Danube Technologies
                                        dan@..., 425-269-8628



                                        Michael James wrote:
                                        >
                                        >
                                        > I find Dan technically correct in the hairsplitting contest, but I
                                        > sympathize more with Peter -- especially on the need to prioritize
                                        > with a customer-centric focus instead of appeasing all the internal
                                        > organizational crud that builds up as companies scale.
                                        >
                                        > If we're brought in to transform organizations, what's the point of
                                        > emphasizing loopholes that encourage them to keep doing what they've
                                        > been doing?
                                        >
                                        > --mj
                                        >
                                        > On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
                                        > <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
                                        > > * value to the user or customer -> what exactly should the product owner
                                        > > prioritize which doesn't have value to the customer or user? Lots of
                                        > > things, including things that have value to the business, the
                                        > > organization, the team, the product...
                                        > >
                                        > > Dan Rawsthorne, PhD, CST
                                        > > Senior Coach, Danube Technologies
                                        > > dan@... <mailto:dan%40danube.com>, 425-269-8628
                                        > >
                                        > >
                                        > >
                                        > > Peter Stevens (cal) wrote:
                                        > >>
                                        > >>
                                        > >> Hi Dan,
                                        > >>
                                        > >> I agree with your summary, but am puzzled by your disagreement on the
                                        > >> constraints.
                                        > >>
                                        > >> * value to the user or customer -> what exactly should the product
                                        > >> owner prioritize which doesn't have value to the customer or user?
                                        > >>
                                        > >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                        > >> stong. The team commits to do its best to meet the sprint goal and
                                        > >> backlog commitments. Timebox and Quality (Definition of Done) are more
                                        > >> important than Scope.
                                        > >>
                                        > >> * definition of done. I agree that the definition is agreed betweeen
                                        > >> P-O and Team (or perhaps even part of a departmental or company-wide
                                        > >> standard, but that is advanced magic ;-) ), but what is the problem of
                                        > >> the word 'formal'? You have X points, and the team commits to
                                        > >> satisfying all X points before presenting the result to the P-O.
                                        > >>
                                        > >> I have seen some variation of how the definition of done is taught.
                                        > >> Most CST's that I have seen thought of the definition of done as a
                                        > >> collection of quality checks, e.g. we have checked in the SW, done a
                                        > >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                        > >> of attending his CSM course in Zürich last month) presented a template
                                        > >> defining all the tasks needed to complete a product backlog item. His
                                        > >> goal was to prevent 'undone' work:
                                        > >>
                                        > >> Developer: It's done.
                                        > >> P-O: OK, so we can release it.
                                        > >> Dev: Uh, no.
                                        > >> P-O: Why not?
                                        > >> Dev: Because we have to...
                                        > >>
                                        > >> Anything after the ellipses was undone work. As teams mature, the
                                        > >> amount of undone work after a sprint should approach zero. So you get
                                        > >> a rather long template for assuring that all PBI's are completed to
                                        > >> satisfaction.
                                        > >>
                                        > >> Cheers,
                                        > >>
                                        > >> Peter
                                        > >>
                                        > >>
                                        > >> Dan Rawsthorne wrote:
                                        > >>
                                        > >>> I love what you wrote, especially about the principles and values of
                                        > >>> scrum, but I disagree with all of your constraints :)
                                        > >>>
                                        > >>> * work committed at the beginning of a sprint must have value to the
                                        > >>> customer or user - I disagree. There are many sorts of value.
                                        > >>> Scrum is silent on which ones to use. All you know is that the PO
                                        > >>> prioritized it
                                        > >>>
                                        > >>> * work committed at the beginning of a sprint must be finished at
                                        > >>> the end of the sprint. - I disagree. There is a commitment. It is
                                        > >>> unclear what that commitment means. If there is pressure to finish
                                        > >>> nomatter what, technical debt and unsustainable pace naturally
                                        > >>> follow. So, again, what do you value?
                                        > >>>
                                        > >>> * the team must complete the work according to a formal definition
                                        > >>> of done - I nearly agree.I only disagree with the word "formal"
                                        > >>> here. I say "agreed to" definition of done
                                        > >>>
                                        > >>> The main think I know about scrum is once you get past the basics of
                                        > >>> "inspect and adapt" for both your product and process, virtually
                                        > >>> everything is malleable. That's on purpose, I think, because the
                                        > purpose
                                        > >>> is to maximize what your organization values, whatever that is.
                                        > >>>
                                        > >>> Dan Rawsthorne, PhD, CST
                                        > >>> Senior Coach, Danube Technologies
                                        > >>> dan@... <mailto:dan%40danube.com>, 425-269-8628
                                        > >>>
                                        > >>>
                                        > >>>
                                        > >>> Peter Stevens (cal) wrote:
                                        > >>>
                                        > >>>>
                                        > >>>>
                                        > >>>> Hi Adam,
                                        > >>>>
                                        > >>>> That's the problem with any self-reporting and lack of branding. What
                                        > >>>> the asker of a question means with the question and how the
                                        > respondent
                                        > >>>> interprets the question can be two entirely different things.
                                        > >>>>
                                        > >>>> At last year's Agile Business Conference in London, keynote speaker
                                        > >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                        > >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                        > >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                        > >>>> to RUP could claim to be Agile.
                                        > >>>>
                                        > >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                        > >>>> test. "Is anybody really doing Scrum
                                        > >>>>
                                        > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                                        > <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>?"
                                        > >>>>
                                        > >>>> 3/4th of the respondents scored 7 or less. Because of the tool
                                        > used to
                                        > >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                        > >>>> definition of Agile (First 3 questions). The number of
                                        > respondents was
                                        > >>>> also rather small -- 47 -- so one might question how representative
                                        > >>>> this poll was. Since then, Robin Dymond has been started a project to
                                        > >>>> get 1000 respondents to answer an extended version of the test.
                                        > Last I
                                        > >>>> heard, he had 360 respondents, so he hasn't published any results
                                        > yet.
                                        > >>>>
                                        > >>>> The speaker at last month's the Scrum Breakfast, Silvan
                                        > Mühlemann, CTO
                                        > >>>> of tilllate.com, described his company's getting started with Scrum.
                                        > >>>> When he started, he didn't believe that Scrum would work in his
                                        > >>>> company, so he changed it. Pretty dramatically. For instance, time
                                        > >>>> boxes yes, fixed length iterations no. At the beginning of his
                                        > talk, I
                                        > >>>> wondered if we could even call his process Scrum. He definitely broke
                                        > >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                                        > That
                                        > >>>> process brought him closer to Scrum by the book (adding
                                        > >>>> retrospectives, daily scrums, ready to try again with fixed length
                                        > >>>> iterations, etc).
                                        > >>>>
                                        > >>>> The talk was a real eye opener. If your top management gets the
                                        > >>>> principles of Scrum, the practices are less of an issue. If they
                                        > >>>> don't, well, it can be tough.
                                        > >>>>
                                        > >>>> Scrum doesn't actually specify any engineering practices. It
                                        > specifies
                                        > >>>> three constraints:
                                        > >>>>
                                        > >>>> * work committed at the beginning of a sprint must have value to
                                        > >>>> the customer or user
                                        > >>>> * work committed at the beginning of a sprint must be finished at
                                        > >>>> the end of the sprint.
                                        > >>>> * the team must complete the work according to a formal definition
                                        > >>>> of done
                                        > >>>>
                                        > >>>> These constraints drive most teams to move towards XP engineering
                                        > >>>> practices (even though there is no requirement to do so). I am not
                                        > >>>> aware of any evidence which shows that doing agile engineering leads
                                        > >>>> companies to adopt agile management practices, so Scrum is the place
                                        > >>>> to start.
                                        > >>>>
                                        > >>>> So, coming back to your original post, I think you've got the numbers
                                        > >>>> and messages you need:
                                        > >>>>
                                        > >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                        > >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                        > >>>> place to start.
                                        > >>>> 3. Scrum is hard, so management buy in and commitment are essential.
                                        > >>>>
                                        > >>>> Now it's time for management to self organize: "How do you convince
                                        > >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                        > >>>> do you learn to walk the walk?"
                                        > >>>>
                                        > >>>> Cheers,
                                        > >>>>
                                        > >>>> Peter
                                        > >>>>
                                        > >>>>
                                        > >>>>
                                        > >>>> Adam Sroka wrote:
                                        > >>>>
                                        > >>>>> Ken's numbers match my experience, but I wonder how many of
                                        > those 84%
                                        > >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                        > >>>>> "engineering practices." And, of those who claim to be doing
                                        > some form
                                        > >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                        > >>>>> anything that would remotely resemble Agile to you or I.
                                        > >>>>>
                                        > >>>>> Also, as an aside, I've noticed that nearly every job
                                        > description now
                                        > >>>>> says "Experience with agile methodologies - especially Scrum or XP -
                                        > >>>>> is desirable," or something quite similar. It makes using the job
                                        > >>>>> boards more difficult, because nine out of ten of the results for
                                        > >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                        > >>>>>
                                        > >>>>>
                                        > >>>>
                                        > >>>
                                        > >>>
                                        > >>> ------------------------------------
                                        > >>>
                                        > >>> To Post a message, send it to: scrumdevelopment@...
                                        > <mailto:scrumdevelopment%40eGroups.com>
                                        > >>> To Unsubscribe, send a blank message to:
                                        > >>> scrumdevelopment-unsubscribe@...
                                        > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                        > >>>
                                        > >>>
                                        > >>>
                                        > >>>
                                        > >>
                                        > >>
                                        > >
                                        > >
                                        > > ------------------------------------
                                        > >
                                        > > To Post a message, send it to: scrumdevelopment@...
                                        > <mailto:scrumdevelopment%40eGroups.com>
                                        > > To Unsubscribe, send a blank message to:
                                        > > scrumdevelopment-unsubscribe@...
                                        > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                        > >
                                        > >
                                        > >
                                        > >
                                        >
                                        > --
                                        > Sent from my mobile device
                                        >
                                        >
                                      • Peter Stevens (cal)
                                        Hi Dan, Obviously hairsplitting can be the basis of a lively thread ... ;-) My experience with hair splitters in a live context is that they often end up
                                        Message 19 of 22 , Aug 1, 2009
                                        • 0 Attachment
                                          Hi Dan,

                                          Obviously hairsplitting can be the basis of a lively thread ... ;-)

                                          My experience with hair splitters in a live context is that they often end up playing a game of "My Scrum is better than your Scrum." The players argue about whether some practice is true Scrum or not. This frustrates all involved parties and leads them away from the values and principles of Scrum. So like a sharp knife, hair splitting is a tool to be used carefully, at the risk of cutting off your own finger.

                                          Cheers,

                                          Peter

                                          Dan Rawsthorne wrote:
                                           

                                          Ah, MJ, I agree with you. But I think that hairsplitting is important on
                                          this group, because if we don't know exactly what we're talking about
                                          here, how can we expect to explain it to others? The fact that I do
                                          split hairs has allowed me to have conversations like "yes, you're doing
                                          something like scrum, but you're not really Agile", and "yes, you're
                                          using C++, but you're not object oriented." I think that bad behavior
                                          hides in the mushiness, if we allow it.

                                          And, MJ, of course you should prioritize with a customer-centric focus.
                                          But that does not mean that you prioritize only things that have
                                          customer value. I know, more hair-splitting. .. but I've seen and heard
                                          of a lot of teams that have a hard time justifying something that
                                          obviously needs to be done (like rearranging the team room) because it
                                          doesn't have "customer value." The good news is that it's the SM's job
                                          to question all this and ask "why is this valuable again?" and "don't we
                                          need to do this?" when working with the PO. It's all about the
                                          conversations, remember... there really aren't that many rules.

                                          Dan Rawsthorne, PhD, CST
                                          Senior Coach, Danube Technologies
                                          dan@..., 425-269-8628

                                          Michael James wrote:
                                          >
                                          >
                                          > I find Dan technically correct in the hairsplitting contest, but I
                                          > sympathize more with Peter -- especially on the need to prioritize
                                          > with a customer-centric focus instead of appeasing all the internal
                                          > organizational crud that builds up as companies scale.
                                          >
                                          > If we're brought in to transform organizations, what's the point of
                                          > emphasizing loopholes that encourage them to keep doing what they've
                                          > been doing?
                                          >
                                          > --mj
                                          >
                                          > On 7/31/09, Dan Rawsthorne <dan.rawsthorne@ drdansplace. com
                                          > <mailto:dan. rawsthorne% 40drdansplace. com>> wrote:
                                          > > * value to the user or customer -> what exactly should the product owner
                                          > > prioritize which doesn't have value to the customer or user? Lots of
                                          > > things, including things that have value to the business, the
                                          > > organization, the team, the product...
                                          > >
                                          > > Dan Rawsthorne, PhD, CST
                                          > > Senior Coach, Danube Technologies
                                          > > dan@... <mailto:dan% 40danube. com>, 425-269-8628
                                          > >
                                          > >
                                          > >
                                          > > Peter Stevens (cal) wrote:
                                          > >>
                                          > >>
                                          > >> Hi Dan,
                                          > >>
                                          > >> I agree with your summary, but am puzzled by your disagreement on the
                                          > >> constraints.
                                          > >>
                                          > >> * value to the user or customer -> what exactly should the product
                                          > >> owner prioritize which doesn't have value to the customer or user?
                                          > >>
                                          > >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                          > >> stong. The team commits to do its best to meet the sprint goal and
                                          > >> backlog commitments. Timebox and Quality (Definition of Done) are more
                                          > >> important than Scope.
                                          > >>
                                          > >> * definition of done. I agree that the definition is agreed betweeen
                                          > >> P-O and Team (or perhaps even part of a departmental or company-wide
                                          > >> standard, but that is advanced magic ;-) ), but what is the problem of
                                          > >> the word 'formal'? You have X points, and the team commits to
                                          > >> satisfying all X points before presenting the result to the P-O.
                                          > >>
                                          > >> I have seen some variation of how the definition of done is taught.
                                          > >> Most CST's that I have seen thought of the definition of done as a
                                          > >> collection of quality checks, e.g. we have checked in the SW, done a
                                          > >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                          > >> of attending his CSM course in Zürich last month) presented a template
                                          > >> defining all the tasks needed to complete a product backlog item. His
                                          > >> goal was to prevent 'undone' work:
                                          > >>
                                          > >> Developer: It's done.
                                          > >> P-O: OK, so we can release it.
                                          > >> Dev: Uh, no.
                                          > >> P-O: Why not?
                                          > >> Dev: Because we have to...
                                          > >>
                                          > >> Anything after the ellipses was undone work. As teams mature, the
                                          > >> amount of undone work after a sprint should approach zero. So you get
                                          > >> a rather long template for assuring that all PBI's are completed to
                                          > >> satisfaction.
                                          > >>
                                          > >> Cheers,
                                          > >>
                                          > >> Peter
                                          > >>
                                          > >>
                                          > >> Dan Rawsthorne wrote:
                                          > >>
                                          > >>> I love what you wrote, especially about the principles and values of
                                          > >>> scrum, but I disagree with all of your constraints :)
                                          > >>>
                                          > >>> * work committed at the beginning of a sprint must have value to the
                                          > >>> customer or user - I disagree. There are many sorts of value.
                                          > >>> Scrum is silent on which ones to use. All you know is that the PO
                                          > >>> prioritized it
                                          > >>>
                                          > >>> * work committed at the beginning of a sprint must be finished at
                                          > >>> the end of the sprint. - I disagree. There is a commitment. It is
                                          > >>> unclear what that commitment means. If there is pressure to finish
                                          > >>> nomatter what, technical debt and unsustainable pace naturally
                                          > >>> follow. So, again, what do you value?
                                          > >>>
                                          > >>> * the team must complete the work according to a formal definition
                                          > >>> of done - I nearly agree.I only disagree with the word "formal"
                                          > >>> here. I say "agreed to" definition of done
                                          > >>>
                                          > >>> The main think I know about scrum is once you get past the basics of
                                          > >>> "inspect and adapt" for both your product and process, virtually
                                          > >>> everything is malleable. That's on purpose, I think, because the
                                          > purpose
                                          > >>> is to maximize what your organization values, whatever that is.
                                          > >>>
                                          > >>> Dan Rawsthorne, PhD, CST
                                          > >>> Senior Coach, Danube Technologies
                                          > >>> dan@... <mailto:dan% 40danube. com>, 425-269-8628
                                          > >>>
                                          > >>>
                                          > >>>
                                          > >>> Peter Stevens (cal) wrote:
                                          > >>>
                                          > >>>>
                                          > >>>>
                                          > >>>> Hi Adam,
                                          > >>>>
                                          > >>>> That's the problem with any self-reporting and lack of branding. What
                                          > >>>> the asker of a question means with the question and how the
                                          > respondent
                                          > >>>> interprets the question can be two entirely different things.
                                          > >>>>
                                          > >>>> At last year's Agile Business Conference in London, keynote speaker
                                          > >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                          > >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                          > >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                          > >>>> to RUP could claim to be Agile.
                                          > >>>>
                                          > >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                          > >>>> test. "Is anybody really doing Scrum
                                          > >>>>
                                          > <http://www.scrum- breakfast. com/2008/ 06/quick- poll-results- is-any-body- really.html
                                          > <http://www.scrum- breakfast. com/2008/ 06/quick- poll-results- is-any-body- really.html>>?"
                                          > >>>>
                                          > >>>> 3/4th of the respondents scored 7 or less. Because of the tool
                                          > used to
                                          > >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                          > >>>> definition of Agile (First 3 questions). The number of
                                          > respondents was
                                          > >>>> also rather small -- 47 -- so one might question how representative
                                          > >>>> this poll was. Since then, Robin Dymond has been started a project to
                                          > >>>> get 1000 respondents to answer an extended version of the test.
                                          > Last I
                                          > >>>> heard, he had 360 respondents, so he hasn't published any results
                                          > yet.
                                          > >>>>
                                          > >>>> The speaker at last month's the Scrum Breakfast, Silvan
                                          > Mühlemann, CTO
                                          > >>>> of tilllate.com, described his company's getting started with Scrum.
                                          > >>>> When he started, he didn't believe that Scrum would work in his
                                          > >>>> company, so he changed it. Pretty dramatically. For instance, time
                                          > >>>> boxes yes, fixed length iterations no. At the beginning of his
                                          > talk, I
                                          > >>>> wondered if we could even call his process Scrum. He definitely broke
                                          > >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                                          > That
                                          > >>>> process brought him closer to Scrum by the book (adding
                                          > >>>> retrospectives, daily scrums, ready to try again with fixed length
                                          > >>>> iterations, etc).
                                          > >>>>
                                          > >>>> The talk was a real eye opener. If your top management gets the
                                          > >>>> principles of Scrum, the practices are less of an issue. If they
                                          > >>>> don't, well, it can be tough.
                                          > >>>>
                                          > >>>> Scrum doesn't actually specify any engineering practices. It
                                          > specifies
                                          > >>>> three constraints:
                                          > >>>>
                                          > >>>> * work committed at the beginning of a sprint must have value to
                                          > >>>> the customer or user
                                          > >>>> * work committed at the beginning of a sprint must be finished at
                                          > >>>> the end of the sprint.
                                          > >>>> * the team must complete the work according to a formal definition
                                          > >>>> of done
                                          > >>>>
                                          > >>>> These constraints drive most teams to move towards XP engineering
                                          > >>>> practices (even though there is no requirement to do so). I am not
                                          > >>>> aware of any evidence which shows that doing agile engineering leads
                                          > >>>> companies to adopt agile management practices, so Scrum is the place
                                          > >>>> to start.
                                          > >>>>
                                          > >>>> So, coming back to your original post, I think you've got the numbers
                                          > >>>> and messages you need:
                                          > >>>>
                                          > >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                          > >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                          > >>>> place to start.
                                          > >>>> 3. Scrum is hard, so management buy in and commitment are essential.
                                          > >>>>
                                          > >>>> Now it's time for management to self organize: "How do you convince
                                          > >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                          > >>>> do you learn to walk the walk?"
                                          > >>>>
                                          > >>>> Cheers,
                                          > >>>>
                                          > >>>> Peter
                                          > >>>>
                                          > >>>>
                                          > >>>>
                                          > >>>> Adam Sroka wrote:
                                          > >>>>
                                          > >>>>> Ken's numbers match my experience, but I wonder how many of
                                          > those 84%
                                          > >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                          > >>>>> "engineering practices." And, of those who claim to be doing
                                          > some form
                                          > >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                          > >>>>> anything that would remotely resemble Agile to you or I.
                                          > >>>>>
                                          > >>>>> Also, as an aside, I've noticed that nearly every job
                                          > description now
                                          > >>>>> says "Experience with agile methodologies - especially Scrum or XP -
                                          > >>>>> is desirable," or something quite similar. It makes using the job
                                          > >>>>> boards more difficult, because nine out of ten of the results for
                                          > >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                          > >>>>>
                                          > >>>>>
                                          > >>>>
                                          > >>>
                                          > >>>
                                          > >>> ------------ --------- --------- ------
                                          > >>>
                                          > >>> To Post a message, send it to: scrumdevelopment@ eGroups.com
                                          > <mailto:scrumdevelo pment%40eGroups. com>
                                          > >>> To Unsubscribe, send a blank message to:
                                          > >>> scrumdevelopment- unsubscribe@ eGroups.comYahoo
                                          > <mailto:scrumdevelo pment-unsubscrib e%40eGroups. comYahoo> ! Groups Links
                                          > >>>
                                          > >>>
                                          > >>>
                                          > >>>
                                          > >>
                                          > >>
                                          > >
                                          > >
                                          > > ------------ --------- --------- ------
                                          > >
                                          > > To Post a message, send it to: scrumdevelopment@ eGroups.com
                                          > <mailto:scrumdevelo pment%40eGroups. com>
                                          > > To Unsubscribe, send a blank message to:
                                          > > scrumdevelopment- unsubscribe@ eGroups.comYahoo
                                          > <mailto:scrumdevelo pment-unsubscrib e%40eGroups. comYahoo> ! Groups Links
                                          > >
                                          > >
                                          > >
                                          > >
                                          >
                                          > --
                                          > Sent from my mobile device
                                          >
                                          >


                                        • victor oliveira
                                          Dan, I totally agree with you on this one. Hair-splitting is what this list is mostly about, IMHO. And also, on value, ROI has many faces and is really hard to
                                          Message 20 of 22 , Aug 1, 2009
                                          • 0 Attachment
                                            Dan,

                                            I totally agree with you on this one. Hair-splitting is what this
                                            list is mostly about, IMHO.
                                            And also, on value, ROI has many faces and is really hard to
                                            calculate. Reducing ROI to "customer value" or "user value" is to
                                            throw money (and more) away.

                                            Best Regards,
                                            Victor Hugo de Oliveira

                                            Scrum & Agile Blog
                                            http://csvo.wordpress.com

                                            Concrete Solutions
                                            new edition: http://www.concretesolutions.com.br/index_eng/


                                            On Fri, Jul 31, 2009 at 10:45 PM, Dan
                                            Rawsthorne<dan.rawsthorne@...> wrote:
                                            >
                                            >
                                            > Ah, MJ, I agree with you. But I think that hairsplitting is important on
                                            > this group, because if we don't know exactly what we're talking about
                                            > here, how can we expect to explain it to others? The fact that I do
                                            > split hairs has allowed me to have conversations like "yes, you're doing
                                            > something like scrum, but you're not really Agile", and "yes, you're
                                            > using C++, but you're not object oriented." I think that bad behavior
                                            > hides in the mushiness, if we allow it.
                                            >
                                            > And, MJ, of course you should prioritize with a customer-centric focus.
                                            > But that does not mean that you prioritize only things that have
                                            > customer value. I know, more hair-splitting... but I've seen and heard
                                            > of a lot of teams that have a hard time justifying something that
                                            > obviously needs to be done (like rearranging the team room) because it
                                            > doesn't have "customer value." The good news is that it's the SM's job
                                            > to question all this and ask "why is this valuable again?" and "don't we
                                            > need to do this?" when working with the PO. It's all about the
                                            > conversations, remember... there really aren't that many rules.
                                            >
                                            > Dan Rawsthorne, PhD, CST
                                            > Senior Coach, Danube Technologies
                                            > dan@..., 425-269-8628
                                            >
                                            > Michael James wrote:
                                            >>
                                            >>
                                            >> I find Dan technically correct in the hairsplitting contest, but I
                                            >> sympathize more with Peter -- especially on the need to prioritize
                                            >> with a customer-centric focus instead of appeasing all the internal
                                            >> organizational crud that builds up as companies scale.
                                            >>
                                            >> If we're brought in to transform organizations, what's the point of
                                            >> emphasizing loopholes that encourage them to keep doing what they've
                                            >> been doing?
                                            >>
                                            >> --mj
                                            >>
                                            >> On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
                                            >> <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
                                            >> > * value to the user or customer -> what exactly should the product owner
                                            >> > prioritize which doesn't have value to the customer or user? Lots of
                                            >> > things, including things that have value to the business, the
                                            >> > organization, the team, the product...
                                            >> >
                                            >> > Dan Rawsthorne, PhD, CST
                                            >> > Senior Coach, Danube Technologies
                                            >> > dan@... <mailto:dan%40danube.com>, 425-269-8628
                                            >> >
                                            >> >
                                            >> >
                                            >> > Peter Stevens (cal) wrote:
                                            >> >>
                                            >> >>
                                            >> >> Hi Dan,
                                            >> >>
                                            >> >> I agree with your summary, but am puzzled by your disagreement on the
                                            >> >> constraints.
                                            >> >>
                                            >> >> * value to the user or customer -> what exactly should the product
                                            >> >> owner prioritize which doesn't have value to the customer or user?
                                            >> >>
                                            >> >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                            >> >> stong. The team commits to do its best to meet the sprint goal and
                                            >> >> backlog commitments. Timebox and Quality (Definition of Done) are more
                                            >> >> important than Scope.
                                            >> >>
                                            >> >> * definition of done. I agree that the definition is agreed betweeen
                                            >> >> P-O and Team (or perhaps even part of a departmental or company-wide
                                            >> >> standard, but that is advanced magic ;-) ), but what is the problem of
                                            >> >> the word 'formal'? You have X points, and the team commits to
                                            >> >> satisfying all X points before presenting the result to the P-O.
                                            >> >>
                                            >> >> I have seen some variation of how the definition of done is taught.
                                            >> >> Most CST's that I have seen thought of the definition of done as a
                                            >> >> collection of quality checks, e.g. we have checked in the SW, done a
                                            >> >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                            >> >> of attending his CSM course in Zürich last month) presented a template
                                            >> >> defining all the tasks needed to complete a product backlog item. His
                                            >> >> goal was to prevent 'undone' work:
                                            >> >>
                                            >> >> Developer: It's done.
                                            >> >> P-O: OK, so we can release it.
                                            >> >> Dev: Uh, no.
                                            >> >> P-O: Why not?
                                            >> >> Dev: Because we have to...
                                            >> >>
                                            >> >> Anything after the ellipses was undone work. As teams mature, the
                                            >> >> amount of undone work after a sprint should approach zero. So you get
                                            >> >> a rather long template for assuring that all PBI's are completed to
                                            >> >> satisfaction.
                                            >> >>
                                            >> >> Cheers,
                                            >> >>
                                            >> >> Peter
                                            >> >>
                                            >> >>
                                            >> >> Dan Rawsthorne wrote:
                                            >> >>
                                            >> >>> I love what you wrote, especially about the principles and values of
                                            >> >>> scrum, but I disagree with all of your constraints :)
                                            >> >>>
                                            >> >>> * work committed at the beginning of a sprint must have value to the
                                            >> >>> customer or user - I disagree. There are many sorts of value.
                                            >> >>> Scrum is silent on which ones to use. All you know is that the PO
                                            >> >>> prioritized it
                                            >> >>>
                                            >> >>> * work committed at the beginning of a sprint must be finished at
                                            >> >>> the end of the sprint. - I disagree. There is a commitment. It is
                                            >> >>> unclear what that commitment means. If there is pressure to finish
                                            >> >>> nomatter what, technical debt and unsustainable pace naturally
                                            >> >>> follow. So, again, what do you value?
                                            >> >>>
                                            >> >>> * the team must complete the work according to a formal definition
                                            >> >>> of done - I nearly agree.I only disagree with the word "formal"
                                            >> >>> here. I say "agreed to" definition of done
                                            >> >>>
                                            >> >>> The main think I know about scrum is once you get past the basics of
                                            >> >>> "inspect and adapt" for both your product and process, virtually
                                            >> >>> everything is malleable. That's on purpose, I think, because the
                                            >> purpose
                                            >> >>> is to maximize what your organization values, whatever that is.
                                            >> >>>
                                            >> >>> Dan Rawsthorne, PhD, CST
                                            >> >>> Senior Coach, Danube Technologies
                                            >> >>> dan@... <mailto:dan%40danube.com>, 425-269-8628
                                            >> >>>
                                            >> >>>
                                            >> >>>
                                            >> >>> Peter Stevens (cal) wrote:
                                            >> >>>
                                            >> >>>>
                                            >> >>>>
                                            >> >>>> Hi Adam,
                                            >> >>>>
                                            >> >>>> That's the problem with any self-reporting and lack of branding. What
                                            >> >>>> the asker of a question means with the question and how the
                                            >> respondent
                                            >> >>>> interprets the question can be two entirely different things.
                                            >> >>>>
                                            >> >>>> At last year's Agile Business Conference in London, keynote speaker
                                            >> >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                            >> >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                            >> >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                            >> >>>> to RUP could claim to be Agile.
                                            >> >>>>
                                            >> >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                            >> >>>> test. "Is anybody really doing Scrum
                                            >> >>>>
                                            >>
                                            >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                                            >>
                                            >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>?"
                                            >> >>>>
                                            >> >>>> 3/4th of the respondents scored 7 or less. Because of the tool
                                            >> used to
                                            >> >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                            >> >>>> definition of Agile (First 3 questions). The number of
                                            >> respondents was
                                            >> >>>> also rather small -- 47 -- so one might question how representative
                                            >> >>>> this poll was. Since then, Robin Dymond has been started a project to
                                            >> >>>> get 1000 respondents to answer an extended version of the test.
                                            >> Last I
                                            >> >>>> heard, he had 360 respondents, so he hasn't published any results
                                            >> yet.
                                            >> >>>>
                                            >> >>>> The speaker at last month's the Scrum Breakfast, Silvan
                                            >> Mühlemann, CTO
                                            >> >>>> of tilllate.com, described his company's getting started with Scrum.
                                            >> >>>> When he started, he didn't believe that Scrum would work in his
                                            >> >>>> company, so he changed it. Pretty dramatically. For instance, time
                                            >> >>>> boxes yes, fixed length iterations no. At the beginning of his
                                            >> talk, I
                                            >> >>>> wondered if we could even call his process Scrum. He definitely broke
                                            >> >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                                            >> That
                                            >> >>>> process brought him closer to Scrum by the book (adding
                                            >> >>>> retrospectives, daily scrums, ready to try again with fixed length
                                            >> >>>> iterations, etc).
                                            >> >>>>
                                            >> >>>> The talk was a real eye opener. If your top management gets the
                                            >> >>>> principles of Scrum, the practices are less of an issue. If they
                                            >> >>>> don't, well, it can be tough.
                                            >> >>>>
                                            >> >>>> Scrum doesn't actually specify any engineering practices. It
                                            >> specifies
                                            >> >>>> three constraints:
                                            >> >>>>
                                            >> >>>> * work committed at the beginning of a sprint must have value to
                                            >> >>>> the customer or user
                                            >> >>>> * work committed at the beginning of a sprint must be finished at
                                            >> >>>> the end of the sprint.
                                            >> >>>> * the team must complete the work according to a formal definition
                                            >> >>>> of done
                                            >> >>>>
                                            >> >>>> These constraints drive most teams to move towards XP engineering
                                            >> >>>> practices (even though there is no requirement to do so). I am not
                                            >> >>>> aware of any evidence which shows that doing agile engineering leads
                                            >> >>>> companies to adopt agile management practices, so Scrum is the place
                                            >> >>>> to start.
                                            >> >>>>
                                            >> >>>> So, coming back to your original post, I think you've got the numbers
                                            >> >>>> and messages you need:
                                            >> >>>>
                                            >> >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                            >> >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                            >> >>>> place to start.
                                            >> >>>> 3. Scrum is hard, so management buy in and commitment are essential.
                                            >> >>>>
                                            >> >>>> Now it's time for management to self organize: "How do you convince
                                            >> >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                            >> >>>> do you learn to walk the walk?"
                                            >> >>>>
                                            >> >>>> Cheers,
                                            >> >>>>
                                            >> >>>> Peter
                                            >> >>>>
                                            >> >>>>
                                            >> >>>>
                                            >> >>>> Adam Sroka wrote:
                                            >> >>>>
                                            >> >>>>> Ken's numbers match my experience, but I wonder how many of
                                            >> those 84%
                                            >> >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                            >> >>>>> "engineering practices." And, of those who claim to be doing
                                            >> some form
                                            >> >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                            >> >>>>> anything that would remotely resemble Agile to you or I.
                                            >> >>>>>
                                            >> >>>>> Also, as an aside, I've noticed that nearly every job
                                            >> description now
                                            >> >>>>> says "Experience with agile methodologies - especially Scrum or XP -
                                            >> >>>>> is desirable," or something quite similar. It makes using the job
                                            >> >>>>> boards more difficult, because nine out of ten of the results for
                                            >> >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                            >> >>>>>
                                            >> >>>>>
                                            >> >>>>
                                            >> >>>
                                            >> >>>
                                            >> >>> ------------------------------------
                                            >> >>>
                                            >> >>> To Post a message, send it to: scrumdevelopment@...
                                            >> <mailto:scrumdevelopment%40eGroups.com>
                                            >> >>> To Unsubscribe, send a blank message to:
                                            >> >>> scrumdevelopment-unsubscribe@...
                                            >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                            >> >>>
                                            >> >>>
                                            >> >>>
                                            >> >>>
                                            >> >>
                                            >> >>
                                            >> >
                                            >> >
                                            >> > ------------------------------------
                                            >> >
                                            >> > To Post a message, send it to: scrumdevelopment@...
                                            >> <mailto:scrumdevelopment%40eGroups.com>
                                            >> > To Unsubscribe, send a blank message to:
                                            >> > scrumdevelopment-unsubscribe@...
                                            >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                            >> >
                                            >> >
                                            >> >
                                            >> >
                                            >>
                                            >> --
                                            >> Sent from my mobile device
                                            >>
                                            >>
                                            >
                                            >



                                            --
                                          • Dan Rawsthorne
                                            Ah, but as a trainer and coach, my job is to make you better. I use hair splitting to get you to look at yourself and start introspection... I try to make sure
                                            Message 21 of 22 , Aug 1, 2009
                                            • 0 Attachment
                                              Ah, but as a trainer and coach, my job is to make you better. I use hair
                                              splitting to get you to look at yourself and start introspection... I
                                              try to make sure it's not about me, it's about you and scrum.

                                              Dan Rawsthorne, PhD, CST
                                              Senior Coach, Danube Technologies
                                              dan@..., 425-269-8628



                                              Peter Stevens (cal) wrote:
                                              >
                                              >
                                              > Hi Dan,
                                              >
                                              > Obviously hairsplitting can be the basis of a lively thread ... ;-)
                                              >
                                              > My experience with hair splitters in a live context is that they often
                                              > end up playing a game of "My Scrum is better than your Scrum." The
                                              > players argue about whether some practice is true Scrum or not. This
                                              > frustrates all involved parties and leads them away from the values
                                              > and principles of Scrum. So like a sharp knife, hair splitting is a
                                              > tool to be used carefully, at the risk of cutting off your own finger.
                                              >
                                              > Cheers,
                                              >
                                              > Peter
                                              >
                                              > Dan Rawsthorne wrote:
                                              >
                                              >>
                                              >>
                                              >> Ah, MJ, I agree with you. But I think that hairsplitting is important on
                                              >> this group, because if we don't know exactly what we're talking about
                                              >> here, how can we expect to explain it to others? The fact that I do
                                              >> split hairs has allowed me to have conversations like "yes, you're doing
                                              >> something like scrum, but you're not really Agile", and "yes, you're
                                              >> using C++, but you're not object oriented." I think that bad behavior
                                              >> hides in the mushiness, if we allow it.
                                              >>
                                              >> And, MJ, of course you should prioritize with a customer-centric focus.
                                              >> But that does not mean that you prioritize only things that have
                                              >> customer value. I know, more hair-splitting... but I've seen and heard
                                              >> of a lot of teams that have a hard time justifying something that
                                              >> obviously needs to be done (like rearranging the team room) because it
                                              >> doesn't have "customer value." The good news is that it's the SM's job
                                              >> to question all this and ask "why is this valuable again?" and "don't we
                                              >> need to do this?" when working with the PO. It's all about the
                                              >> conversations, remember... there really aren't that many rules.
                                              >>
                                              >> Dan Rawsthorne, PhD, CST
                                              >> Senior Coach, Danube Technologies
                                              >> dan@... <mailto:dan%40danube.com>, 425-269-8628
                                              >>
                                              >> Michael James wrote:
                                              >> >
                                              >> >
                                              >> > I find Dan technically correct in the hairsplitting contest, but I
                                              >> > sympathize more with Peter -- especially on the need to prioritize
                                              >> > with a customer-centric focus instead of appeasing all the internal
                                              >> > organizational crud that builds up as companies scale.
                                              >> >
                                              >> > If we're brought in to transform organizations, what's the point of
                                              >> > emphasizing loopholes that encourage them to keep doing what they've
                                              >> > been doing?
                                              >> >
                                              >> > --mj
                                              >> >
                                              >> > On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
                                              >> <mailto:dan.rawsthorne%40drdansplace.com>
                                              >> > <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
                                              >> > > * value to the user or customer -> what exactly should the
                                              >> product owner
                                              >> > > prioritize which doesn't have value to the customer or user? Lots of
                                              >> > > things, including things that have value to the business, the
                                              >> > > organization, the team, the product...
                                              >> > >
                                              >> > > Dan Rawsthorne, PhD, CST
                                              >> > > Senior Coach, Danube Technologies
                                              >> > > dan@... <mailto:dan%40danube.com>
                                              >> <mailto:dan%40danube.com>, 425-269-8628
                                              >> > >
                                              >> > >
                                              >> > >
                                              >> > > Peter Stevens (cal) wrote:
                                              >> > >>
                                              >> > >>
                                              >> > >> Hi Dan,
                                              >> > >>
                                              >> > >> I agree with your summary, but am puzzled by your disagreement
                                              >> on the
                                              >> > >> constraints.
                                              >> > >>
                                              >> > >> * value to the user or customer -> what exactly should the product
                                              >> > >> owner prioritize which doesn't have value to the customer or user?
                                              >> > >>
                                              >> > >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                              >> > >> stong. The team commits to do its best to meet the sprint goal and
                                              >> > >> backlog commitments. Timebox and Quality (Definition of Done)
                                              >> are more
                                              >> > >> important than Scope.
                                              >> > >>
                                              >> > >> * definition of done. I agree that the definition is agreed betweeen
                                              >> > >> P-O and Team (or perhaps even part of a departmental or company-wide
                                              >> > >> standard, but that is advanced magic ;-) ), but what is the
                                              >> problem of
                                              >> > >> the word 'formal'? You have X points, and the team commits to
                                              >> > >> satisfying all X points before presenting the result to the P-O.
                                              >> > >>
                                              >> > >> I have seen some variation of how the definition of done is taught.
                                              >> > >> Most CST's that I have seen thought of the definition of done as a
                                              >> > >> collection of quality checks, e.g. we have checked in the SW, done a
                                              >> > >> code review, all unit tests green, etc. Ken Schwaber (I had the
                                              >> honor
                                              >> > >> of attending his CSM course in Zürich last month) presented a
                                              >> template
                                              >> > >> defining all the tasks needed to complete a product backlog
                                              >> item. His
                                              >> > >> goal was to prevent 'undone' work:
                                              >> > >>
                                              >> > >> Developer: It's done.
                                              >> > >> P-O: OK, so we can release it.
                                              >> > >> Dev: Uh, no.
                                              >> > >> P-O: Why not?
                                              >> > >> Dev: Because we have to...
                                              >> > >>
                                              >> > >> Anything after the ellipses was undone work. As teams mature, the
                                              >> > >> amount of undone work after a sprint should approach zero. So
                                              >> you get
                                              >> > >> a rather long template for assuring that all PBI's are completed to
                                              >> > >> satisfaction.
                                              >> > >>
                                              >> > >> Cheers,
                                              >> > >>
                                              >> > >> Peter
                                              >> > >>
                                              >> > >>
                                              >> > >> Dan Rawsthorne wrote:
                                              >> > >>
                                              >> > >>> I love what you wrote, especially about the principles and
                                              >> values of
                                              >> > >>> scrum, but I disagree with all of your constraints :)
                                              >> > >>>
                                              >> > >>> * work committed at the beginning of a sprint must have value
                                              >> to the
                                              >> > >>> customer or user - I disagree. There are many sorts of value.
                                              >> > >>> Scrum is silent on which ones to use. All you know is that the PO
                                              >> > >>> prioritized it
                                              >> > >>>
                                              >> > >>> * work committed at the beginning of a sprint must be finished at
                                              >> > >>> the end of the sprint. - I disagree. There is a commitment. It is
                                              >> > >>> unclear what that commitment means. If there is pressure to finish
                                              >> > >>> nomatter what, technical debt and unsustainable pace naturally
                                              >> > >>> follow. So, again, what do you value?
                                              >> > >>>
                                              >> > >>> * the team must complete the work according to a formal definition
                                              >> > >>> of done - I nearly agree.I only disagree with the word "formal"
                                              >> > >>> here. I say "agreed to" definition of done
                                              >> > >>>
                                              >> > >>> The main think I know about scrum is once you get past the
                                              >> basics of
                                              >> > >>> "inspect and adapt" for both your product and process, virtually
                                              >> > >>> everything is malleable. That's on purpose, I think, because the
                                              >> > purpose
                                              >> > >>> is to maximize what your organization values, whatever that is.
                                              >> > >>>
                                              >> > >>> Dan Rawsthorne, PhD, CST
                                              >> > >>> Senior Coach, Danube Technologies
                                              >> > >>> dan@... <mailto:dan%40danube.com>
                                              >> <mailto:dan%40danube.com>, 425-269-8628
                                              >> > >>>
                                              >> > >>>
                                              >> > >>>
                                              >> > >>> Peter Stevens (cal) wrote:
                                              >> > >>>
                                              >> > >>>>
                                              >> > >>>>
                                              >> > >>>> Hi Adam,
                                              >> > >>>>
                                              >> > >>>> That's the problem with any self-reporting and lack of
                                              >> branding. What
                                              >> > >>>> the asker of a question means with the question and how the
                                              >> > respondent
                                              >> > >>>> interprets the question can be two entirely different things.
                                              >> > >>>>
                                              >> > >>>> At last year's Agile Business Conference in London, keynote
                                              >> speaker
                                              >> > >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                              >> > >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                              >> > >>>> Responsibility. So projects using everything from Scrum to XP
                                              >> to DSDM
                                              >> > >>>> to RUP could claim to be Agile.
                                              >> > >>>>
                                              >> > >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                              >> > >>>> test. "Is anybody really doing Scrum
                                              >> > >>>>
                                              >> >
                                              >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                                              >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>
                                              >>
                                              >> >
                                              >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                                              >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>>?"
                                              >> > >>>>
                                              >> > >>>> 3/4th of the respondents scored 7 or less. Because of the tool
                                              >> > used to
                                              >> > >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                              >> > >>>> definition of Agile (First 3 questions). The number of
                                              >> > respondents was
                                              >> > >>>> also rather small -- 47 -- so one might question how
                                              >> representative
                                              >> > >>>> this poll was. Since then, Robin Dymond has been started a
                                              >> project to
                                              >> > >>>> get 1000 respondents to answer an extended version of the test.
                                              >> > Last I
                                              >> > >>>> heard, he had 360 respondents, so he hasn't published any results
                                              >> > yet.
                                              >> > >>>>
                                              >> > >>>> The speaker at last month's the Scrum Breakfast, Silvan
                                              >> > Mühlemann, CTO
                                              >> > >>>> of tilllate.com, described his company's getting started with
                                              >> Scrum.
                                              >> > >>>> When he started, he didn't believe that Scrum would work in his
                                              >> > >>>> company, so he changed it. Pretty dramatically. For instance, time
                                              >> > >>>> boxes yes, fixed length iterations no. At the beginning of his
                                              >> > talk, I
                                              >> > >>>> wondered if we could even call his process Scrum. He
                                              >> definitely broke
                                              >> > >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                                              >> > That
                                              >> > >>>> process brought him closer to Scrum by the book (adding
                                              >> > >>>> retrospectives, daily scrums, ready to try again with fixed length
                                              >> > >>>> iterations, etc).
                                              >> > >>>>
                                              >> > >>>> The talk was a real eye opener. If your top management gets the
                                              >> > >>>> principles of Scrum, the practices are less of an issue. If they
                                              >> > >>>> don't, well, it can be tough.
                                              >> > >>>>
                                              >> > >>>> Scrum doesn't actually specify any engineering practices. It
                                              >> > specifies
                                              >> > >>>> three constraints:
                                              >> > >>>>
                                              >> > >>>> * work committed at the beginning of a sprint must have value to
                                              >> > >>>> the customer or user
                                              >> > >>>> * work committed at the beginning of a sprint must be finished at
                                              >> > >>>> the end of the sprint.
                                              >> > >>>> * the team must complete the work according to a formal definition
                                              >> > >>>> of done
                                              >> > >>>>
                                              >> > >>>> These constraints drive most teams to move towards XP engineering
                                              >> > >>>> practices (even though there is no requirement to do so). I am not
                                              >> > >>>> aware of any evidence which shows that doing agile engineering
                                              >> leads
                                              >> > >>>> companies to adopt agile management practices, so Scrum is the
                                              >> place
                                              >> > >>>> to start.
                                              >> > >>>>
                                              >> > >>>> So, coming back to your original post, I think you've got the
                                              >> numbers
                                              >> > >>>> and messages you need:
                                              >> > >>>>
                                              >> > >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                              >> > >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                              >> > >>>> place to start.
                                              >> > >>>> 3. Scrum is hard, so management buy in and commitment are
                                              >> essential.
                                              >> > >>>>
                                              >> > >>>> Now it's time for management to self organize: "How do you
                                              >> convince
                                              >> > >>>> yourselves the Scrum and Agile are worthy of serious
                                              >> commitment? How
                                              >> > >>>> do you learn to walk the walk?"
                                              >> > >>>>
                                              >> > >>>> Cheers,
                                              >> > >>>>
                                              >> > >>>> Peter
                                              >> > >>>>
                                              >> > >>>>
                                              >> > >>>>
                                              >> > >>>> Adam Sroka wrote:
                                              >> > >>>>
                                              >> > >>>>> Ken's numbers match my experience, but I wonder how many of
                                              >> > those 84%
                                              >> > >>>>> are doing some kind of Scrum-but with absolutely none of the
                                              >> Agile
                                              >> > >>>>> "engineering practices." And, of those who claim to be doing
                                              >> > some form
                                              >> > >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                              >> > >>>>> anything that would remotely resemble Agile to you or I.
                                              >> > >>>>>
                                              >> > >>>>> Also, as an aside, I've noticed that nearly every job
                                              >> > description now
                                              >> > >>>>> says "Experience with agile methodologies - especially Scrum
                                              >> or XP -
                                              >> > >>>>> is desirable," or something quite similar. It makes using the job
                                              >> > >>>>> boards more difficult, because nine out of ten of the results for
                                              >> > >>>>> "agile," "XP," and "Scrum," are false positives (For my
                                              >> purposes.)
                                              >> > >>>>>
                                              >> > >>>>>
                                              >> > >>>>
                                              >> > >>>
                                              >> > >>>
                                              >> > >>> ------------------------------------
                                              >> > >>>
                                              >> > >>> To Post a message, send it to: scrumdevelopment@...
                                              >> <mailto:scrumdevelopment%40eGroups.com>
                                              >> > <mailto:scrumdevelopment%40eGroups.com>
                                              >> > >>> To Unsubscribe, send a blank message to:
                                              >> > >>> scrumdevelopment-unsubscribe@...
                                              >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>
                                              >> > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                              >> > >>>
                                              >> > >>>
                                              >> > >>>
                                              >> > >>>
                                              >> > >>
                                              >> > >>
                                              >> > >
                                              >> > >
                                              >> > > ------------------------------------
                                              >> > >
                                              >> > > To Post a message, send it to: scrumdevelopment@...
                                              >> <mailto:scrumdevelopment%40eGroups.com>
                                              >> > <mailto:scrumdevelopment%40eGroups.com>
                                              >> > > To Unsubscribe, send a blank message to:
                                              >> > > scrumdevelopment-unsubscribe@...
                                              >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>
                                              >> > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                              >> > >
                                              >> > >
                                              >> > >
                                              >> > >
                                              >> >
                                              >> > --
                                              >> > Sent from my mobile device
                                              >> >
                                              >> >
                                              >>
                                              >
                                              >
                                            • Michael Vizdos
                                              ... and remember you are dealing with people who *love* splitting hairs. Me... I just use comic strips as an outlet... and working with teams to deliver
                                              Message 22 of 22 , Aug 1, 2009
                                              • 0 Attachment
                                                ... and remember you are dealing with people who *love* splitting hairs.

                                                Me... I just use comic strips as an outlet... and working with teams
                                                to deliver working software around the world :).

                                                Thank you,

                                                - Mike Vizdos
                                                Vizdos Enterprises, LLC

                                                Contact Information

                                                Phone: (262) MVIZDOS / (262) 684-9367
                                                Web: www.implementingscrum.com
                                                www.michaelvizdos.com
                                                AOL IM: MikeV Work
                                                Twitter: www.twitter.com/mvizdos
                                                Skype: mvizdos

                                                PS: Come to one of my workshops. Visit michaelvizdos.com/enroll.

                                                PPS: Visit implementingscrum.com/subscribe. Receive 2 FREE videos.





                                                On Sat, Aug 1, 2009 at 6:39 AM, Peter Stevens (cal)<peterstev@...> wrote:
                                                >
                                                >
                                                > Hi Dan,
                                                >
                                                > Obviously hairsplitting can be the basis of a lively thread ... ;-)
                                                >
                                                > My experience with hair splitters in a live context is that they often end
                                                > up playing a game of "My Scrum is better than your Scrum." The players argue
                                                > about whether some practice is true Scrum or not. This frustrates all
                                                > involved parties and leads them away from the values and principles of
                                                > Scrum. So like a sharp knife, hair splitting is a tool to be used carefully,
                                                > at the risk of cutting off your own finger.
                                                >
                                                > Cheers,
                                                >
                                                > Peter
                                                >
                                                > Dan Rawsthorne wrote:
                                                >
                                                >
                                                >
                                                > Ah, MJ, I agree with you. But I think that hairsplitting is important on
                                                > this group, because if we don't know exactly what we're talking about
                                                > here, how can we expect to explain it to others? The fact that I do
                                                > split hairs has allowed me to have conversations like "yes, you're doing
                                                > something like scrum, but you're not really Agile", and "yes, you're
                                                > using C++, but you're not object oriented." I think that bad behavior
                                                > hides in the mushiness, if we allow it.
                                                >
                                                > And, MJ, of course you should prioritize with a customer-centric focus.
                                                > But that does not mean that you prioritize only things that have
                                                > customer value. I know, more hair-splitting... but I've seen and heard
                                                > of a lot of teams that have a hard time justifying something that
                                                > obviously needs to be done (like rearranging the team room) because it
                                                > doesn't have "customer value." The good news is that it's the SM's job
                                                > to question all this and ask "why is this valuable again?" and "don't we
                                                > need to do this?" when working with the PO. It's all about the
                                                > conversations, remember... there really aren't that many rules.
                                                >
                                                > Dan Rawsthorne, PhD, CST
                                                > Senior Coach, Danube Technologies
                                                > dan@..., 425-269-8628
                                                >
                                                > Michael James wrote:
                                                >>
                                                >>
                                                >> I find Dan technically correct in the hairsplitting contest, but I
                                                >> sympathize more with Peter -- especially on the need to prioritize
                                                >> with a customer-centric focus instead of appeasing all the internal
                                                >> organizational crud that builds up as companies scale.
                                                >>
                                                >> If we're brought in to transform organizations, what's the point of
                                                >> emphasizing loopholes that encourage them to keep doing what they've
                                                >> been doing?
                                                >>
                                                >> --mj
                                                >>
                                                >> On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
                                                >> <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
                                                >> > * value to the user or customer -> what exactly should the product owner
                                                >> > prioritize which doesn't have value to the customer or user? Lots of
                                                >> > things, including things that have value to the business, the
                                                >> > organization, the team, the product...
                                                >> >
                                                >> > Dan Rawsthorne, PhD, CST
                                                >> > Senior Coach, Danube Technologies
                                                >> > dan@... <mailto:dan%40danube.com>, 425-269-8628
                                                >> >
                                                >> >
                                                >> >
                                                >> > Peter Stevens (cal) wrote:
                                                >> >>
                                                >> >>
                                                >> >> Hi Dan,
                                                >> >>
                                                >> >> I agree with your summary, but am puzzled by your disagreement on the
                                                >> >> constraints.
                                                >> >>
                                                >> >> * value to the user or customer -> what exactly should the product
                                                >> >> owner prioritize which doesn't have value to the customer or user?
                                                >> >>
                                                >> >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
                                                >> >> stong. The team commits to do its best to meet the sprint goal and
                                                >> >> backlog commitments. Timebox and Quality (Definition of Done) are more
                                                >> >> important than Scope.
                                                >> >>
                                                >> >> * definition of done. I agree that the definition is agreed betweeen
                                                >> >> P-O and Team (or perhaps even part of a departmental or company-wide
                                                >> >> standard, but that is advanced magic ;-) ), but what is the problem of
                                                >> >> the word 'formal'? You have X points, and the team commits to
                                                >> >> satisfying all X points before presenting the result to the P-O.
                                                >> >>
                                                >> >> I have seen some variation of how the definition of done is taught.
                                                >> >> Most CST's that I have seen thought of the definition of done as a
                                                >> >> collection of quality checks, e.g. we have checked in the SW, done a
                                                >> >> code review, all unit tests green, etc. Ken Schwaber (I had the honor
                                                >> >> of attending his CSM course in Zürich last month) presented a template
                                                >> >> defining all the tasks needed to complete a product backlog item. His
                                                >> >> goal was to prevent 'undone' work:
                                                >> >>
                                                >> >> Developer: It's done.
                                                >> >> P-O: OK, so we can release it.
                                                >> >> Dev: Uh, no.
                                                >> >> P-O: Why not?
                                                >> >> Dev: Because we have to...
                                                >> >>
                                                >> >> Anything after the ellipses was undone work. As teams mature, the
                                                >> >> amount of undone work after a sprint should approach zero. So you get
                                                >> >> a rather long template for assuring that all PBI's are completed to
                                                >> >> satisfaction.
                                                >> >>
                                                >> >> Cheers,
                                                >> >>
                                                >> >> Peter
                                                >> >>
                                                >> >>
                                                >> >> Dan Rawsthorne wrote:
                                                >> >>
                                                >> >>> I love what you wrote, especially about the principles and values of
                                                >> >>> scrum, but I disagree with all of your constraints :)
                                                >> >>>
                                                >> >>> * work committed at the beginning of a sprint must have value to the
                                                >> >>> customer or user - I disagree. There are many sorts of value.
                                                >> >>> Scrum is silent on which ones to use. All you know is that the PO
                                                >> >>> prioritized it
                                                >> >>>
                                                >> >>> * work committed at the beginning of a sprint must be finished at
                                                >> >>> the end of the sprint. - I disagree. There is a commitment. It is
                                                >> >>> unclear what that commitment means. If there is pressure to finish
                                                >> >>> nomatter what, technical debt and unsustainable pace naturally
                                                >> >>> follow. So, again, what do you value?
                                                >> >>>
                                                >> >>> * the team must complete the work according to a formal definition
                                                >> >>> of done - I nearly agree.I only disagree with the word "formal"
                                                >> >>> here. I say "agreed to" definition of done
                                                >> >>>
                                                >> >>> The main think I know about scrum is once you get past the basics of
                                                >> >>> "inspect and adapt" for both your product and process, virtually
                                                >> >>> everything is malleable. That's on purpose, I think, because the
                                                >> purpose
                                                >> >>> is to maximize what your organization values, whatever that is.
                                                >> >>>
                                                >> >>> Dan Rawsthorne, PhD, CST
                                                >> >>> Senior Coach, Danube Technologies
                                                >> >>> dan@... <mailto:dan%40danube.com>, 425-269-8628
                                                >> >>>
                                                >> >>>
                                                >> >>>
                                                >> >>> Peter Stevens (cal) wrote:
                                                >> >>>
                                                >> >>>>
                                                >> >>>>
                                                >> >>>> Hi Adam,
                                                >> >>>>
                                                >> >>>> That's the problem with any self-reporting and lack of branding. What
                                                >> >>>> the asker of a question means with the question and how the
                                                >> respondent
                                                >> >>>> interprets the question can be two entirely different things.
                                                >> >>>>
                                                >> >>>> At last year's Agile Business Conference in London, keynote speaker
                                                >> >>>> Rob Thomsett defined Agile as a set of values, not as a set of
                                                >> >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
                                                >> >>>> Responsibility. So projects using everything from Scrum to XP to DSDM
                                                >> >>>> to RUP could claim to be Agile.
                                                >> >>>>
                                                >> >>>> I conducted a poll last summer asking the 8 questions of the Nokia
                                                >> >>>> test. "Is anybody really doing Scrum
                                                >> >>>>
                                                >>
                                                >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
                                                >>
                                                >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>?"
                                                >> >>>>
                                                >> >>>> 3/4th of the respondents scored 7 or less. Because of the tool
                                                >> used to
                                                >> >>>> collect the data, I couldn't tell how many satisfied Nokia's
                                                >> >>>> definition of Agile (First 3 questions). The number of
                                                >> respondents was
                                                >> >>>> also rather small -- 47 -- so one might question how representative
                                                >> >>>> this poll was. Since then, Robin Dymond has been started a project to
                                                >> >>>> get 1000 respondents to answer an extended version of the test.
                                                >> Last I
                                                >> >>>> heard, he had 360 respondents, so he hasn't published any results
                                                >> yet.
                                                >> >>>>
                                                >> >>>> The speaker at last month's the Scrum Breakfast, Silvan
                                                >> Mühlemann, CTO
                                                >> >>>> of tilllate.com, described his company's getting started with Scrum.
                                                >> >>>> When he started, he didn't believe that Scrum would work in his
                                                >> >>>> company, so he changed it. Pretty dramatically. For instance, time
                                                >> >>>> boxes yes, fixed length iterations no. At the beginning of his
                                                >> talk, I
                                                >> >>>> wondered if we could even call his process Scrum. He definitely broke
                                                >> >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
                                                >> That
                                                >> >>>> process brought him closer to Scrum by the book (adding
                                                >> >>>> retrospectives, daily scrums, ready to try again with fixed length
                                                >> >>>> iterations, etc).
                                                >> >>>>
                                                >> >>>> The talk was a real eye opener. If your top management gets the
                                                >> >>>> principles of Scrum, the practices are less of an issue. If they
                                                >> >>>> don't, well, it can be tough.
                                                >> >>>>
                                                >> >>>> Scrum doesn't actually specify any engineering practices. It
                                                >> specifies
                                                >> >>>> three constraints:
                                                >> >>>>
                                                >> >>>> * work committed at the beginning of a sprint must have value to
                                                >> >>>> the customer or user
                                                >> >>>> * work committed at the beginning of a sprint must be finished at
                                                >> >>>> the end of the sprint.
                                                >> >>>> * the team must complete the work according to a formal definition
                                                >> >>>> of done
                                                >> >>>>
                                                >> >>>> These constraints drive most teams to move towards XP engineering
                                                >> >>>> practices (even though there is no requirement to do so). I am not
                                                >> >>>> aware of any evidence which shows that doing agile engineering leads
                                                >> >>>> companies to adopt agile management practices, so Scrum is the place
                                                >> >>>> to start.
                                                >> >>>>
                                                >> >>>> So, coming back to your original post, I think you've got the numbers
                                                >> >>>> and messages you need:
                                                >> >>>>
                                                >> >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
                                                >> >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
                                                >> >>>> place to start.
                                                >> >>>> 3. Scrum is hard, so management buy in and commitment are essential.
                                                >> >>>>
                                                >> >>>> Now it's time for management to self organize: "How do you convince
                                                >> >>>> yourselves the Scrum and Agile are worthy of serious commitment? How
                                                >> >>>> do you learn to walk the walk?"
                                                >> >>>>
                                                >> >>>> Cheers,
                                                >> >>>>
                                                >> >>>> Peter
                                                >> >>>>
                                                >> >>>>
                                                >> >>>>
                                                >> >>>> Adam Sroka wrote:
                                                >> >>>>
                                                >> >>>>> Ken's numbers match my experience, but I wonder how many of
                                                >> those 84%
                                                >> >>>>> are doing some kind of Scrum-but with absolutely none of the Agile
                                                >> >>>>> "engineering practices." And, of those who claim to be doing
                                                >> some form
                                                >> >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
                                                >> >>>>> anything that would remotely resemble Agile to you or I.
                                                >> >>>>>
                                                >> >>>>> Also, as an aside, I've noticed that nearly every job
                                                >> description now
                                                >> >>>>> says "Experience with agile methodologies - especially Scrum or XP -
                                                >> >>>>> is desirable," or something quite similar. It makes using the job
                                                >> >>>>> boards more difficult, because nine out of ten of the results for
                                                >> >>>>> "agile," "XP," and "Scrum," are false positives (For my purposes.)
                                                >> >>>>>
                                                >> >>>>>
                                                >> >>>>
                                                >> >>>
                                                >> >>>
                                                >> >>> ------------------------------------
                                                >
                                                >> >>>
                                                >> >>> To Post a message, send it to: scrumdevelopment@...
                                                >> <mailto:scrumdevelopment%40eGroups.com>
                                                >> >>> To Unsubscribe, send a blank message to:
                                                >> >>> scrumdevelopment-unsubscribe@...
                                                >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                                >> >>>
                                                >> >>>
                                                >> >>>
                                                >> >>>
                                                >> >>
                                                >> >>
                                                >> >
                                                >> >
                                                >> > ------------------------------------
                                                >> >
                                                >> > To Post a message, send it to: scrumdevelopment@...
                                                >> <mailto:scrumdevelopment%40eGroups.com>
                                                >> > To Unsubscribe, send a blank message to:
                                                >> > scrumdevelopment-unsubscribe@...
                                                >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                                                >> >
                                                >> >
                                                >> >
                                                >> >
                                                >>
                                                >> --
                                                >> Sent from my mobile device
                                                >>
                                                >>
                                                >
                                                >
                                              Your message has been successfully submitted and would be delivered to recipients shortly.