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

Agile Practices - Developer led viral adoption

Expand Messages
  • Dean Margerison
    Hi I have written a paper on the reasons behind the increasing adoption of agile practices and would welcome feedback.
    Message 1 of 4 , Jun 27, 2004
    View Source
    • 0 Attachment
      Hi

      I have written a paper on the reasons behind the increasing adoption
      of agile practices and would welcome feedback.

      http://www.dekam.net/Documents/Agile_Practices-viral_adoption.pdf

      Regards Dean
    • Ken Boucher
      ... Having an accurate figure for downloads and page views should be an indicator of interest but I fail to see how it s an indicator of adoption. All your
      Message 2 of 4 , Jun 27, 2004
      View Source
      • 0 Attachment
        > http://www.dekam.net/Documents/Agile_Practices-viral_adoption.pdf

        Having an accurate figure for downloads and page views should be an
        indicator of interest but I fail to see how it's an indicator of
        adoption. "All your base are belong to us" and "Badger Badger Badger"
        have massive amounts of hits and yet I don't see either of them
        actually changing how we do business.

        I'm also not seeing where adoption is really being led by the
        developers. It's a nice thought, but I'm missing the proof behind
        that conclusion. Since the enviroment that supports pair programming
        is radically different from the standard "cubeville" this is a change
        that does not go unnoticed by management. It's hard to rearrange the
        area for pair programming, get white space for BVCs, move your
        customer onsite, and stop producing the documention required for BDUF
        without someone noticing. And any new process tends to fail unless
        everyone buys into it. Because of that I don't see these processes
        as "developer led". I see them as "whole team led" with everyone,
        including the customer and any management, having a stake in it and
        believing in it. Without that, I see nothing but difficulty and
        unrealistic expectations.

        Don't get me wrong. I like what the paper says. But I don't see any
        supporting evidence that leads to the conclusions presented.
      • Russell Gold
        ... OTOH, there are some practices which can clearly be developer-led; most noticeably test-first, always-on-baseline, frequent-checkin, and refactoring. I had
        Message 3 of 4 , Jun 27, 2004
        View Source
        • 0 Attachment
          On Sun, 27 Jun 2004 21:53:44 -0000, Ken Boucher <yahoo@...> wrote:
          > I'm also not seeing where adoption is really being led by the
          > developers. It's a nice thought, but I'm missing the proof behind
          > that conclusion. Since the enviroment that supports pair programming
          > is radically different from the standard "cubeville" this is a change
          > that does not go unnoticed by management. It's hard to rearrange the
          > area for pair programming, get white space for BVCs, move your
          > customer onsite, and stop producing the documention required for BDUF
          > without someone noticing. And any new process tends to fail unless
          > everyone buys into it. Because of that I don't see these processes
          > as "developer led". I see them as "whole team led" with everyone,
          > including the customer and any management, having a stake in it and
          > believing in it. Without that, I see nothing but difficulty and
          > unrealistic expectations.
          >
          > Don't get me wrong. I like what the paper says. But I don't see any
          > supporting evidence that leads to the conclusions presented.

          OTOH, there are some practices which can clearly be developer-led;
          most noticeably test-first, always-on-baseline, frequent-checkin, and
          refactoring. I had tremenous success introducing these at Bluestone
          -and the result could well be described as viral, as first one small
          workgroup and ultimately significant portions of the developer staff
          adopted them.

          BTW, many cubicle designs can be easily adapted for pair programming.
          All you have to do is persuade your co-workers to reposition their
          computers away from the corner favored by cubicle designers. Most
          cubicles have a long shelf that will accomodate two people
          side-by-side.
        • Dean Margerison
          Hi Ken I suppose my point is that, having such high page views and downloads relating to TOOLS that enable developers to deliver software IS
          Message 4 of 4 , Jul 2, 2004
          View Source
          • 0 Attachment
            Hi Ken

            I suppose my point is that, having such high page views and
            downloads relating to TOOLS that enable developers to deliver
            software IS significant...Downloading ANT,JUnit and Maven is very
            different from visiting sites such as Badger Badger Badger

            Amusing as they are

            The 2 minutes of fun these sites deliver does not really equate to
            the value you can derive from downloading software productivity
            tools.

            Ps coming from Gods county Yorkshire, and a keen football player
            (not soccer), I much prefer the England Badgers at http://www.weebls-
            stuff.com/toons/35/

            Regards Dean







            --- In extremeprogramming@yahoogroups.com, "Ken Boucher"
            <yahoo@n...> wrote:
            > > http://www.dekam.net/Documents/Agile_Practices-viral_adoption.pdf
            >
            > Having an accurate figure for downloads and page views should be
            an
            > indicator of interest but I fail to see how it's an indicator of
            > adoption. "All your base are belong to us" and "Badger Badger
            Badger"
            > have massive amounts of hits and yet I don't see either of them
            > actually changing how we do business.
            >
            > I'm also not seeing where adoption is really being led by the
            > developers. It's a nice thought, but I'm missing the proof behind
            > that conclusion. Since the enviroment that supports pair
            programming
            > is radically different from the standard "cubeville" this is a
            change
            > that does not go unnoticed by management. It's hard to rearrange
            the
            > area for pair programming, get white space for BVCs, move your
            > customer onsite, and stop producing the documention required for
            BDUF
            > without someone noticing. And any new process tends to fail unless
            > everyone buys into it. Because of that I don't see these processes
            > as "developer led". I see them as "whole team led" with everyone,
            > including the customer and any management, having a stake in it
            and
            > believing in it. Without that, I see nothing but difficulty and
            > unrealistic expectations.
            >
            > Don't get me wrong. I like what the paper says. But I don't see
            any
            > supporting evidence that leads to the conclusions presented.
          Your message has been successfully submitted and would be delivered to recipients shortly.