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

RE: [scrumdevelopment] Digest Number 1533

Expand Messages
  • Jeff Heinen
    In our org our software is developed using scrum, AND our support organization is a scrum team as well. We ve had to come up with some creative ways to deal
    Message 1 of 33 , Aug 1, 2006
    • 0 Attachment
      In our org our software is developed using scrum, AND our support organization is a scrum team as well. We've had to come up with some creative ways to deal with the fact that much of this team's work is interrupt driven, but it is working exceedingly well. One of the big problems we've faced is having to deal with the enormous amount of out-of-date, useless documentation about the product that was generated as a result of our waterfall legacy. Since adopting scrum we've gotten much better at producing *useful* documentation. If it's a business priority, it goes on the backlog. If it's for engineers, they document what's useful for advancing the project and no more.
       
      -Jeff


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Rohilla, Pryank
      Sent: Tuesday, August 01, 2006 8:43 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Digest Number 1533

      Hi,

      I am a developer doing some support work of an agile project. My team mate keep criticising agile methodologies. His points are: Agile is not good for Support as it doesn’t provide proper documentation of developed applications and it’s a pain to support projects developed using agile.

      Can some of you agile gurus point out how Agile helps in doing support of live applications?

      Pryank


      From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com]
      Sent: 30 July 2006 11:51
      To: scrumdevelopment@ yahoogroups. com
      Subject: [scrumdevelopment] Digest Number 1533

      Messages In This Digest (9 Messages)

      Messages

      1a.

      Are SCRUM and XP actually Process Oriented?

      Posted by: "Vickydhiman" vickydhiman@ yahoo.com   vickydhiman

      Sat Jul 29, 2006 2:54 am (PST)

      I understand Agile focuses *more on* interaction and collaboration rather than processes. However, someone recently asked me, is not updating product backlog, having sprint meetings, release planning - all basically a process? It may be a more effective process but it is a process. Do you agree?

      I said its not a process, its a light weight framework and is different from a process. Then he asked me whats the difference between the two. I tried to Google it out with no luck.

      Any thoughts?

      Thanks

      Vicki


      ------------ --------- --------- ---
      Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

      1b.

      Agile 2.0

      Posted by: "Marco Abis" abis@agilemovement. it   capotribu

      Sat Jul 29, 2006 3:04 am (PST)

      Please tell me it's a joke :-)

      Scott Ambler has published some interesting data related to a surveys
      done via Dr. Dobb's Journal. Questions, raw data and summary here
      http://www.ambysoft .com/surveys/

      In the last slide of the summary presentation (ppt) I read: "There
      was a statistical correlation between adoption of "Agile 2.0" methods
      such as Agile Unified Process (AUP) or MSF Agile and adoption of
      Agile Model Driven Development (AMDD)"

      Please please please can we try to avoid such a thing as Agile 2.0?
      And who says that AUP, MSF Agile and AAMD are Agile 2.0? what do
      we/you/they mean by Agile 2.0? I still am not sure AUP and MSF Agile
      are "Agile 1.0"... ;-)

      Marco Abis

      "let's not talk about Type A Scrum unless we also want to talk
      about Type W Scrum, which is more commonly called Waterfall" (Mike Cohn)

      http://www.agilemov ement.it :: Italian Agile Movement

      1c.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "Ron Jeffries" ronjeffries@ acm.org   RonaldEJeffries

      Sat Jul 29, 2006 5:00 am (PST)

      On Saturday, July 29, 2006, at 5:53:26 AM, Vickydhiman wrote:

      > I understand Agile focuses *more on* interaction and collaboration
      > rather than processes. However, someone recently asked me, is not
      > updating product backlog, having sprint meetings, release planning
      > - all basically a process? It may be a more effective process but
      > it is a process. Do you agree?

      > I said its not a process, its a light weight framework and is
      > different from a process. Then he asked me whats the difference
      > between the two. I tried to Google it out with no luck.

      > Any thoughts?

      It's a process. A process is "what you do". Everyone has a process.

      As you point out, the manifesto says "this OVER that", not "this
      INSTEAD OF that", and we said it that way, and emphasized it, on
      purpose. In that line we had in mind that we will need good
      processes and good tools. But what we need most is good people
      working well together.

      Ron Jeffries
      www.XProgramming. com
      I'm giving the best advice I have. You get to decide whether it's true for you.

      1d.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "Steven Gordon" sgordonphd@gmail. com   sfman2k

      Sat Jul 29, 2006 5:17 am (PST)

      The agile approaches are empirical or adaptive processes as opposed to
      defined or deterministic processes.

      The difference is that agile processes are less rigid and driven by
      principles rather than perscription. This allows teams to adapt the
      process to context, which in turn allows the process to be more
      concise and lightweight (because the process does not have to
      explicitly cover every contingency) .

      On 7/29/06, Vickydhiman <vickydhiman@ yahoo.com> wrote:
      >
      >
      >
      >
      >
      >
      > I understand Agile focuses *more on* interaction and collaboration rather
      > than processes. However, someone recently asked me, is not updating product
      > backlog, having sprint meetings, release planning - all basically a process?
      > It may be a more effective process but it is a process. Do you agree?
      >
      > I said its not a process, its a light weight framework and is different from
      > a process. Then he asked me whats the difference between the two. I tried to
      > Google it out with no luck.
      >
      > Any thoughts?
      >
      > Thanks
      >
      > Vicki
      >
      >
      > ____________ _________ _________ __
      > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
      > countries) for 2¢/min or less.
      >
      >
      >
      >

      1e.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "Vickydhiman" vickydhiman@ yahoo.com   vickydhiman

      Sat Jul 29, 2006 5:30 am (PST)

      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.

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

      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] but I guess it also focusses on the same BUT it also focusses on whole lot other things. Is that the main difference?

      Thanks

      Vicki

      Steven Gordon <sgordonphd@gmail. com> wrote: The agile approaches are empirical or adaptive processes as opposed to
      defined or deterministic processes.

      The difference is that agile processes are less rigid and driven by
      principles rather than perscription. This allows teams to adapt the
      process to context, which in turn allows the process to be more
      concise and lightweight (because the process does not have to
      explicitly cover every contingency) .

      On 7/29/06, Vickydhiman <vickydhiman@ yahoo.com> wrote:
      >
      >
      >
      >
      >
      >
      > I understand Agile focuses *more on* interaction and collaboration rather
      > than processes. However, someone recently asked me, is not updating product
      > backlog, having sprint meetings, release planning - all basically a process?
      > It may be a more effective process but it is a process. Do you agree?
      >
      > I said its not a process, its a light weight framework and is different from
      > a process. Then he asked me whats the difference between the two. I tried to
      > Google it out with no luck.
      >
      > Any thoughts?
      >
      > Thanks
      >
      > Vicki
      >
      >
      > ____________ _________ _________ __
      > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
      > countries) for 2¢/min or less.
      >
      >
      >
      >





      ------------ --------- --------- ---
      Yahoo! Music Unlimited - Access over 1 million songs.Try it free.

      1f.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "Ilja Preuss" it@iljapreuss. de   ipreussde

      Sat Jul 29, 2006 5:46 am (PST)

      To me the difference is that for an Agile time, the process is there to
      serve the people - in contrast to the people being there to execute a
      prescribed process.

      If a team finds that some Scrum (or XP, Crystal, etc.) practice isn't
      helping them, they are supposed to stop doing it (or, if they are new to
      it, preferably try to find out whether they could make it work by doing
      it differently) .

      Cheers, Ilja

      1g.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "PaulOldfield1@ aol.com" PaulOldfield1@ aol.com   pauloldfield1

      Sat Jul 29, 2006 6:15 am (PST)

      (responding to Vicki)

      I'll attempt an answer, hope it gives more light than obfuscation. ..

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

      A framework is something on which we select and hang good practices.
      A framework with a set of practices is a process. In building a
      framework we almost certainly have to identify some practices as
      'best'. i.e. each instantiation of the framework will include these
      practices because they are part of the framework.

      For example, the RUP framework is Risk driven (a 'best' practice in
      RUP). As a result it comes with 4 out-of-the-box phases that
      focus on specific types of risk, in sequence. It comes with a
      vast array pf practices that we may choose to adopt, omit or
      modify. Unfortunately all too many folk try to adopt the lot and
      end up with more process than product. These 4 phases are also
      a good practice - in theory they can be added to or modified,
      but the practice is so good that few RUP projects change them.
      In reality, people who know better in this respect would not choose
      to do RUP.


      For example? A really agile team may knock off the risks to
      be addressed in RUP's Inception and Elaboration phases well
      within the first 2 weeks, so the overhead of doing these phases
      formally is not warranted.

      Bear in mind these are opinions, feel free to differ.

      Paul Oldfield

      1h.

      Re: Are SCRUM and XP actually Process Oriented?

      Posted by: "Ron Jeffries" ronjeffries@ acm.org   RonaldEJeffries

      Sat Jul 29, 2006 8:30 am (PST)

      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
      www.XProgramming. com
      In programming, do, or undo. There is always try. --Yoda

      2.

      Re: [XP] Agile 2.0

      Posted by: "Ron Jeffries" ronjeffries@ acm.org   RonaldEJeffries

      Sat Jul 29, 2006 5:35 pm (PST)

      Hello, Marco,

      On Saturday, July 29, 2006, at 6:45:04 AM, you wrote:

      > [rant]
      > Please tell me it's a joke. Scott W. Ambler has published some very
      > interesting data related to a surveys done via Dr. Dobb's Journal.
      > Questions, raw data and summary can be found at
      > http://www.ambysoft .com/surveys/

      It's certainly not a joke, and I see the results as generally very
      favorable toward Agile, especially XP and Scrum.

      > In the last slide of the summary presentation (ppt) I read: "There was a
      > statistical correlation between adoption of "Agile 2.0" methods such as
      > Agile Unified Process (AUP) or MSF Agile and adoption of Agile Model
      > Driven Development (AMDD)"

      Well, there was apparently a correlation. About 5 percent of
      respondents reported using those, um, approaches. How many were used
      together isn't clear from what we seen in the data now.

      > Please please please can we try to avoid such a thing as Agile 2.0? And
      > who says that AUP and MSF Agile are Agile 2.0? what do we/you/they mean by
      > Agile 2.0? I still am not sure AUP and MSF Agile are "Agile 1.0"...
      > [/rant]

      Yes. Scott has been pushing his approach hard, in every conceivable
      forum. It has achieved some penetration. I would be very interested
      to see the correlation between the various methods and the levels of
      satisfaction, quality, and so on. Perhaps the upcoming article[s]
      will address that.

      The notion of "Agile 2.0" is, in my opinion, odious in the
      "extreme". There are a lot of people out there pushing Agile, there
      are lots of training courses, lots of consultants, lots of new
      entrants into the market, many of whom cannot trace their
      participation to anyone in the original Agile lineage. That troubles
      me a bit.

      I continue to see individuals and organizations saying that they're
      Agile without even getting close to what "Agile 1.0" suggests.
      Adding more modeling, and adding more process elements, will not
      improve this situation. People ought to learn to do Agile 1.0 before
      worrying much about what's next. There's plenty there to learn.

      It's all part of "crossing the chasm", I reckon. Everything gets
      watered down.

      Ron Jeffries
      www.XProgramming. com
      Keep away from people who try to belittle your ambitions. Small people
      always do that, but the really great make you feel that you, too, can
      become great." -- Mark Twain.

      Recent Activity

      ·                        31

      Visit Your Group

      SPONSORED LINKS

      §                       Scrum

      New web site?

      Drive traffic now.

      Get your business

      on Yahoo! search.

      Yahoo! Groups

      Start a group

      in 3 easy steps.

      Connect with others.

      Y! Toolbar

      Get it Free!

      easy 1-click access

      to your groups.

      Need to Reply?

      Click one of the "Reply" links to respond to a specific message in the Daily Digest.

    • Steven Gordon
      ... Because, keeping information in more than one place is fundamentally flawed. Keeping documentation in synch with something else is a big waste of
      Message 33 of 33 , Aug 4, 2006
      • 0 Attachment
        On 8/4/06, David H. <dmalloc@...> wrote:
        >
        > On 04/08/06, Steven Gordon <sgordonphd@...> wrote:
        > > On 8/3/06, David H. <dmalloc@...> wrote:
        > > >
        > > > And as mentioned here before, in such situations go revisit DITA
        > >
        > > DITA? Would that be "Darwin Information Typing Architecture"?
        > >
        > > If so, I do not believe any single predefined information meta-model
        > > can be appropriate for all projects (unless you melt down to trivially
        > > atomic knowledge representations like ER). Even if it was, I do not
        > > see how it would solve the problem of static information inevitably
        > > getting stale and being a poor substitute for timely communication and
        > > collaborative feedback.
        > >
        > What is "static information" ?
        > Every piece of documentation is as alive as you keep it.
        > Now if every story develops a task that reads "keep documentation in
        > sync" or whatever you call it, PLUS the fact that you can
        > auto-generate a hell of a lot of documentation, I do not quite see why
        > this picture of big monolithinc, static documents is dso prevelant?
        >

        Because, keeping information in more than one place is fundamentally
        flawed. Keeping documentation in synch with something else is a big
        waste of resources. In practice, you get:
        1. Resistance to change because the cost of change is at least double, or
        2. Documentation not kept up to date when the going gets tough, or
        3. Both (the usual case).

        Of course, autogeneration is a fine option (although I do not
        understand why DITA would be a more useful format than UML). Better
        yet is expressive, readable test code that specifies what each
        component/class of the system does in a verifiable manner (so that you
        know when either the spec or the system is wrong).

        >
        > > Yes, it is important that the domain model in the head of every
        > > project member is compatible, but codifying it formally does not
        > > guarantee that mental models agree nor does it solve the major issues
        > > involved with communication, mutual understanding, and ramping up new
        > > people.
        >
        > Ramping up people costs money. I appreciate that this is a necessity
        > in any project under any methodology, but written documentation is
        > passive and can be cosumed any time, any where. Ramping someone up
        > through communication and interaction will most likely produce better
        > results because there is an immideate feedback loop, but it costs a
        > lot more money.
        > If you can combine both approaches I would argue that you get
        > excellent results, no?

        You get what you pay for. I have found passive measures, while
        consumable at any time, are an ineffective way to communicate and
        learn. And it also costs resources to produce and especially maintain
        those documents.

        I know personally, that if you pair me with the individuals on any
        team in any technology in any domain while they are doing the work
        they would normally be doing, I will learn much more effectively than
        by sitting in a cube by myself reading. Furthermore, I would be
        contributing value to the team from day, if only by questioning code
        and practices that the team has gotten into the habit of doing without
        thinking about why.

        At least in my case, it costs more for an organization to pay me to
        read documents because pairing returns immediate value and trains me
        up faster. I do not think I am unusual among professional software
        developers.

        Steve

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