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

RE: [scrumdevelopment] RE: [XP] Re: Agile Rentschian Thinking

Expand Messages
  • Mike Beedle
    Grady: Thanks for the summary of RUP. A good summary certainly clarifies the tons of documentation written on it that sometimes miss the point of expressing
    Message 1 of 48 , Jul 13, 2002

      Thanks for the summary of RUP. A good summary certainly
      clarifies the tons of documentation written on it that
      sometimes miss the point of expressing its essence.

      These are a few statements that summarize my position so far
      from our sometimes heated but respectful and insightful conversation
      over the last couple of days:

      1) Agility always involves "embracing change" and therefore
      requires some level of self-organization

      2) Agile methods are based on agile practices, are simpler
      to implement, and have fewer options to be "configured"

      3) There is agility in RUP, (at least in the way you
      describe it below), but it varies with how RUP is configured

      4) There is a definite difference between Agile Methods,
      which include RUP in different degrees depending on how
      it is configured (specially as you describe it below); and
      striclty Defined-Process methods ("defined process" in
      the sense of purely sequential step-wise activities).

      These are still things that I question:

      1) What are the limits of flavoring that RUP can be
      configured into? i.e. RUP-XP, RUP-CMM5, RUP-ISO9K,
      RUP-self-organizing, etc.

      2) How much effort does it take and how much overhead
      does it take to configure each of these flavors?
      And does this come in the way of agility itself?

      - Mike

      RUP Summary

      Grady Booch wrote:
      > Mike Beedle wrote:
      > > [egb> ] thank you for the advice. are you open to using this
      > > conversation as a crash course in rup concepts, principles,
      > > values, and beliefs?
      > Sure.

      Ok, I'm about to tell you everything you need to know about the RUP...all
      else is simply details.

      First, the essence of the RUP may be expressed in its six best practices.
      These are not an invention, but instead are a reflection of what we've seen
      in working with literally tens of thousands of projects over the past 20
      years, codifying what works in successful organizations and what is
      noticeably absent in unsuccessful ones:

      1. Develop iteratively (every project has a regular rhythm, manifest as a
      series of contiuous, regular releases of executables)

      2. Model visually (we model so that we may better reason about the systems
      we are trying to build; the UML exists as the standard means of visualizing,
      specifying, constructing, and documenting these artifacts of a
      software-intensive system)

      3. Manage requirements (everything is driven by use cases/stories which are
      continuously discovered, refined, and managed in the rhythm of the project,
      and so in turn drive unit and systems test as well as the system's
      architecture and therefore implementation)

      4. Control changes (change is good insofar as it is directed by aggressively
      attacking the risks to success in the system)

      5. Continuously verify quality (test continuously, using the use
      cases/stories as the baseline, and use these tests to measure progress and
      identify risks along the way)

      Use component-based architectures (one grows a system's architecture through
      each iteration; we validate and verify the system's essential architecture
      early on so as to aggressively attack all technical risks and to raise the
      level of abstraction for the rest of the team by explicitly making manifest
      the design patterns/mechanisms and architectural patterns that pervade the

      Second, there are a few implicit practices:

      1. Develop only what is necessary
      2. Focus on valuable results, not on how the results are achieved
      3. Minimize the production of paperwork
      4. Be flexible
      5. Learn from your mistakes
      6. Revisit your risks regularly
      7. Establish objective, measurable criteria for your progress
      8. Automate what is human-intensive, tedious, and error-prone
      9. Use small, empowered teams
      10. Have a plan

      Third, there's some terminology worth noting, so that we level set the
      vocabulary of the process to all stakeholders:

      1. The conduct of a project tends to follow four major phases, the end of
      each which represents an important business gate: inception (when the
      business case for the project is established and the basic boundaries of
      what's in and what's out of that case are drawn; at the end of inception we
      can say "yes, we should do this"), elaboration (gated by the establishment
      of the system's essential use cases and architecture, representing a direct
      attack that confronts the essential technical risks to the system; at the
      end of elaboration we can say "yes, we know we can do this"), construction
      (wherein the system is grown through the successive refinement of the
      system's architecture, along with the continuous discovery of the system's
      desired behavior; at the end of construction we can say "yes, the system is
      in a place where it may be fully deployed to its users" [it may have been
      incrementally deployed during construction, of course]), and finally,
      transition (wherein the business decision is made that aggressive investment
      in the system is no longer necessary, and the system enters a plateau of use
      and maintenance; at the end of transition we can say "this system is at end
      of life")

      2. Since the RUP is about deploying systems for which software is an
      essential element (acknowledging that executables are the essential artifact
      that's produced continuously but that this labor has a business, economic,
      and technological context whose stakeholders contribute), there are several
      disciplines that engage in the development activity: business modeling,
      requirements, analysis and design, implementation, test, deployment,
      configuration and change management, project management, and environment.
      These disciplines represent different stakeholders, different views into the
      system, and different skill sets. Each discipline has its own rhythm, but
      all in harmony with the essential construction rhythm of the project as a

      3. In the conduct of a project, the RUP provides a common vocabulary for
      those things that get created during a project (artifacts), the roles/skill
      sets who create those things (workers) and the concurrent, interweaving
      workflows that those workers typically follow to manipulate those artifacts

      That's all you really need to know...

    • 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.