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

RE: [XP] Re: Agile Rentschian Thinking

Expand Messages
  • Mike Beedle
    ... ceases to ... Grady: (A meta note, please don t read this as if I acting defensively. I am calm, relaxed and friendly. Any other interpretation is purely
    Message 1 of 48 , Jul 11, 2002
    • 0 Attachment
      Grady Booch wrote:
      > > I disagree.
      >
      > [egb> ] Mike, you've missed my point. Are self-organizing systems fragile?
      > Yes...take a look at any of the references I offered up - that's the
      > conclusion of lots of researchers who look for organization on the edge of
      > chaos: achieving sustainable, emergent behavior that comes from
      > self-organization requires a delicate combination of context plus
      > sufficient and necessary rules to reach a point of stability. Change any
      > of those initial conditions or rules and the desired emergent behavior
      ceases to
      > exhibit itself. Hawking and others have pointed out in a similar vein that
      > if one were to tweak any of the universal constants, the world as we
      > experience it would simply not be (that's not to say that another kind of
      > universe would not exist, but we as we are here and now would not
      > be present to experience it).


      Grady:

      (A meta note, please don't read this as if I acting defensively. I am
      calm, relaxed and friendly. Any other interpretation is purely in
      the imagination of the reader.)

      I am very familiar with the references -- only too well, and many more.
      Have you read any of the works Kauffman, Holland, Prigogine, Axelrod,
      Axtell, Gessler, etc.?

      My experience with complex systems started in 1986. In my previous
      life as a Physicist I studied the fractal dimension of the cross
      section of speckled laser beams, nonlinear dynamics, and
      since I have had many research inroads with Complexity Science.

      However, I don't agree with the general conclusion that "lots of
      researchers"
      say that self-organization is fragile.

      Our bodies and our mind are self-organized. Are they fragile?
      Ecosystems are self-organized. Are they fragile?

      No, I don't think, they are pervasive and resilient.

      Self-organization is the quality of life itself. And life is
      not all that fragile. If it was, you and I wouldn't be here
      arguing about it.

      So I didn't miss your point. I insist:

      I disagree, I don't think self-organization is fragile
      and I disagree that the general conclusion of "lots of researchers"
      is that self-organization is fragile.

      Can you enlighten us with specific references?


      Grady Booch wrote:
      > [egb> ] Does Scrum offer value that derives from its self-organization
      > principles? That's an entirely orthogonal issue, and I did not
      > then nor am I now arguing that point. I do not deny that
      > self-organization is possible or that it can lead to emergent behavior.
      > The point of my message was simply that doing so via self-organization
      > alone <is> a delicate thing.


      I disagree. It is not such a "delicate" thing as you think it is.

      It is in fact a strength. When a defined process is failing, you need
      a process improvement team to come and fix it, when a self-organized team
      is failing, it is much easier to fix it, because self-organization
      allows rapid reconfiguration and it heals itself much faster than
      by "external intervention".


      Grady Booch wrote:
      > > Have you ever run an XP or a Scrum project, btw? You would know if
      > > you had.
      >
      > [egb> ] Gosh, but if Scrum relies on self-organization, why do you need
      > anyone to run such a project at all? :-)


      By "running a project" I mean if you have ever participated, sponsored
      or coached an XP or a Scrum project.


      Grady Booch wrote:
      > [egb> ] Have I "run" an XP project? When I was cutting Smalltalk code some
      > years ago, I was doing what we now would probably identify as XP. I had a
      > pair programmer; we created tests first; we continuously integrated a
      > running system; we had the customer on side for much of the time. I don't
      > cut as much code today, but I do consult/mentor a handful of projects that
      > are trying to apply XP to much bigger things.

      Did it feel to you that you needed to have all the extra baggage of
      RUP in those days, or was it sufficient that you could produce lots
      of quality software in a short amount of time while you were having
      fun?


      Grady Booch wrote:
      > > The Agile Manifesto simply contains a summary of the agile principles
      > > 17 guys could articulate in 2 days. It is a good start, but do not
      > > reflect all of the rules, values, practices, patterns, and principles,
      > > that are embedded into each of the agile methods.
      >
      > [egb> ] The problem with any movements that re driven by strong, unique,
      > gifted individuals with special insight is that they are hard to replicate
      > because they rely upon lots of hidden rules, values, practices, patterns,
      > and principles that are locked up in the heads of their creators.

      The hidden rules, values, practices, patterns and principles are now
      _explicit_ in the large collection of agile software development books
      and articles.

      I forgot, how many Agile books there now? Over 20.

      This knowledge is very explicit. In fact, soon there might be more
      Agile books than RUP books. (Agile books tend to be thinner and to
      the point, btw.)


      Grady Booch wrote:
      > I would venture to say that the growth of Scrum, as you vision it,
      > will be limited in its expanse to the degree that you can personally
      > carry that message to the world. That's why publicly articulating
      > all those rules etc is essential
      > - and the very act of trying to articulate those things will force any
      > agilest doing so to be very precise and complete. Some may complain about
      > the size of the RUP compared to some of the agile stuff, but a) just like
      > the Agile Manifesto, the basic spirit of the RUP can be shown in
      > one or two
      > PowerPoint slides and b) everything else there is just details
      > (the RUP just
      > makes those details manifest).

      I agree with most of what you say, but of course it would help
      if Scrum would have a multi-billion dollar marketing machine behind it :-)


      Grady Booch wrote:
      > [egb> ] By the way, since you asked and I replied, have you ever been a
      > project manager for a RUP project?


      No, I have not. And I wouldn't accept the role anyhow.

      They typically call us when RUP has already failed. I can give you a
      an example of how that happened.

      In 1999, I was called to "save" a RUP based project. In the words of
      the project manager, there was lot of activity but they didn't have
      any software to show for. We installed a Scrum process, and within a
      month we had an executable.

      Alto her, I must have saved at least 5 other RUP-based projects since that
      time.


      Grady Booch wrote:
      > > Grady Booch wrote:
      > > > [egb> ] With regard to having the right set of initial
      > > > conditions, this is a hard one, for processes, like the parable of
      > > > the seeds, sometimes fall on hard ground and fail to flourish...that's
      > > > not a fault of the process, but a consequence of the culture into
      > > > which that process is injected.
      > >
      > > Sounds like a "process" crisis to me, in the sense that you are trying
      > > to control through process things that are above and beyond its
      > > capability.
      >
      > [egb> ] You've missed my point again. No process will change initial
      > conditions (e.g. I've got a pile of mainframe programmers I'm
      > trying to drag into the world of the Web; I have to use platform X;
      > I have to contend with legacy code Y; the executives of my company
      > are clueless as to their ability to manage software; the code
      > warriors of my company are clueless to anything beyond coding
      > their way out of every problem). These are all aspects of a
      > development culture, and no matter what process you use, you must
      > take these initial conditions into account, for you cannot alter them.

      No, I didn't. I meant exactly work by word of what I said.

      Let me explain my rationale.

      You argue above that there need to be special conditions for a process to
      flourish as you quote the "parable of the seeds".

      My point is that given any initial conditions, expecting a process
      to flourish or not, might be irrelevant. Because in fact the
      best way to proceed may not be by "installing" or "forcing" a process
      given any of the initial conditions.

      Talk to Linda Rising. She can give you some examples where teams which
      members wouldn't even talk to each other, magically started sharing
      ideas and knowledge, and eventually produced running software using
      Scrum.

      And talk to Ken Schwaber, Jeff Sutherland, Martine Devos, Mike Cohn,
      Yonat Shareon, etc. There are thousands of Scrum projects world-wide.

      Each an every one of them, including myself, has had experiences
      where the "initial conditions" were not favorable, and yet despite
      this disadvantage we were able to produce working software.

      But it didn't happen by installing a process. That's my
      argument for saying that it is a "process crisis", because maybe
      more process, or waiting for the "right conditions" for a process
      is not the answer.


      Grady Booch wrote:
      > > Grady Booch wrote:
      > > > [egb >] Finally, self-organization takes time and energy. Systems that
      > > > operate within the laws of physics self-organize in relative
      > real time;
      > > > systems that operate within the laws of chemical interactions
      > take a bit
      > > > more time; systems that operate within the laws of biology take a
      > > > long time (evolution); systems that operate within the laws of human
      > > > psychology take a wide range of time (social interactions at
      > > > a cocktail party versus global cultural trends). Agilism, IMO,
      > > > operates at the speed of human interaction.
      > >
      > > It works in practice. If you ran Scrum or XP projects you would know.
      >
      > [egb> ] Mike, you've missed my point again, and are becoming unnecessarily
      > defensive in a manner that makes it counterproductive to understanding.

      I don't feel particularly defensive. But sounds to me like you are
      using derogatory and accusatory tactics.

      If you notice, I have not used any derogatory or accusatory tactics on you:

      so please return the favor.

      Anyhow, I would argue that self-organization takes a lot less energy,
      for example, the installation of Scrum is a lot simpler and less
      energy demanding than the installation of RUP.

      Btw, how is stating that "it works in practice" defensive? I am merely
      stating my experience.


      Grady Booch wrote:
      > I did not say that Scrum et al does not work in practice. My point here is
      > that self-organization is not an instantaneous event, but that it requires
      > some amount of time to reach a point of stability. The best kinds of such
      > systems are additionally resilient, meaning that they self-reorganize in
      the
      > presence of external forces. That reorganization also is a non-zero time
      > activity. That's all I'm saying.

      Well, here we agree. Scrum does take some time to jell. But typically
      is in the order of a few weeks. Even the most pernicious teams jell
      within 4-6 weeks. And this is the incubation period where the team needs
      the most coaching. After that, the coach or Scrum master just makes sure,
      that the team is going well. However, that still takes a lot less time,
      and it is a lot less expensive than what an instance of RUP takes to
      install.


      Grady Booch wrote:
      > > I disagree on two counts: a) it doesn't feel fragile in
      > practice, and b) the agile principles are not the only thing at play.
      >
      > [egb> ] I absolutely accept that it does not feel fragile in practice to
      > you; similarly, a properly executed RUP project has been, in my
      > experience, a very resilient thing that helps teams create great software.

      This is contrary to my experience, but well, at least we are
      comfortable in our habitats.


      Grady Booch wrote:
      > [egb> ] As for point b, so, enlighten us: what are those other things that
      > are at play? This group exists for all of us to learn and share.


      I didn't mean anything mystical or important, just the specific
      practices, values, patterns and rules of a given agile method,

      - Mike

      http://www.livingmetaphor.org
    • 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
      • 0 Attachment
        > 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.

        Cheers,

        -[Morendil]-
        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.