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

Re: [XP] Hypotheses, Theories and Research (was Results are in on organizational culture survey)

Expand Messages
  • PAUL
    Hi Steve, Charlie, Now it makes sense. I understand you. Your reluctance is the ends to which research is used, and I agree with you. They say there are lies
    Message 1 of 178 , Jul 10, 2010
    • 0 Attachment
      Hi Steve, Charlie,

      Now it makes sense. I understand you. Your reluctance is the ends to which research is used, and I agree with you. They say there are lies damned lies and statistics. I think the social sciences suffer from this too. I know of social workers who are tired of people running off with the latest research as though it is God given fact.

      Another interesting point worth raising is who is sponsoring the research and why? Having said this there are valuable questions researchers could help us answer.

      Such as why does Agile work and Where?

      What is happening when attempts at Agility fail? and why?

      What are the pre-requisites for Agile success?

      I am coming strongly to the opinion that Agile isn't for everyone. Some environments just aren't ready and may need to take an approach to improvement that is less challenging. Becoming Agile in one bound is just out of their grasp.

      Those of us who get it understand these things intuitively I feel, but it would be nice to back up this intuitive understanding with some academic research.

      None of us here are academics, and it seems sensible to me for us to foster postive relationships with the academic community to get better answers to questions that matter to us.

      Regards,

      Paul.


      --- In extremeprogramming@yahoogroups.com, Charlie Poole <charlie@...> wrote:
      >
      > Hi Steve,
      >
      > It sounds as if we agree on most things when it comes to wearing our
      > "practitioner hats." I myself have no "academic hat" so I can only
      > evaluate academic results by how they impact practice. That seems
      > OK to me, since I believe most academics justify research in the
      > same way.
      >
      > I generally read the academic papers from the major conferences
      > I attend and attempt to figure out how they can help me. Considering
      > only those dealing with agile practices, I find one or two per year that
      > I am able to usefully incorporate in my work. This seems a very low
      > number to me and (for me) calls into question the usefulness of the
      > large effort expended on such research.
      >
      > I agree 100% with you that such work is viewed as useful by those
      > management and customers wanting to "adopt agile." Unfortunately,
      > in the wild, that phrase usually means to require programmers to
      > follow some set of practices. This may not be the intent - I surely
      > hope not - of the researchers, but it's pretty common.
      >
      > For a great example of the exaggeration and misuse of research
      > results, google "Mozart Effect" The original researcher never claimed
      > any effect on babies lasting longer than a quarter hour nor any
      > special benefit of using Mozart over... say... Bob Marley.
      >
      > When management asks me for research, I ask them how they
      > will act differently in the absence of research versus research
      > with positive/negative results. I'm often able to get them to see
      > that they already have enough information to move forward. I
      > recommend this approach to anyone who feels that the lack
      > of research limits their ability to progress.
      >
      > Charlie
      >
      > On Fri, Jul 9, 2010 at 11:52 AM, Steven Gordon <sgordonphd@...> wrote:
      > > On Fri, Jul 9, 2010 at 10:59 AM, Charlie Poole
      > > <charlie@...>wrote:
      > >
      > >>
      > >>
      > >> Hi Steve,
      > >>
      > >> Since we were (or I was) getting away from the main topic, I'll start
      > >> a new thread.
      > >>
      > >> > Research is about proving/supporting or disproving/undermining
      > >> > hypotheses/theories.  Mine was just an example hypothesis that is also
      > >> > related to a hypothesis about what opinions reflect.
      > >>
      > >> Certainly some research is about this. There are other kinds. For example,
      > >> research is done to discover/invent new algorithms, etc. That's not my
      > >> target, however. I'm talking about research that intends to demonstrate
      > >> an hypothesis about agile practice - as I believe you are.
      > >>
      > >> > If you are not interested in any hypotheses, then there is no point in
      > >> doing
      > >> > research or surveys.
      > >> >
      > >> > If the hypotheses you are interested in involves what makes various agile
      > >> > approaches work well (or fail to work well), then after the fact opinions
      > >> > are largely useless.
      > >> >
      > >> > If the hypotheses you are interested in is what makes people like to
      > >> > continue or stop using various agile approaches, regardless of how they
      > >> are
      > >> > actually applying those approaches, then opinions rule.
      > >>
      > >> I think there is a deeper question here beyond simply what one may be
      > >> interested in. I'm interested in lots of things that don't have particular
      > >> value to anyone else. I pursue those things, of course, but don't seek
      > >> to justify them as any more than the pursuit of my own personal interests
      > >>
      > >> What I'm addressing is the putative value of research that seeks to "prove"
      > >> certain ways of working are better than others. Some people seem to find
      > >> this very valuable (which I take to mean useful) to the community. Others
      > >> of us wonder about the value. You haven't said where you stand on the
      > >> question, but my impression is that you do find such work to have value.
      > >> If that's the case, I would ask why - I don't think the answer is obvious.
      > >>
      > >> At XP2010, I attended an interesting panel on the role of academic
      > >> research.
      > >> However, it brought up one disturbing bit of information. One of the
      > >> panelists,
      > >> who happened to be an academic researcher, asked practitioners to deposit
      > >> cards on which they had written questions for which they thought research
      > >> might provide an answer.
      > >>
      > >> Looking at the questions, what struck me was that a very large majority
      > >> of them already had answers, although those answers would not satisfy
      > >> the necessary rigor for proper academic research. That is, the folks who
      > >> wanted to know how to do various things could have sought the answer
      > >> among experienced practitioners. Those answers would be purely
      > >> anecdotal and qualified by YMMVs, but in most cases would have been
      > >> of great practical help. I found it very disturbing that people with enough
      > >> commitment to attend an agile conference were looking for answers that
      > >> many of us could have given them.
      > >>
      > >> That's where I'm coming from in this discussion. I have no doubt that
      > >> research has value, but I see too many folks looking to it for answers
      > >> to questions that can be arrived at much more simply.
      > >>
      > >> I also have a nagging doubt about generalized answers. Since those off
      > >> us working in projects only need particular answers to our particular
      > >> questions, my fear is that those who want generalized answers are the
      > >> folks who want to tell others how to work. That's a BadThing in my view,
      > >> and I dislike encouraging it.
      > >>
      > > Wearing my coach and practitioner hat, I agree that the day-to-day questions
      > > that should matter to practitioners are ones that should really be answered
      > > empirically within the context of the specific project that one would apply
      > > that answer in.  In agile, there are no one-size-fits-all answers, so even
      > > if generalized research were to come up with very specific 80% answers to
      > > some practical questions, the practitioner should at best consider the 80%
      > > answer a starting point from which to adapt based on what happens in their
      > > specific project.
      > >
      > > Most of the requests for research results I see are not from practitioners
      > > from customers/managers seeking evidence to support their desire to become
      > > agile (or to support their fear of it).  I see this as a marketing game that
      > > I am not particularly interested it. I believe that an organization cannot
      > > successfully adopt an agile approach unless the organization truly believes
      > > that their current approach will lead to business failure (otherwise the
      > > change is too painful and the organization will successfully resist even if
      > > upper management claims to be on board).  Once an organization can
      > > acknowledge the severity of their software development problems, then it is
      > > best to make the case based on how agile would address the specific problems
      > > they acknowledge, not on how agile has worked anywhere else.  And then by
      > > proceeding to work on those specific problems in agile ways rather than
      > > big-bang big-agile-up-front.
      > >
      > > Putting on my academic hat, the questions I would like research to be able
      > > to answer is why does agile work?  Maybe, it might provide insights into my
      > > coaching and practice rather than specific answers to specific question.
      > > Maybe, it might help organizations understand how relinquishing control
      > > might actually make things work better.  But, basically, I am just curious
      > > about why agile works so effectively when it is so contrary to intuitive
      > > notions of:
      > > * divide-and-conquer,
      > > * division of labor,
      > > * becoming really, really good at one thing and letting others do what they
      > > are really, really good at,
      > > * measuring twice and cutting once,
      > > etc.
      > >
      > > Steven Gordon
      > >
      > >
      > >
      > >
      > >
      > >>
      > >> Charlie
      > >>
      > >> _,_._,___
      > >>
      > >
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to:   extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
    • Rob Park
      Least Qualified Implementor has a slightly different connotation than least competent developer . :) (Arlo s paper in fact referred to least-qualified
      Message 178 of 178 , Jul 17, 2010
      • 0 Attachment
        "Least Qualified Implementor" has a slightly different connotation than "least
        competent developer". :) (Arlo's paper in fact referred to
        "least-qualified person")


        --
        Rob
        --
        http://agileintention.blogspot.com
        http://twitter.com/robpark
        http://leandog.com


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.