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

Re: [XP] summary of the disscusion

Expand Messages
  • Steven Gordon
    Zaidoun , The objective is to do what works best in each particular project context. The ultimately responsibility is to deliver value, not to blindly follow
    Message 1 of 11 , Nov 6, 2009
      Zaidoun ,

      The objective is to do what works best in each particular project context.
      The ultimately responsibility is to deliver value, not to blindly follow XP
      (or any other process).

      If your context requires more permanent documentation than typical XP
      projects, who are we to say that is necessarily wrong (although it might
      be). I am only saying that it being the case in your context does not mean
      that all other XP projects also need more permanent documentation, so we
      resist changing XP itself.

      I like to think of all agile processes as just the starting point for a
      project. Reflection and adaptation to context and feedback means each
      team's process will change a bit over time. This is good, but these
      adaptations do not change the starting points for other teams.

      We like to hear about adaptations that have proved sucessful, but those
      individual adaptations do not change XP itself.

      Steve


      On Thu, Nov 5, 2009 at 11:03 PM, zdnfa <zdnfa@...> wrote:

      >
      >
      >
      > Dear all,
      >
      > After a couple of discussions on documentation and knowledge sharing in XP
      > I would like to summerize what I understood, and would like to see your
      > comments on the ideas presented
      > Your comments on the ideas I presented were as follows:
      >
      > � Size of the project: all the posts suggested that 10 programmers are
      > enough to do any project disregard to the project size (See what curtis
      > cooley in this regard as an example).
      >
      > � XP process: all the posts suggested that no modifications should be
      > introduced to XP's lifecycle, no matter the context is. If the current
      > lifecycle is not fit, we can use Crystal (ron's suggestion). The only
      > exception to that is what Kent said (" the process you are processing looks
      > reasonable to me�..it enhances accountability and responsibility") if I
      > understood him correctly. This means that if we use all principles of XP and
      > modify the lifecycle then this is not XP. Jon spoke also of the purity of
      > XP. Use of analysis phase was also rejected. The term pair development is
      > accepted and considered a more explanative than pair programming.
      >
      > � Tacit Vs. explicit knowledge: almost everyone in this discussion
      > emphasized the importance of tacit knowledge sharing. Code and test cases
      > are the used forms of explicit knowledge. Fear of miscommunication through
      > documentation, the burden of their creation and maintenance, and usefulness
      > lead to resistance of documents as a knowledge sharing tool. Exception to
      > that are the posts in documentation and designing post, where some
      > encouraged the use of 'light ' models and documents such as ERD and Use
      > Cases.
      >
      > Looking forward to see your comments
      > Regards
      > Zaidoun
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Ron Jeffries
      Hello, zdnfa. On Friday, November 6, 2009, at 1:03:47 AM, you ... All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did. ... What was said that XP
      Message 2 of 11 , Nov 6, 2009
        Hello, zdnfa. On Friday, November 6, 2009, at 1:03:47 AM, you
        wrote:

        > After a couple of discussions on documentation and knowledge
        > sharing in XP I would like to summerize what I understood, and
        > would like to see your comments on the ideas presented
        > Your comments on the ideas I presented were as follows:

        > • Size of the project: all the posts suggested that 10
        > programmers are enough to do any project disregard to the project
        > size (See what curtis cooley in this regard as an example).

        All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.

        > • XP process: all the posts suggested that no modifications
        > should be introduced to XP's lifecycle, no matter the context is.

        What was said that XP should not be redefined. Everyone agrees, I
        think, that an individual team's process is and should be modified
        to fit their needs.

        > If the current lifecycle is not fit, we can use Crystal (ron's
        > suggestion).

        The advantage to Crystal for your purposes is that Alistair defines
        a family of processes tailor made for various sizes of problem,
        team, and risk.

        > The only exception to that is what Kent said (" the
        > process you are processing looks reasonable to me…..it enhances
        > accountability and responsibility") if I understood him
        > correctly.

        Yes he did say something like that. I think most people would agree
        that if YOUR team needs the elements you mention, you should do
        them. Many of us suspect that your team MAY not need them, but we
        base this on observing other teams who thought they needed things,
        not on inspecting your team.

        > This means that if we use all principles of XP and
        > modify the lifecycle then this is not XP.

        I do not understand what it would mean to say that a given process
        is, or is not, XP, nor why anyone would want to say it. What
        matters, its seems to me, is whether a given process is effective,
        and if the team likes the XP ideas, it makes sense to try to apply
        them.

        > Jon spoke also of the purity of XP. Use of analysis phase was also
        > rejected. The term pair development is accepted and considered a
        > more explanative than pair programming.

        I'm not sure what you're getting at here. Now that I think of it,
        I'm not sure what you are getting at at all. I await enlightenment.

        > • Tacit Vs. explicit knowledge: almost everyone in this
        > discussion emphasized the importance of tacit knowledge sharing.
        > Code and test cases are the used forms of explicit knowledge. Fear
        > of miscommunication through documentation, the burden of their
        > creation and maintenance, and usefulness lead to resistance of
        > documents as a knowledge sharing tool. Exception to that are the
        > posts in documentation and designing post, where some encouraged
        > the use of 'light ' models and documents such as ERD and Use Cases.

        I think you may be mischaracterizing people's views here. I am
        certain that you are over-generalizing, in that there are thousands
        of members on this list with opinions, and we have not heard from
        most of them.

        Regards,

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        It is not because things are difficult that we do not dare,
        it is because we do not dare that they are difficult. --Seneca
      • zaidoun alzoabi
        ...   cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some
        Message 3 of 11 , Nov 6, 2009
          > • Size of the project: all the posts suggested that 10
          > programmers are enough to do any project disregard to the project
          > size (See what curtis cooley in this regard as an example).

          >>All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.
           
          cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some projects require more than 10 programmers? if we have such projects, do we stick to the same face-to-face principle? would it be enough?
           
          > • XP process: all the posts suggested that no modifications
          > should be introduced to XP's lifecycle, no matter the context is.

          >>What was said that XP should not be redefined. Everyone agrees, I
          >>think, that an individual team's process is and should be modified
          >>to fit their needs.
           
          It is not redifining XP, it is a suggestion when using XP in large projects. In those projects, where we need to reach a common understading in highly complex environment.
           
          >>I think you may be mischaracterizing people's views here. I am
          >>certain that you are over-generalizing, in that there are thousands
          >>of members on this list with opinions, and we have not heard from
          >>most of them.

          I did not say everyone in the group, I just said everybody in the discussion, this obviously does not mean everyone in the group, and those who participated in the discussion emphasized tacit knowledge sharing, you can review the posts and you will get to the same conclusion.
           
          One more note: I met the project manager of one of the leading software companies in the Middle East, who is providing software to large mobile communication using XP as the software development method and he said: " no matter how we explain to our customers that many documents are not needed, ALL our customers insisted to have these documents and in fact in some cases we found that these documents are useful"
          Regards,

          Zaidoun




          [Non-text portions of this message have been removed]
        • Adam Sroka
          ... Not exactly. One of the lessons of Agile is that smaller is better. Small classes and methods are easier to understand and maintain. Small stories are
          Message 4 of 11 , Nov 6, 2009
            On Thu, Nov 5, 2009 at 10:03 PM, zdnfa <zdnfa@...> wrote:
            >
            >
            >
            > Dear all,
            >
            > After a couple of discussions on documentation and knowledge sharing in XP I would like to summerize what I understood, and would like to see your comments on the ideas presented
            > Your comments on the ideas I presented were as follows:
            >
            > • Size of the project: all the posts suggested that 10 programmers are enough to do any project disregard to the project size (See what curtis cooley in this regard as an example).
            >

            Not exactly. One of the lessons of Agile is that smaller is better.
            Small classes and methods are easier to understand and maintain. Small
            stories are quicker to implement. Small teams gel quickly and can
            swarm on stories to get them done. Small, frequent releases enable
            rapid customer feedback. Etc. This is contrary to the traditional view
            that if I want to do twice as much I just double my resources.

            It is not possible to scale an Agile team without fundamentally
            effecting the way that they work, and I have yet to see this happen
            for the better. It is possible to scale Agile projects by breaking the
            work along business or functional lines. I have seen this work, but I
            am not convinced that it was better.

            The problem with scaling is that most businesses, particularly large
            ones, think that their problems are large. The reality is that nearly
            every supposedly large problem is really just a set of small problems,
            and each of those small problems benefits from having a small cohesive
            group focus in on it and get it done. It might be possible for more
            than one small team to work on each of these small problems, but that
            mitigates our ability to learn from each small problem and adapt our
            path towards the larger goal.

            Agile teams are like Special Forces. You might think that having more
            Special Forces was better. The reality is that maintaining a small
            footprint and operating as a small, cohesive team is fundamental to
            their ability to do their job. If you put a bunch of them together as
            a big team then they have to operate as a big team which means they
            can't do the missions that they can do as a small team.

            > • XP process: all the posts suggested that no modifications should be introduced to XP's lifecycle, no matter the context is. If the current lifecycle is not fit, we can use Crystal (ron's suggestion). The only exception to that is what Kent said (" the process you are processing looks reasonable to me…..it enhances accountability and responsibility") if I understood him correctly. This means that if we use all principles of XP and modify the lifecycle then this is not XP. Jon spoke also of the purity of XP. Use of analysis phase was also rejected. The term pair development is accepted and considered a more explanative than pair programming.
            >

            I am not going to speak for anyone else. What I have been trying to
            say is that there is a reason that some of us don't do things the way
            you suggest.

            I am less and less interested in whether you call what you are doing
            XP or some sort of modification to XP. The point that you seem to be
            ignoring is that the things you want to add to XP aren't in XP *by
            design*.

            Most folks who have done XP have also done formal documentation and
            analysis phases. I did RUP. I even got formal training in RUP and used
            some of the tools. It didn't work very well, and I didn't enjoy it. As
            a recovering RUP user I found XP and discovered that it emphasized
            many of the things that I knew mattered (Like code that works, and
            working together to solve business problems) and rejected many of the
            things that I couldn't get to work (Like analysis phases and detailed
            specs.)

            When XP and other "lean methods" were invented they were based on the
            idea that we could focus on the activities that really mattered to
            creating quality working software and ignore much of the rest. The
            things you are suggesting are things that we deliberately removed.
            Before you put them back in it might be worth your while to understand
            why we removed them. That is the piece that seems to be missing.

            > • Tacit Vs. explicit knowledge: almost everyone in this discussion emphasized the importance of tacit knowledge sharing. Code and test cases are the used forms of explicit knowledge. Fear of miscommunication through documentation, the burden of their creation and maintenance, and usefulness lead to resistance of documents as a knowledge sharing tool. Exception to that are the posts in documentation and designing post, where some encouraged the use of 'light ' models and documents such as ERD and Use Cases.
            >

            I have been excruciatingly clear on this, and I'm not going to waste
            another second on it... damn, I just did ;-)
          • Curtis Cooley
            ... If I did say any project can be done with 10 people then I disagree with what I said. What I meant is that I do not believe the increase in productivity as
            Message 5 of 11 , Nov 6, 2009
              On Fri, Nov 6, 2009 at 10:28 AM, zaidoun alzoabi <zdnfa@...> wrote:
              >
              >
              >
              > > • Size of the project: all the posts suggested that 10
              > > programmers are enough to do any project disregard to the project
              > > size (See what curtis cooley in this regard as an example).
              >
              > >>All the posts DID NOT SUGGEST THAT. Some, perhaps only one, did.
              >
              > cool down Ron!! when I saw no comments on what Cooley said i -mistakenly as appeared- thought that everybody agrees to it. So do you think that some projects require more than 10 programmers? if we have such projects, do we stick to the same face-to-face principle? would it be enough?

              If I did say any project can be done with 10 people then I disagree
              with what I said. What I meant is that I do not believe the increase
              in productivity as you add developers is linear. I believe that as you
              add developers, you approach a point where adding more will decrease
              your productivity due to communication overhead. Imagine 1000 people
              trying to mow a 400 square foot lawn. I may have implied that the
              number is 10, but I have no idea that the number is 10. I have no idea
              what the number is. I don't actually have any evidence that the number
              exists except for thought experiments I've done where I try to image
              10,000 developers trying to get something done.

              I guess no one openly disagreed with what I said because everyone has
              that number in their head. Some think it's 5, others think it's 10.
              Microsoft thinks they can build an OS with 2500. Whether they can or
              not is a point of debate. I'll go out on a limb and say everyone on
              this list has some maximum number of developers he or she thinks is
              effective.

              --
              Curtis Cooley
              curtis.cooley@...
              home:http://curtiscooley.com
              blog:http://ponderingobjectorienteddesign.blogspot.com
              ===============
              Leadership is a potent combination of strategy and character. But if
              you must be without one, be without the strategy.
              -- H. Norman Schwarzkopf
            • Adam Sroka
              ... s/lean/lightweight/
              Message 6 of 11 , Nov 6, 2009
                On Fri, Nov 6, 2009 at 11:20 AM, Adam Sroka <adam.sroka@...> wrote:
                >
                > When XP and other "lean methods" ...

                s/lean/lightweight/
              Your message has been successfully submitted and would be delivered to recipients shortly.