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

Re: summary of the disscusion

Expand Messages
  • Phlip
    ... The Tao that can be understood is less than the Eternal Tao. We might also have some language translation issues, too. (-:
    Message 1 of 11 , Nov 6, 2009
    • 0 Attachment
      Critique wrote:

      > Zaidoun,
      >
      >> Jon spoke also of the purity of XP.
      >
      > I dislike the way this is phrased because, to my mind, it suggests
      > that I spoke of XP as something that was "pure", giving an implication
      > that it is right. (Pure gold, pure (unblemished) victory, etc)

      The Tao that can be understood is less than the Eternal Tao.

      We might also have some language translation issues, too. (-:
    • 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 2 of 11 , Nov 6, 2009
      • 0 Attachment
        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 3 of 11 , Nov 6, 2009
        • 0 Attachment
          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 4 of 11 , Nov 6, 2009
          • 0 Attachment
            > • 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 5 of 11 , Nov 6, 2009
            • 0 Attachment
              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 6 of 11 , Nov 6, 2009
              • 0 Attachment
                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 7 of 11 , Nov 6, 2009
                • 0 Attachment
                  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.