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

Re: [scrumdevelopment] Are SCRUM and XP actually Process Oriented?

Expand Messages
  • Ron Jeffries
    ... Vicky, I don t think that s key at all. I think that what s key is what the people actually /do/. ... Rigid? You know people who call that rigid? What are
    Message 1 of 41 , Jul 29, 2006
      On Saturday, July 29, 2006, at 8:30:23 AM, Vickydhiman wrote:

      > Interesting comments from Steven and Ron. I am not sure if I have "THE" answer.

      > I might be wrong but the key is to define what is difference
      > between process and framework. Probably a very loose version if
      > the a very light weight process which is based more on principles
      > then set amount of dos and donts is a framework. Or probably
      > framework is collection of some best practices.

      Vicky, I don't think that's key at all. I think that what's key is
      what the people actually /do/.

      > However, some people in my team find SCRUM is rigid where it wants
      > to be [daily meetings, release planning, product backlog et al].

      Rigid? You know people who call that rigid? What are they doing now,
      coming in to work if and when they feel like it? ;->

      > Another possible version is that Agile focusses on processes that
      > facilitate communication and collaboration in the team and with
      > the customer. I am not very familiar with RUP [I think frequent
      > delivery/ daily meetings/ transparency/ debunking processions/ TDD
      > can be achieved with RUP as well]

      Of these, frequent delivery, for some use of the word "frequent", is
      important in RUP. The others are not terms I generally read in the
      RUP literature. But RUP isn't even a process, if we must use the
      word. RUP is a "process framework". That is, it's a big laundry list
      of ideas that all hang together in a reasonable-seeming pattern.

      > but I guess it also focusses on
      > the same BUT it also focusses on whole lot other things. Is that
      > the main difference?

      I think I'd advise not worrying much about differentiating Agile vs
      anything, or process vs framework. I'd advise learning what Agile
      teaches, what the key practices are, and so on. And having learned
      what they are, I'd advising trying them.

      What matters isn't the headings on the folders in our filing
      cabinet: what matters is what we do with the materials in there.

      Ron Jeffries
      In programming, do, or undo. There is always try. --Yoda
    • Mike Beedle
      ... Giora, Good points.... but, there is also a valid point in highlighting that the basic Agile single-project techniques DO NOT satisfy the requirements of
      Message 41 of 41 , Aug 10, 2006
        --- In scrumdevelopment@yahoogroups.com, "gioramorein" <gmorein@...>

        > So maybe when we hear these offensive terms like "New Agile",
        > "Enterprise Agile" or "Agile 2.0" we consider that they may not refer
        > to a change in Agile itself, but rather a change in who and where it
        > is being used.
        > Giora Morein
        > gmorein@...


        Good points.... but, there is also a valid point in highlighting
        that the basic Agile single-project techniques DO NOT satisfy
        the requirements of enterprise development, and that there are
        also "advanced agile techniques", not necessarily included in
        Scrum (Agile == Scrum 1.0, XP == cheap copy of Scrum without credit,
        other methods sorry but NOT Agile enough). [NOTE to Ron: Please
        send your standard insults in direct messages to me, and don't waste
        the group's bandwith.]

        For example, from the enteprise perspective, 1) Super-sprints
        that include simultanous testing and release of multiple applications
        with reusable functionality across different projects (each with their
        own Scrum), and from the "advanced agile techniques" side
        2) structured "green hat" sessions, to compare alternative designs
        in a single project; are good exmaples of these enterprise
        or advanced agile techniques. Other examples are the late
        contributions from Jeff Sutherland, and the many unexploited
        managment and social techniques derived from agent technologies.

        But all this is well known among Scrum practitioners:

        We are not done with Agile...
        We need more for the enterprise, and
        We can improve even the single project techniques

        However, what the skeptics and anti-brandists confuse, is the fact
        that some of us, that for lack of better words I am going to call
        the "enterprise or advance agile developers", have found over time
        some techniques that apply to managing multiple project
        simultaneously, or more techniques to manage individual projects.

        But for those contributions we get the privilege to be
        insulted as "brandists", "opportunists", or worse.

        We need to "open our minds" and continue to let innovation take
        place. We need to stop the overzealous restrain of creativity
        and open ourselves to NEW and IMPROVED ideas (yes, while giving
        FULL credit to everthing done in the past!!!)

        Until then, we will continue to dwell in mediocrity, bashing
        and restraining people accusing them of things like:

        * it has been done before -- let us find NEW and OLD patterns!
        * you are branding! (who cares if they brand! Let them try
        new things and follow the course of adaptation)

        Change is the only constant... Agile 1.0, or 2.0 or 3.0,
        cannot be constant, or cannot be just "one way"...
        we thrive in diversity, in cooperation but also in competition.

        End of rant,

        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.