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

R: [scrumdevelopment] RUP vs. Scrum

Expand Messages
  • Adriano Comai
    Mike, ... Yes. This configuration takes place at the organizational level, usually in the form of a customization project, that is driven by company cultural
    Message 1 of 48 , Jul 15 1:32 PM
    • 0 Attachment
      Mike,

      > Da: Mike Beedle
      > Inviato: lunedi 15 luglio 2002 18.04
      >
      > Adriano:
      >
      > But if you want to do RUP-ISO9K, RUP-self-organizing,
      > RUP-CMM5, RUP-XP, etc.; don't you also need a lot of
      > configuration upfront? I don't think you can get
      > away from that upfront stuff in a configurable process
      > framework.

      Yes. This configuration takes place at the organizational level, usually in
      the form of a customization project, that is driven by company cultural
      values, by company needs and constraints. The results, as you know, may be
      (in different companies) very different processes. And it takes some time
      (much more than introducing Scrum, for what I can say), and a lot of
      experience.

      > Yes, I agree with you, in theory, the environment gets
      > changed as needed. I'll even say that in theory, the
      > environment gets tweaked to match the best interests
      > of the configuration you had selected and configured
      > upfront. That will certainly be more agile because
      > it would reflect feedback cycles of:
      >
      > inspection --> adaptation

      At the project level, at the start of the project, the customization (the
      "development case") is usually very quick, but it needs experience, of
      course. And the adaptation of the process, during the whole project, needs
      experience too.

      > However, in practice, and again speaking from my experience,
      > I always see the configuration or RUP up-front and
      > very little or none tweaking thereafter. In fact,
      > very many times companies hire Rational or other
      > consultants to configure RUP for a project or for
      > an organization -- but these resources hardly ever
      > stay throughout the lifecycle of the projects.

      Yes, it happens. The transfer of knowledge related to the process, the
      customization at the organizational level is the "easy" part (even if
      boring, at least for me), the hard part (the critical part) is to help
      projects to be successful. But don't you think the same is true for Scrum
      (or XP)?
      Without _care_ , without the help of someone who knows how to do the things
      that are to be done, it is difficult that new approaches are used in an
      effective and efficient way.
      I have read your posts about self-organization (I've also read the excellent
      book about Scrum you wrote with Ken Schwaber), but I think the right amount
      of experience is needed also to determine what space has to be left to the
      self-organization of the team, which activities have to be self-organized.
      And I think the ability of the coach (Scrum Master) is very critical for the
      building of the team, the relation with the customer, and the success of the
      project.

      > (I don't argue that somebody can and does do it right,
      > i.e. adjust the environment, but I just don't see
      > it in the trenches.)
      >
      > - Mike

      Adriano Comai
      www.analisi-disegno.com
    • 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 9:38 AM
      • 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.