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

Customer Satisfaction and Agile Methods

Expand Messages
  • donald.buresh
    To Whom It May Concern, Because of the significance of the work, and because of demand, I decided to publish the results of my research with VDM Publishing
    Message 1 of 12 , Nov 7, 2008
    • 0 Attachment
      To Whom It May Concern,

      Because of the significance of the work, and because of demand, I
      decided to publish the results of my research with VDM Publishing
      LLC. The web site is www.vdm-publishing,com. The book is
      entitled: "Customer Satisfaction and Agile Methods", and the ISBN
      number is 978-3-639-09476-3.

      The research surveyed 185 projects, and the results proved to be
      quite controversial, provocative, and unexpected. You will not look
      at agile methods the same way after you have read my book. You will
      not believe all of the hype that has been written about the use and
      results of agile methods. The next time that you read something on
      agile methods, you will think of my research. You will come away from
      my book with a greater understanding of what agile methods are all
      about, and what they can and do achieve, but more importantly, what
      they cannot and do not achieve.

      If you are interested in agile methods, but are unsure whether they
      are the right software development methods to employ, then my book is
      for you. In my book, you will find hard data on the characteristics
      of projects, participants, and whether agile methods are the only
      software development to use to satisfy your customers.

      I invite you to contact VDM Publishing LLC regarding my book
      entitled "Customer Satisfaction and Agile Methods", and find out for
      yourself the real value of employing agile software development
      methods rather than plan-driven software development methods.

      Donald L. Buresh, Ph.D.
      3115 Enoch Avenue
      Zion, IL 60099
      Tele: 847-872-1659
      LoganSquareDon@...
    • Michael Dubakov
      Too many my in this ad post... And the attempt to scare agile community ;) Michael Dubakov http://www.targetprocess.com/blog
      Message 2 of 12 , Nov 7, 2008
      • 0 Attachment
        Too many "my" in this ad post...

        And the attempt to scare agile community ;)

        Michael Dubakov
        http://www.targetprocess.com/blog

        --- In scrumdevelopment@yahoogroups.com, "donald.buresh"
        <donald.buresh@...> wrote:
        >
        > To Whom It May Concern,
        >
        > Because of the significance of the work, and because of demand, I
        > decided to publish the results of my research with VDM Publishing
        > LLC. The web site is www.vdm-publishing,com. The book is
        > entitled: "Customer Satisfaction and Agile Methods", and the ISBN
        > number is 978-3-639-09476-3.
        >
        > The research surveyed 185 projects, and the results proved to be
        > quite controversial, provocative, and unexpected. You will not look
        > at agile methods the same way after you have read my book. You will
        > not believe all of the hype that has been written about the use and
        > results of agile methods. The next time that you read something on
        > agile methods, you will think of my research. You will come away from
        > my book with a greater understanding of what agile methods are all
        > about, and what they can and do achieve, but more importantly, what
        > they cannot and do not achieve.
        >
        > If you are interested in agile methods, but are unsure whether they
        > are the right software development methods to employ, then my book is
        > for you. In my book, you will find hard data on the characteristics
        > of projects, participants, and whether agile methods are the only
        > software development to use to satisfy your customers.
        >
        > I invite you to contact VDM Publishing LLC regarding my book
        > entitled "Customer Satisfaction and Agile Methods", and find out for
        > yourself the real value of employing agile software development
        > methods rather than plan-driven software development methods.
        >
        > Donald L. Buresh, Ph.D.
        > 3115 Enoch Avenue
        > Zion, IL 60099
        > Tele: 847-872-1659
        > LoganSquareDon@...
        >
      • Paul Oldfield
        (responding to Michael) ... My experience tells me that my list of what agile methods cannot achieve is often smaller than that of other folk. Perhaps I m
        Message 3 of 12 , Nov 7, 2008
        • 0 Attachment
          (responding to Michael)

          > Too many "my" in this ad post...
          >
          > And the attempt to scare agile community ;)

          ...or those of them ruled by fear ;)

          > <donald.buresh@> wrote:
          > >
          > > To Whom It May Concern, ...
          > >
          > > ... but more importantly, what
          > > they cannot and do not achieve.

          My experience tells me that my list of what agile
          methods cannot achieve is often smaller than that
          of other folk. Perhaps I'm using a different
          definition of the word 'cannot'; or maybe I really
          do value people over process, etc. If people
          cannot do it then an agile method cannot do it,
          *and vice versa* IMHO. An agile method should
          harness the power of people, not constrain it.

          Hmm... did I just argue that we could use an agile
          method and be really inefficient, because people
          can be really inefficient? Oh dear. These
          sweeping generalisations have their drawbacks. Ho Hum.

          Paul Oldfield
          Capgemini
        • Alan Dayley
          ... --[clip]-- That was a disappointing ad. I was expecting some shared insight and discussion from which I could learn something about Scrum and agile. Alan
          Message 4 of 12 , Nov 7, 2008
          • 0 Attachment
            On Fri, Nov 7, 2008 at 3:37 AM, donald.buresh <donald.buresh@...> wrote:
            > To Whom It May Concern,
            >
            > Because of the significance of the work, and because of demand, I
            > decided to publish the results of my research with VDM Publishing
            --[clip]--

            That was a disappointing ad. I was expecting some shared insight and
            discussion from which I could learn something about Scrum and agile.

            Alan
          • Ilja Preuß
            Yeah - just fluff, no stuff...
            Message 5 of 12 , Nov 7, 2008
            • 0 Attachment
              Yeah - just fluff, no stuff...

              2008/11/7 Alan Dayley <alandd@...>:
              > On Fri, Nov 7, 2008 at 3:37 AM, donald.buresh <donald.buresh@...>
              > wrote:
              >> To Whom It May Concern,
              >>
              >> Because of the significance of the work, and because of demand, I
              >> decided to publish the results of my research with VDM Publishing
              > --[clip]--
              >
              > That was a disappointing ad. I was expecting some shared insight and
              > discussion from which I could learn something about Scrum and agile.
              >
              > Alan
              >
              >
            • Mark Levison
              Please consider the source of this FUD. Mr Buresh has never participated on this on or any other agile newsgroup except to ask that we complete his survey.
              Message 6 of 12 , Nov 7, 2008
              • 0 Attachment
                Please consider the source of this FUD. Mr Buresh has never participated on this on or any other agile newsgroup except to ask that we complete his survey.

                Donald instead of trying to intimidate and threaten why not engage us in a conversation? As to the hype you allude to I don't give a moments thought, my time is spent on delivering value to customers.
                --
                Cheers
                Mark Levison

                Blog: http://www.notesfromatooluser.com/
                Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
                Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
              • mike.dwyer1@comcast.net
                Dr Don I have a couple of questions before I shell out any money for your study. 1. When I saw you trolling for a while ago,I was wondering what your
                Message 7 of 12 , Nov 7, 2008
                • 0 Attachment
                  Dr Don
                  I have a couple of questions before I shell out any money for your study.
                  1. When I saw you trolling for a while ago,I was wondering what your definition of Agile and Agile projects were, Do you have this in the study? does your study show how many submissions met your criteria and how many failed? Or did you decide to let people self identify their work as Agile?

                  If the latter, did you build a profile of what Agile is to people who self identify their work as Agile? Did you have a baseline definition or did you just go with the norm?

                  2. Did you gain any notion of what the scaling boundaries are?

                  I could go on and on but the bottom line is Dr Don, I dont like being treated like a Fox News devotee and if you are interested in getting my attention then chum the waters with some facts and empirical evidence.


                  --
                  Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


                  The greatest oak was once a little nut who held its ground. ~Author Unknown


                  -------------- Original message ----------------------
                  From: "donald.buresh" <donald.buresh@...>
                  > To Whom It May Concern,
                  >
                  > Because of the significance of the work, and because of demand, I
                  > decided to publish the results of my research with VDM Publishing
                  > LLC. The web site is www.vdm-publishing,com. The book is
                  > entitled: "Customer Satisfaction and Agile Methods", and the ISBN
                  > number is 978-3-639-09476-3.
                  >
                  > The research surveyed 185 projects, and the results proved to be
                  > quite controversial, provocative, and unexpected. You will not look
                  > at agile methods the same way after you have read my book. You will
                  > not believe all of the hype that has been written about the use and
                  > results of agile methods. The next time that you read something on
                  > agile methods, you will think of my research. You will come away from
                  > my book with a greater understanding of what agile methods are all
                  > about, and what they can and do achieve, but more importantly, what
                  > they cannot and do not achieve.
                  >
                  > If you are interested in agile methods, but are unsure whether they
                  > are the right software development methods to employ, then my book is
                  > for you. In my book, you will find hard data on the characteristics
                  > of projects, participants, and whether agile methods are the only
                  > software development to use to satisfy your customers.
                  >
                  > I invite you to contact VDM Publishing LLC regarding my book
                  > entitled "Customer Satisfaction and Agile Methods", and find out for
                  > yourself the real value of employing agile software development
                  > methods rather than plan-driven software development methods.
                  >
                  > Donald L. Buresh, Ph.D.
                  > 3115 Enoch Avenue
                  > Zion, IL 60099
                  > Tele: 847-872-1659
                  > LoganSquareDon@...
                  >
                  >
                  >
                  >
                • aacockburn
                  ... I don t think it was an attempt to scare the agile community, because it was obviously a mass mailing, and coming to this list in an unnoticed sort of way.
                  Message 8 of 12 , Nov 7, 2008
                  • 0 Attachment
                    --- In scrumdevelopment@yahoogroups.com, "Paul Oldfield"
                    <PaulOldfield1@...> wrote:
                    >
                    > (responding to Michael)
                    >
                    > > Too many "my" in this ad post...
                    > >
                    > > And the attempt to scare agile community ;)

                    I don't think it was an attempt to scare the agile community,
                    because it was obviously a mass mailing, and coming to this list
                    in an unnoticed sort of way.


                    >
                    > ...or those of them ruled by fear ;)
                    >
                    > > <donald.buresh@> wrote:
                    > > >
                    > > > To Whom It May Concern, ...
                    > > >
                    > > > ... but more importantly, what
                    > > > they cannot and do not achieve.
                    >
                    > My experience tells me that my list of what agile
                    > methods cannot achieve is often smaller than that
                    > of other folk. Perhaps I'm using a different
                    > definition of the word 'cannot'; or maybe I really
                    > do value people over process, etc. If people
                    > cannot do it then an agile method cannot do it,
                    > *and vice versa* IMHO. An agile method should
                    > harness the power of people, not constrain it.
                    >
                    > Hmm... did I just argue that we could use an agile
                    > method and be really inefficient, because people
                    > can be really inefficient?

                    Nice thought! Think I'll go out and hire 100 low-cost novice
                    programmers, put them all into a room, throw in a pile of
                    index cards, and see what they produce at the end of the month
                    for our farm-equipment-refinancing sponsors. I'll have the medics
                    and the morticians standing by.

                    :-) Alistair
                  • Roy Morien
                    One thing that concerns me about this post is the statement ... because people can be really inefficient. Yes, very true. I guess it doesn t matter what line
                    Message 9 of 12 , Nov 7, 2008
                    • 0 Attachment
                      One thing that concerns me about this post is the statement "... because people can be really inefficient."
                       
                      Yes, very true. I guess it doesn't matter what line of work you're in, you can be inefficient.
                       
                      But IT / IS developers are supposed to be well educated professionals, I would have thought. HR selection processes should have been appropriate and successful in selecting reasonably well qualified and efficient (and effective) professionals. If not, then it is a selection process failure.
                       
                      Universities and colleges responsible for the education of IS / IT professionals are supposed to provide a good level of professional education to (potential) IS / IS developers. If they have not, they have failed.
                       
                      Statements about how people can be so inefficient, or so apathetic, or so disinterested are not statements about system development process, theories and practices. They are about the people involved. If that is failing, it is not a failure of the process, it is a failure of other factors.
                       
                      But, to me, the discussion should be about the best way to develop systems, by competent professional developers. Move the discussion about incompetent, apathetic, inefficient people over to the HR interest group, or wherever staff selection and development is discussed.
                       
                      Regards,
                      Roy Morien  




                      To: scrumdevelopment@yahoogroups.com
                      From: acockburn@...
                      Date: Fri, 7 Nov 2008 15:51:40 +0000
                      Subject: [scrumdevelopment] Re: Customer Satisfaction and Agile Methods


                      --- In scrumdevelopment@ yahoogroups. com, "Paul Oldfield"
                      <PaulOldfield1@ ...> wrote:
                      >
                      > (responding to Michael)
                      >
                      > > Too many "my" in this ad post...
                      > >
                      > > And the attempt to scare agile community ;)

                      I don't think it was an attempt to scare the agile community,
                      because it was obviously a mass mailing, and coming to this list
                      in an unnoticed sort of way.

                      >
                      > ...or those of them ruled by fear ;)
                      >
                      > > <donald.buresh@ > wrote:
                      > > >
                      > > > To Whom It May Concern, ...
                      > > >
                      > > > ... but more importantly, what
                      > > > they cannot and do not achieve.
                      >
                      > My experience tells me that my list of what agile
                      > methods cannot achieve is often smaller than that
                      > of other folk. Perhaps I'm using a different
                      > definition of the word 'cannot'; or maybe I really
                      > do value people over process, etc. If people
                      > cannot do it then an agile method cannot do it,
                      > *and vice versa* IMHO. An agile method should
                      > harness the power of people, not constrain it.
                      >
                      > Hmm... did I just argue that we could use an agile
                      > method and be really inefficient, because people
                      > can be really inefficient?

                      Nice thought! Think I'll go out and hire 100 low-cost novice
                      programmers, put them all into a room, throw in a pile of
                      index cards, and see what they produce at the end of the month
                      for our farm-equipment- refinancing sponsors. I'll have the medics
                      and the morticians standing by.

                      :-) Alistair




                      Sign up for the Hotmail Road Trip today. Your dream beach house escape for summer!
                    • Paul Oldfield
                      (responding to Roy) ... Bringing the discussion back to the point I was trying to make - Yes, people are not perfect. This helps explain why sometimes a
                      Message 10 of 12 , Nov 10, 2008
                      • 0 Attachment
                        (responding to Roy)

                        > One thing that concerns me about this post is the
                        > statement "... because people can be really inefficient."
                        >
                        > Yes, very true. I guess it doesn't matter what line of
                        > work you're in, you can be inefficient.

                        Bringing the discussion back to the point I was trying
                        to make - Yes, people are not perfect. This helps explain
                        why sometimes a nominally agile approach does not deliver.

                        But I have strong objections when people start saying
                        that an agile approach "cannot" deliver. I doubt the
                        author has sufficient understanding to make such a
                        statement with any degree of accuracy.

                        There's a big difference between saying "This can't work"
                        and "I don't know how to make this work".

                        Paul Oldfield
                        Capgemini
                      • Ron Jeffries
                        Hello, Paul. On Monday, November 10, 2008, at 3:38:38 AM, you ... Or Whatever we did, that didn t work. Ron Jeffries www.XProgramming.com
                        Message 11 of 12 , Nov 10, 2008
                        • 0 Attachment
                          Hello, Paul. On Monday, November 10, 2008, at 3:38:38 AM, you
                          wrote:

                          > There's a big difference between saying "This can't work"
                          > and "I don't know how to make this work".

                          Or "Whatever we did, that didn't work."

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          How do I know what I think until I hear what I say? -- E M Forster
                        • aacockburn
                          ... Got lots of those. Frightening to say to a client (and I ve said it a couple of times), If you want to do that, we have to try something that s never been
                          Message 12 of 12 , Nov 10, 2008
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                            <ronjeffries@...> wrote:
                            >
                            > Hello, Paul. On Monday, November 10, 2008, at 3:38:38 AM, you
                            > wrote:
                            >
                            > > There's a big difference between saying "This can't work"
                            > > and "I don't know how to make this work".
                            >
                            > Or "Whatever we did, that didn't work."
                            >

                            Got lots of those. Frightening to say to a client (and I've said it
                            a couple of times), "If you want to do that, we have to try something
                            that's never been tried before. As far as I can tell, everything
                            that's been tried so far doesn't work. So we have to try something
                            different."

                            Of course, whatever we tried didn't work.
                          Your message has been successfully submitted and would be delivered to recipients shortly.