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

Re: [scrumdevelopment] Re: How popular is SCRUM and agile?

Expand Messages
  • 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 1 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 2 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 3 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 4 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.