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

RE: [XP] Re: Agile Rentschian Thinking

Expand Messages
  • Mike Beedle
    ... better ... basic of ... levels of ... Grady: (Thanks for your response when I wrote the first Agile Software Development Revolution and Agile Rentschian
    Message 1 of 48 , Jul 11, 2002
      Grady Booch wrote:
      > [egb> ] This reality of the breadth of software is what tempers a
      > lot of my comments about process in this forum. Fundamentally, building
      > software faster is hard. No one size fits all - there are just so
      > many kinds of domains and development cultures out there. My goodness, we
      > as an industry can't even agree upon a common vocabulary for the most
      basic of
      > things like "requirement" or "architecture" or "component" (take a look at
      > what the SWEBOK did and didn't achieve). That being said, I therefore rant
      > against any radical claims of revolution in this space from any
      > source. The entire history of software engineering is one of raising
      levels of
      > abstraction - but what primarily limits us as an industry from building
      > great software is not this technical dimension, but the human one.


      (Thanks for your response when I wrote the first "Agile Software Development
      Revolution" and "Agile Rentschian articles, this is the kind of discussions
      that I had in mind, but serendipity took us to coffee spills, sex, and
      "dirty politics". Fun threads, btw. :-)

      Here are some comments.

      1) No size fits all. I agree that even including the space of
      Agile Software Development "no size fits all". Defined-process methods
      cope with this problem by adding more processes, more artifacts, more
      roles and hierarchy and more tools.

      And agile methods follow the same trend, we add more, except we add
      more Agile practices instead of more processes, artifacts, etc.. In
      Agile methods, we believe _practices_, which are really patterns
      in most cases, generate the processes. We see process as a second
      order effect.

      Let me give you an example of how different agile practices apply to
      different team sizes, in teams of 3-5 or above, Pair Programming applies;
      but in projects of hundreds or even thousands of developers or above,
      practices like Scrum of Scrums, or like the Shared Resources team that
      I describe in XBreed apply. (A multi-project agile method that fuses
      Scrum, XP and Reusability, Alexanderian and Open Source ideas, which
      main goal is to scale agile methods.)

      So there is an agile adjustment for size: we use more generative
      agile practices.

      2) Building Software faster. There are many core Agile Practices
      that deal directly with "developing software faster". For example:

      * hiring top talent,
      * practicing test driven development,
      * constantly getting feedback from the customer,
      * minimizing excessive documentation or generating it faster
      * avoiding an assembly line process that creates dependencies
      on finished products like plans, requirements and architecture.

      In general, Agile methods, adjust quality, size, scope and schedule
      by making adjustments on agile practices, and accepting that there
      are bounds on what can be controlled.

      3) Agile Revolution or not?. However, even though there may be
      adjustments agile practices there is a fundamental difference in
      doing Agile Development. The different is so pervasive that I
      think it deserves by its own merits to be granted at least the
      possibility of being a true paradigm shift. But only time
      will tell. In fact, Kuhn reminds us that the success of a
      paradigm shift and a revolution is typically guided by
      many factors including strong personalities. (In this case
      we beg your endorsement.... )

      I believe that this paradigm shift is rooted at its very core in
      self-organization, because this is the essence or the difference.

      This is the generative quality that leads to many other things like:

      1. Management pyramid is inverted
      2. Greater Liberty and Freedom to accomplish the task at hand
      3. Constant Learning, Knowledge Creation and Knowledge Sharing
      4. A More Enjoyable and Humane Work Environment
      5. A Hyper-productive Cooperative Work Mode
      6. Emergent Planning, Architecture and Requirements
      7. New values that generate a cooperative culture
      8. The Quality of Life

      More on this at: http://c2.com/cgi-bin/wiki?AgileRevolution

      Grady Booch wrote:
      > [egb> ] I find it telling to note that, if you look at some of
      > the hard core methodologists from the previous and contemporary
      > generations of analysis and design methods - Ed Yourdon, Larry
      > Tom DeMarco, Kent, myself, and others - virtually all of that group
      > have morphed to confronting the human issue of development. That's not
      > to say that tools and methods are irrelevant - they can amplify human
      > ability, eliminate errors, help us better reason about complex things -
      > rather, it's the social dynamics among individuals, within small teams,
      > and among teams of teams that are deeply critical in pushing out
      > great software.

      Here I agree completely. In fact the Agile Manifesto is very clearly
      in saying that:

      We are uncovering better ways of developing
      software by doing it and helping others do it.
      Through this work we have come to value:

      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan

      That is, while there is value in the items on
      the right, we value the items on the left more.

      The operative memes being "we have come to value" and "over",

      - Mike
    • Laurent Bossavit
      ... Controlled by whom ? Aye, there s the rub. ... Agreed. Here and now, given our skill and knowledge, it would be stupid. Do remember, though, that fairly
      Message 48 of 48 , Jul 25, 2002
        > As such, any meaningful method has to "embrace change" but perhaps
        > where we differ is that I would add "and do so in a controlled manner."

        Controlled by whom ? Aye, there's the rub.

        > if you are building a high rise, it would be infinitely stupid to start
        > with a pile of lumber and some hand tools and expect to be successful.

        Agreed. Here and now, given our skill and knowledge, it would be
        stupid. Do remember, though, that fairly simple biological organisms
        routinely build, with their bare appendages, constructions which are
        to them as a highrise is to us. Termites. Wasps.

        Conclusion : it is not stupid to expect that we might *develop* the
        knowledge and skill to build a highrise starting with a pile of
        lumber and some hand tools.

        Now. Metaphor is nice, but we are not, in fact, building highrises.
        We are building software, a different kind of thing. What transposes
        there from the metaphor, and what doesn't ?

        > To be clear as well, I have problems with the pseudoscientific sound
        > bites in your statement: "embracing change" strikes me too much like
        > the pop business edits of the 80's and 90's. I mean, what's the
        > alternative? "I'm a Luddite."

        I don't see where you get that. Could be a language problem - as a
        freakin' furriner I always double-check this kind of thing.

        Dictionary.com says : "embrace, to take up willingly or eagerly", or
        more interestingly, "to avail oneself of". Thus the alternatives are:
        "to accept change reluctantly", or even "not to avail oneself of the
        possibilities offered by change". Which is where you're leading with
        your "embrace change in a controlled manner".

        Dictionary.com says Luddite is "One who opposes technical or
        technological change". I think one could legitimately oppose some
        kinds of technical change - human cloning is routinely opposed by
        some people who, perhaps, might object to being labeled Luddites.

        I definitely don't think "embrace change" is vacuous. On the
        contrary, reading some Roberto Unger, who in the domain of social
        science says the same thing under the slogan "Plasticity into Power",
        I found more content in the position than I would have expected from
        a principle of software development.


        The greatest obstacle to transforming the world is that we lack the
        clarity and imagination to conceive that it could be different.
        Roberto Mangabeira Unger
      Your message has been successfully submitted and would be delivered to recipients shortly.