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

XP Project Management tool recommendation?

Expand Messages
  • Alexander Kon
    Hi folks, What do you recommend as an *XP* project management tool? I prefer the software be (in importance order): 1. With public API or Web Services 2.
    Message 1 of 16 , Feb 28, 2005
    • 0 Attachment
      Hi folks,

      What do you recommend as an *XP* project management tool?

      I prefer the software be (in importance order):

      1. With public API or Web Services
      2. Web-Based
      3. Open Source
      4. With Bug-Tracker

      Thanks in advance,
      --
      - Alexander K. Kon
    • Ron Jeffries
      ... Please tell us more about the project. Is it co-located? Is it starting from an empty code base? What external communication requirements do you have? Why
      Message 2 of 16 , Feb 28, 2005
      • 0 Attachment
        On Monday, February 28, 2005, at 2:03:52 PM, Alexander Kon wrote:

        > What do you recommend as an *XP* project management tool?

        > I prefer the software be (in importance order):

        > 1. With public API or Web Services
        > 2. Web-Based
        > 3. Open Source
        > 4. With Bug-Tracker

        Please tell us more about the project. Is it co-located? Is it
        starting from an empty code base? What external communication
        requirements do you have? Why are you planning to have enough bugs
        to need tracking?

        Thanks,

        Ron Jeffries
        www.XProgramming.com
        If not now, when? -- The Talmud
      • Sarath Kummamuru
        Why are you planning to have enough bugs to need tracking? . A wonderful question ;-) But any way coming back to what forms part of a XP
        Message 3 of 16 , Feb 28, 2005
        • 0 Attachment
          <quote> Why are you planning to have enough bugs to need tracking? </quote>.
          A wonderful question ;-)

          But any way coming back to what forms part of a XP Project management
          tool. The most crucial part of Project Management and with XP
          obviously is communication and from my experience i am writing some of
          the tools that we have used before or think of using that server our
          PM for XP purposes well. (Predominantly the communication part).


          For our projects we use

          Wiki for user stories, with some status tracking capabilities, RSS
          support for content update notifications to notify interested parties
          about changes to user stories, comments about them, etc.

          A Issue Tracker to document feature requests (associated with users
          stories), change requests and link to the Version control system (CVS
          or SVN).

          An interface between the Version Control System and Issue Tracker with
          the Wiki to update the status, version and other details to be viewed
          from the project wiki.

          An automate JUnit class generator which again creates links in the Wiki.

          guess it is obvious that a wiki in my opinion (and experience) forms a
          core part of any XP effort to make sure that the process remains
          light.

          I am not sure if there are any ready made products that are available,
          but if some of us are interested, I would love to start that effort
          for an (close to Ideal) XP Project management tool.

          A feature missing with most wikis is an ability to use tags for
          multiple documents in multiple versions (more or less like tagging a
          project in CVS with a unique name, so that an export can be done any
          time.) Still looking for this kind of a feature.

          As for pair programming, there is nothing that can substitute a pair
          partner in flesh and blood, but there is a plug in for eclipse which
          is promising (Atleast a start in the right direction).

          Sarath.
          http://www.quadone.com







          On Mon, 28 Feb 2005 20:26:19 -0600, Ron Jeffries
          <ronjeffries@...> wrote:
          >
          > On Monday, February 28, 2005, at 2:03:52 PM, Alexander Kon wrote:
          >
          > > What do you recommend as an *XP* project management tool?
          >
          > > I prefer the software be (in importance order):
          >
          > > 1. With public API or Web Services
          > > 2. Web-Based
          > > 3. Open Source
          > > 4. With Bug-Tracker
          >
          > Please tell us more about the project. Is it co-located? Is it
          > starting from an empty code base? What external communication
          > requirements do you have? Why are you planning to have enough bugs
          > to need tracking?
          >
          > Thanks,
          >
          > Ron Jeffries
          > www.XProgramming.com
          > If not now, when? -- The Talmud
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
        • Michael Dubakov
          Hi, I may suggest TargetProcess:Suite. http://www.targetprocess.com The version 1.2 will be released soon. Release candidate already on demo site. ... Yes, API
          Message 4 of 16 , Mar 1, 2005
          • 0 Attachment
            Hi,

            I may suggest TargetProcess:Suite.
            http://www.targetprocess.com

            The version 1.2 will be released soon.
            Release candidate already on demo site.

            > 1. With public API or Web Services

            Yes, API will be included in v1.2

            > 2. Web-Based

            Yes. .NET platform

            > 3. Open Source

            Commercial open source version will be available in v1.2

            > 4. With Bug-Tracker

            Yes, there is bug tracking module.

            You may contact me to discuss details.
            info (at) targetprocess.com.

            Michael
            http://www.targetprocess.com
            XP Planning & Bug Tracking tool.



            > Hi folks,
            >
            > What do you recommend as an *XP* project management tool?
            >
            > I prefer the software be (in importance order):
            >
            > 1. With public API or Web Services
            > 2. Web-Based
            > 3. Open Source
            > 4. With Bug-Tracker
            >
            > Thanks in advance,
            > --
            > - Alexander K. Kon
          • Ron Jeffries
            ... Thank you. I meant it to be amusing and provocative at the same time. Just as I would not buy a circular saw until it was time to cut boards, I would not
            Message 5 of 16 , Mar 1, 2005
            • 0 Attachment
              On Tuesday, March 1, 2005, at 1:11:30 AM, Sarath Kummamuru wrote:

              > <quote> Why are you planning to have enough bugs to need tracking? </quote>.
              > A wonderful question ;-)

              Thank you. I meant it to be amusing and provocative at the same
              time. Just as I would not buy a circular saw until it was time to
              cut boards, I would not get a bug tracker until I had enough bugs to
              need tracking. Since XP teams sometimes report only one defect per
              month, that day really might not come.

              > But any way coming back to what forms part of a XP Project management
              > tool. The most crucial part of Project Management and with XP
              > obviously is communication and from my experience i am writing some of
              > the tools that we have used before or think of using that server our
              > PM for XP purposes well. (Predominantly the communication part).

              Yes. Agile methods like XP try to rely on direct person to person
              contact for communicating as much as possible. In addition, they
              often use informative charts and other wall decorations for keeping
              track of status such as the amount of work that's done and what's
              left to do.

              I am concerned, in general, when a would-be XP team starts using
              tools, that the tools might get them off on the wrong foot in
              communicating: they might use cold textual documents for matters
              that could best be communicated in a warmer more human fashion.

              > For our projects we use

              > Wiki for user stories, with some status tracking capabilities, RSS
              > support for content update notifications to notify interested parties
              > about changes to user stories, comments about them, etc.

              Here I would ask whether the people who are being notified cannot
              for some reason be in the room with everyone else when these things
              are mentioned. I would also be concerned that the people in the room
              might begin using the wiki to communicate even with others in the
              room.

              Some years ago I went to the first national meeting of the
              CompuServe "CB" chat users. (CB was one of the first "instant
              message" tools, and they decided to have a get-together.) The most
              striking thing about the meeting was that after a little while
              talking with their electronic friends at the hotel, many CBers
              went back to their respective rooms, opened up CB, and went back
              to typing messages to each other. The actual human contact was too
              much for them.

              There are probably days when a programming team might feel the same
              way, but in my experience the richness and warmth of all being
              present together is of great value to the project. I wouldn't want
              the wiki to interfere with it.

              > A Issue Tracker to document feature requests (associated with users
              > stories), change requests and link to the Version control system (CVS
              > or SVN).

              Again I wonder what it is about the project that needs these things.
              Is there no customer to keep track of the user stories and
              requirements? Has she no lunch box to keep her cards in? (It might
              well be that someone in the role of customer might want to keep her
              stories electronically, and she should certainly do so if she
              wishes. But it's not inherently necessary.)

              > An interface between the Version Control System and Issue Tracker with
              > the Wiki to update the status, version and other details to be viewed
              > from the project wiki.

              Again ... what's to update? Will it enhance communication among the
              team ... or will it actually get in the way.

              > An automate JUnit class generator which again creates links in the Wiki.

              I don't understand this notion but it sounds interesting. What does
              it generate, and what are the links in the wiki for?

              > guess it is obvious that a wiki in my opinion (and experience) forms a
              > core part of any XP effort to make sure that the process remains
              > light.

              A wiki is very light. Not having a wiki is even lighter and I have
              seen very many projects that went just fine without even a wiki.

              > I am not sure if there are any ready made products that are available,
              > but if some of us are interested, I would love to start that effort
              > for an (close to Ideal) XP Project management tool.

              There are quite a few such products listed on my software page, at
              http://www.xprogramming.com/software.htm . There are also links to a
              few articles relating to this topic.

              > A feature missing with most wikis is an ability to use tags for
              > multiple documents in multiple versions (more or less like tagging a
              > project in CVS with a unique name, so that an export can be done any
              > time.) Still looking for this kind of a feature.

              Why do you want multiple versions of your documents? Could the
              hierarchic aspects of the wiki that comes with FitNesse serve this
              need?

              > As for pair programming, there is nothing that can substitute a pair
              > partner in flesh and blood, but there is a plug in for eclipse which
              > is promising (Atleast a start in the right direction).

              It's a start in a direction that would help two people who cannot
              sit together within voice distance pair. Sometimes I would even use
              such a thing while physically together, because it might make the
              joint use of keyboard and mouse possible. It would be at least
              interesting. Chet and I are looking at setting up pair document
              editing (not project documents, stand down, but books and articles)
              so that both keyboards and mouses work at the same time. A pointer
              to such products would be helpful, by the way.

              So ... lots to think about. My experience leads me to the concern
              that many of us are so used to working through these keyboards that
              we'll use them when human conversation and presence together would
              be better. Thus I am slow to recommend or to go to such tools, even
              though as a techie I like to have every gadget that exists.

              Regards,

              Ron Jeffries
              www.XProgramming.com
              You don't need to see my identification.
              These aren't the ideas you're looking for. Move along.
            • Michael Dubakov
              ... Yes, I agree. Teams should use tools only if they pretty sure about possible benefits. If it is possible to not use a tool without teams performance
              Message 6 of 16 , Mar 1, 2005
              • 0 Attachment
                > So ... lots to think about. My experience leads me to the concern
                > that many of us are so used to working through these keyboards that
                > we'll use them when human conversation and presence together would
                > be better. Thus I am slow to recommend or to go to such tools, even
                > though as a techie I like to have every gadget that exists.

                Yes, I agree. Teams should use tools only if they pretty sure about
                possible benefits. If it is possible to not use a tool without teams
                performance penalty and so on, you should not use the tool.

                Michael
                http://www.targetprocess.com
                XP Planning & BugTracking software



                --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                <ronjeffries@X...> wrote:
                > On Tuesday, March 1, 2005, at 1:11:30 AM, Sarath Kummamuru wrote:
                >
                > > <quote> Why are you planning to have enough bugs to need tracking?
                </quote>.
                > > A wonderful question ;-)
                >
                > Thank you. I meant it to be amusing and provocative at the same
                > time. Just as I would not buy a circular saw until it was time to
                > cut boards, I would not get a bug tracker until I had enough bugs to
                > need tracking. Since XP teams sometimes report only one defect per
                > month, that day really might not come.
                >
                > > But any way coming back to what forms part of a XP Project management
                > > tool. The most crucial part of Project Management and with XP
                > > obviously is communication and from my experience i am writing some of
                > > the tools that we have used before or think of using that server our
                > > PM for XP purposes well. (Predominantly the communication part).
                >
                > Yes. Agile methods like XP try to rely on direct person to person
                > contact for communicating as much as possible. In addition, they
                > often use informative charts and other wall decorations for keeping
                > track of status such as the amount of work that's done and what's
                > left to do.
                >
                > I am concerned, in general, when a would-be XP team starts using
                > tools, that the tools might get them off on the wrong foot in
                > communicating: they might use cold textual documents for matters
                > that could best be communicated in a warmer more human fashion.
                >
                > > For our projects we use
                >
                > > Wiki for user stories, with some status tracking capabilities, RSS
                > > support for content update notifications to notify interested parties
                > > about changes to user stories, comments about them, etc.
                >
                > Here I would ask whether the people who are being notified cannot
                > for some reason be in the room with everyone else when these things
                > are mentioned. I would also be concerned that the people in the room
                > might begin using the wiki to communicate even with others in the
                > room.
                >
                > Some years ago I went to the first national meeting of the
                > CompuServe "CB" chat users. (CB was one of the first "instant
                > message" tools, and they decided to have a get-together.) The most
                > striking thing about the meeting was that after a little while
                > talking with their electronic friends at the hotel, many CBers
                > went back to their respective rooms, opened up CB, and went back
                > to typing messages to each other. The actual human contact was too
                > much for them.
                >
                > There are probably days when a programming team might feel the same
                > way, but in my experience the richness and warmth of all being
                > present together is of great value to the project. I wouldn't want
                > the wiki to interfere with it.
                >
                > > A Issue Tracker to document feature requests (associated with users
                > > stories), change requests and link to the Version control system (CVS
                > > or SVN).
                >
                > Again I wonder what it is about the project that needs these things.
                > Is there no customer to keep track of the user stories and
                > requirements? Has she no lunch box to keep her cards in? (It might
                > well be that someone in the role of customer might want to keep her
                > stories electronically, and she should certainly do so if she
                > wishes. But it's not inherently necessary.)
                >
                > > An interface between the Version Control System and Issue Tracker with
                > > the Wiki to update the status, version and other details to be viewed
                > > from the project wiki.
                >
                > Again ... what's to update? Will it enhance communication among the
                > team ... or will it actually get in the way.
                >
                > > An automate JUnit class generator which again creates links in the
                Wiki.
                >
                > I don't understand this notion but it sounds interesting. What does
                > it generate, and what are the links in the wiki for?
                >
                > > guess it is obvious that a wiki in my opinion (and experience) forms a
                > > core part of any XP effort to make sure that the process remains
                > > light.
                >
                > A wiki is very light. Not having a wiki is even lighter and I have
                > seen very many projects that went just fine without even a wiki.
                >
                > > I am not sure if there are any ready made products that are available,
                > > but if some of us are interested, I would love to start that effort
                > > for an (close to Ideal) XP Project management tool.
                >
                > There are quite a few such products listed on my software page, at
                > http://www.xprogramming.com/software.htm . There are also links to a
                > few articles relating to this topic.
                >
                > > A feature missing with most wikis is an ability to use tags for
                > > multiple documents in multiple versions (more or less like tagging a
                > > project in CVS with a unique name, so that an export can be done any
                > > time.) Still looking for this kind of a feature.
                >
                > Why do you want multiple versions of your documents? Could the
                > hierarchic aspects of the wiki that comes with FitNesse serve this
                > need?
                >
                > > As for pair programming, there is nothing that can substitute a pair
                > > partner in flesh and blood, but there is a plug in for eclipse which
                > > is promising (Atleast a start in the right direction).
                >
                > It's a start in a direction that would help two people who cannot
                > sit together within voice distance pair. Sometimes I would even use
                > such a thing while physically together, because it might make the
                > joint use of keyboard and mouse possible. It would be at least
                > interesting. Chet and I are looking at setting up pair document
                > editing (not project documents, stand down, but books and articles)
                > so that both keyboards and mouses work at the same time. A pointer
                > to such products would be helpful, by the way.
                >
                > So ... lots to think about. My experience leads me to the concern
                > that many of us are so used to working through these keyboards that
                > we'll use them when human conversation and presence together would
                > be better. Thus I am slow to recommend or to go to such tools, even
                > though as a techie I like to have every gadget that exists.
                >
                > Regards,
                >
                > Ron Jeffries
                > www.XProgramming.com
                > You don't need to see my identification.
                > These aren't the ideas you're looking for. Move along.
              • Steve Bate
                ... I have a list of 22 tools for agile project management (XP and Scrum) at... http://del.icio.us/sbate/agile+projectmanagement+tool?setcount=50 This page
                Message 7 of 16 , Mar 1, 2005
                • 0 Attachment
                  > From: Sarath Kummamuru [mailto:kcsarath@...]
                  > I am not sure if there are any ready made products that are available,
                  > but if some of us are interested, I would love to start that effort
                  > for an (close to Ideal) XP Project management tool.

                  I have a list of 22 tools for agile project management (XP and Scrum)
                  at...

                  http://del.icio.us/sbate/agile+projectmanagement+tool?setcount=50

                  This page also has an RSS feed if you want to monitor new tool
                  links as I add them.

                  From what I've seen, VersionOne is the most popular of the
                  commercial tools and XPlanner is the most popular of the free,
                  open source tools.

                  Steve
                • William Pietri
                  ... I think I d go even farther than that. Even if people think eschewing the tracking tool will be moderately worse, I encourage them to try the experiment
                  Message 8 of 16 , Mar 1, 2005
                  • 0 Attachment
                    On Tue, 2005-03-01 at 11:43 +0000, Michael Dubakov wrote:
                    > > So ... lots to think about. My experience leads me to the concern
                    > > that many of us are so used to working through these keyboards that
                    > > we'll use them when human conversation and presence together would
                    > > be better. Thus I am slow to recommend or to go to such tools, even
                    > > though as a techie I like to have every gadget that exists.
                    >
                    > Yes, I agree. Teams should use tools only if they pretty sure about
                    > possible benefits. If it is possible to not use a tool without teams
                    > performance penalty and so on, you should not use the tool.

                    I think I'd go even farther than that. Even if people think eschewing
                    the tracking tool will be moderately worse, I encourage them to try the
                    experiment and see how and how much reality conforms to their
                    intuitions.

                    For many, this approach is scary, and they ask a million what-if
                    questions: What if I lose the cards? What if a manager wants to know
                    what's going on? What if I'm at home and want to add a feature idea? If
                    I get them to calm down, they'll discover they can answer these
                    questions themselves.

                    For those whose fear doesn't abate, I suggest they treat the cards as
                    primary, and occasionally update their tools or documents with the
                    results of group interactions. Almost every time I've tried this,
                    they've eventually given up on the tool, or at least drastically cut
                    back their use of it. It's not that they suddenly see the tool as
                    valueless. Rather, they discover that most of their needs are already
                    addressed in the process, and that the rest, while valuable, aren't as
                    valuable as other things they can do for the project.

                    William

                    --
                    William Pietri <william@...>
                  • Sarath Kummamuru
                    ... I do agree. ... I do agree with you and with XP about the importance of person - person Direct communication. I also strongly believe in putting pen on
                    Message 9 of 16 , Mar 18, 2005
                    • 0 Attachment
                      > > <quote> Why are you planning to have enough bugs to need tracking? </quote>.
                      > > A wonderful question ;-)
                      >
                      > Thank you. I meant it to be amusing and provocative at the same
                      > time. Just as I would not buy a circular saw until it was time to
                      > cut boards, I would not get a bug tracker until I had enough bugs to
                      > need tracking. Since XP teams sometimes report only one defect per
                      > month, that day really might not come.
                      I do agree.

                      >
                      > > But any way coming back to what forms part of a XP Project management
                      > > tool. The most crucial part of Project Management and with XP
                      > > obviously is communication and from my experience i am writing some of
                      > > the tools that we have used before or think of using that server our
                      > > PM for XP purposes well. (Predominantly the communication part).
                      >
                      > Yes. Agile methods like XP try to rely on direct person to person
                      > contact for communicating as much as possible. In addition, they
                      > often use informative charts and other wall decorations for keeping
                      > track of status such as the amount of work that's done and what's
                      > left to do.
                      >
                      > I am concerned, in general, when a would-be XP team starts using
                      > tools, that the tools might get them off on the wrong foot in
                      > communicating: they might use cold textual documents for matters
                      > that could best be communicated in a warmer more human fashion.

                      I do agree with you and with XP about the importance of person -
                      person Direct communication. I also strongly believe in "putting pen
                      on paper", so we have our developers writing what they need to on
                      cards and stick them up on their work boards and on their desks. Each
                      developer is expected to have the paper (or cards) with them when they
                      sit together and program.
                      At the same time, being predominantly offshore, we need to get our
                      client strongly involved into the communication, so we get the stories
                      and other stuff on to the wiki where the Actual client/User is seeing
                      in English what is being thought. For us a wiki is a way to put
                      thoughts on a plane where the client can see them. So we strongly
                      advocate using Wiki for this. (Though ensuring that priority is for
                      "pen on paper" )


                      >
                      > > For our projects we use
                      >
                      > > Wiki for user stories, with some status tracking capabilities, RSS
                      > > support for content update notifications to notify interested parties
                      > > about changes to user stories, comments about them, etc.
                      >
                      > Here I would ask whether the people who are being notified cannot
                      > for some reason be in the room with everyone else when these things
                      > are mentioned. I would also be concerned that the people in the room
                      > might begin using the wiki to communicate even with others in the
                      > room.
                      >
                      Yeah like i already mentioned, when a team of developers sitting in
                      the US is working along with a team that is here in India, we find a
                      lot of benefit in Rss based notifications.

                      > Some years ago I went to the first national meeting of the
                      > CompuServe "CB" chat users. (CB was one of the first "instant
                      > message" tools, and they decided to have a get-together.) The most
                      > striking thing about the meeting was that after a little while
                      > talking with their electronic friends at the hotel, many CBers
                      > went back to their respective rooms, opened up CB, and went back
                      > to typing messages to each other. The actual human contact was too
                      > much for them.
                      >
                      ;-) I understand how they must have felt. Though i also realize that,
                      getting into such a situation is really dangerous for a project.

                      > There are probably days when a programming team might feel the same
                      > way, but in my experience the richness and warmth of all being
                      > present together is of great value to the project. I wouldn't want
                      > the wiki to interfere with it.
                      I do agree, like i said, the wiki is to put what we have on paper in
                      front of us, in a place where out client or counterparts can share.

                      >
                      > > A Issue Tracker to document feature requests (associated with users
                      > > stories), change requests and link to the Version control system (CVS
                      > > or SVN).
                      >
                      > Again I wonder what it is about the project that needs these things.
                      > Is there no customer to keep track of the user stories and
                      > requirements? Has she no lunch box to keep her cards in? (It might
                      > well be that someone in the role of customer might want to keep her
                      > stories electronically, and she should certainly do so if she
                      > wishes. But it's not inherently necessary.)
                      >
                      Some how i felt having a Issue Tracker, gave some people a perspective
                      that they felt comfortable with, for example, we have a person who is
                      not so much into XP and feels there is some thing missing if he
                      doesnot see the global perspective, For such a person an issue tracker
                      worked very well. He just goes to it, sees the list of issues, and the
                      status as updated by a CVS commit notification.
                      For me this is a win win, because my developer just claims he
                      completed the task X %, when he commits the code to the repository and
                      the Manager sees that status. Light enough for the developer not to
                      add extra work and comfortable for a manager who says (At the end of
                      it all, any time i want to look at a project, i want to be able to see
                      where we stand).

                      > > An interface between the Version Control System and Issue Tracker with
                      > > the Wiki to update the status, version and other details to be viewed
                      > > from the project wiki.
                      >
                      > Again ... what's to update? Will it enhance communication among the
                      > team ... or will it actually get in the way.
                      >
                      > > An automate JUnit class generator which again creates links in the Wiki.
                      >
                      > I don't understand this notion but it sounds interesting. What does
                      > it generate, and what are the links in the wiki for?
                      >
                      Say I have a story Login, this forms a page in my wiki. A developer
                      picks up this story, puts it on a card and also in the wiki. Starts
                      coding. When we get to the meta information of an entity called User
                      in this case, we define it in Hibernate XML, generate the classes
                      associated with it. These classes would include the POJOs, Some
                      storage handlers with Basic CRUD API.

                      We have our own modifications to the Hibernate XML to include basic
                      field level validations, and using these we generate some JUNIT Test
                      cases, both for the POJOs and the Storage Handler CRUD methods.
                      As soon as these testers are created, the wiki is modified with a link
                      to say UnitTesters, (which becomes another page) and the names of the
                      testers are added to this.

                      Again the link in the Wiki points to a Testers list page, so that the
                      QA person, has a list of tests that have been accumulated over a
                      period of time for the project. So we get a place on our project wiki,
                      where all the testers' with their names is availalbe. They reivew it,
                      add any testers that the developer might have forgotten, or suggest
                      their own.

                      > > guess it is obvious that a wiki in my opinion (and experience) forms a
                      > > core part of any XP effort to make sure that the process remains
                      > > light.
                      >
                      > A wiki is very light. Not having a wiki is even lighter and I have
                      > seen very many projects that went just fine without even a wiki.
                      >
                      I do agree that a wiki is just a good tool and that neither is it a
                      necessary nor sufficient assurance for good project development.
                      The only necessary and sufficient conditions for successful project
                      development are
                      People,
                      Clear Communication between people,
                      A good attitude and
                      many of the XP principles.

                      > > I am not sure if there are any ready made products that are available,
                      > > but if some of us are interested, I would love to start that effort
                      > > for an (close to Ideal) XP Project management tool.
                      >
                      > There are quite a few such products listed on my software page, at
                      > http://www.xprogramming.com/software.htm . There are also links to a
                      > few articles relating to this topic.
                      >

                      > > A feature missing with most wikis is an ability to use tags for
                      > > multiple documents in multiple versions (more or less like tagging a
                      > > project in CVS with a unique name, so that an export can be done any
                      > > time.) Still looking for this kind of a feature.
                      >
                      > Why do you want multiple versions of your documents? Could the
                      > hierarchic aspects of the wiki that comes with FitNesse serve this
                      > need?
                      The reason i am looking for this kind of a feature is some thing like this.
                      I have a product that we built (a hospital Information management
                      system), built using many of our XP principles. Now a version of that
                      is released, because documentation is a compliance requirement, we do
                      have documentation in lines with what i described above for this
                      product.

                      Now for different customers we always have to make customizations,
                      that means some of the stories we had before would need to be
                      modified, some refactoring needs to be done, but that is only in the
                      context of the current client. While we are able to manage that pretty
                      well in the code by branching for each client, the documentation in
                      wiki is some thing we have a problem maintaing. So now we do some
                      thing like:

                      A Story called ScheduleAppointment in our prodcut wiki, becomes
                      ClientA_ScheduleAppointment with a link to the first page and this
                      page containing the modifications relevant to the customer.

                      >
                      > > As for pair programming, there is nothing that can substitute a pair
                      > > partner in flesh and blood, but there is a plug in for eclipse which
                      > > is promising (Atleast a start in the right direction).
                      >
                      > It's a start in a direction that would help two people who cannot
                      > sit together within voice distance pair. Sometimes I would even use
                      > such a thing while physically together, because it might make the
                      > joint use of keyboard and mouse possible. It would be at least
                      > interesting. Chet and I are looking at setting up pair document
                      > editing (not project documents, stand down, but books and articles)
                      > so that both keyboards and mouses work at the same time. A pointer
                      > to such products would be helpful, by the way.
                      >
                      That would be great Ron, i would love to see any progress on that. It
                      would be a great tool to use. Currently we cannot have a joint
                      continuous review with our developers and our counterparts, but if we
                      have it, that would be great. I think i remember reading about an
                      effort to build such a plugin for eclipse, but i need to check up.

                      > So ... lots to think about. My experience leads me to the concern
                      > that many of us are so used to working through these keyboards that
                      > we'll use them when human conversation and presence together would
                      > be better. Thus I am slow to recommend or to go to such tools, even
                      > though as a techie I like to have every gadget that exists.
                      >
                      > Regards,
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > You don't need to see my identification.
                      > These aren't the ideas you're looking for. Move along.
                      >
                      >
                      > To Post a message, send it to: extremeprogramming@...
                      >
                      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                      >
                      > ad-free courtesy of objectmentor.com
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                    • Ron Jeffries
                      ... Yes. It s a very interesting issue. It is possible, I would guess, to develop a culture where people live on the wiki, looking at it often and so on. I was
                      Message 10 of 16 , Mar 18, 2005
                      • 0 Attachment
                        On Friday, March 18, 2005, at 7:18:19 AM, Sarath Kummamuru wrote:

                        > I do agree with you and with XP about the importance of person -
                        > person Direct communication. I also strongly believe in "putting pen
                        > on paper", so we have our developers writing what they need to on
                        > cards and stick them up on their work boards and on their desks. Each
                        > developer is expected to have the paper (or cards) with them when they
                        > sit together and program.

                        > At the same time, being predominantly offshore, we need to get our
                        > client strongly involved into the communication, so we get the stories
                        > and other stuff on to the wiki where the Actual client/User is seeing
                        > in English what is being thought. For us a wiki is a way to put
                        > thoughts on a plane where the client can see them. So we strongly
                        > advocate using Wiki for this. (Though ensuring that priority is for
                        > "pen on paper" )

                        Yes. It's a very interesting issue. It is possible, I would guess,
                        to develop a culture where people live on the wiki, looking at it
                        often and so on.

                        I was just sitting with a new team who, because of their schedules,
                        are seldom all in the office at the same time. The members present
                        were complaining that the members absent didn't know what was going
                        on and that no one knew the full project status, even though it was
                        on the web site.

                        I allowed as how things like stand-up meetings are "push": everyone
                        hears what is said, while things like wikis are "pull": you only
                        find things out if you look.

                        Some teams use phone-in stand-up meetings. Object Mentor had these
                        for a long time. I found them better than nothing but without
                        something to look at and point at, they often became very boring and
                        it was hard to get the value out.

                        That leaves us with a dilemma. Phones, TV, wiki ... really aren't
                        "almost like being there". Some distributed teams are doing very
                        well, we're told. I just keep wondering what they'd be doing if they
                        were together. But, hey: we have to live in the world we're in ...
                        or do we?

                        Ron Jeffries
                        www.XProgramming.com
                        Accroche toi a ton reve. --ELO
                      • Steve Bate
                        ... Ron, Do you have any theories about why no one on the team is interested enough in the full project status to review the information? It seems that if a
                        Message 11 of 16 , Mar 19, 2005
                        • 0 Attachment
                          > From: Ron Jeffries [mailto:ronjeffries@...]
                          >...
                          > I was just sitting with a new team who, because of their schedules,
                          > are seldom all in the office at the same time. The members present
                          > were complaining that the members absent didn't know what was going
                          > on and that no one knew the full project status, even though it was
                          > on the web site.

                          Ron,

                          Do you have any theories about why no one on the team is interested
                          enough in the full project status to review the information? It seems
                          that if a team, or even a few individuals on the team, felt accountable
                          for delivering on team agreements with the customer they'd seek at
                          least enough information to know the team is on track.

                          If you were on this team, would you feel it was important for
                          yourself to know the full project status? Why or why not?

                          > I allowed as how things like stand-up meetings are "push": everyone
                          > hears what is said, while things like wikis are "pull": you only
                          > find things out if you look.

                          I agree there is often a lot of benefit to "push" information
                          channels. However, when I'm very interested in information that's
                          only available through a "pull" channel it's not a problem to
                          get it. I'm guessing there is more than a push/pull issue here.
                          For example, the web-based project data could be emailed (pushed)
                          to the team each day. Do you think that would make a significant
                          difference in their knowledge of project status... or would they
                          not pay much attention to the emails (like some people don't pay
                          much attention in standup meetings)?

                          Steve
                        • Ron Jeffries
                          ... It no longer seems quite that way to me. I don t think it s about lack of commitment or accountability, it s just a fact of life. My experience with myself
                          Message 12 of 16 , Mar 19, 2005
                          • 0 Attachment
                            On Saturday, March 19, 2005, at 12:00:28 PM, Steve Bate wrote:

                            >> From: Ron Jeffries [mailto:ronjeffries@...]
                            >>...
                            >> I was just sitting with a new team who, because of their schedules,
                            >> are seldom all in the office at the same time. The members present
                            >> were complaining that the members absent didn't know what was going
                            >> on and that no one knew the full project status, even though it was
                            >> on the web site.

                            > Ron,

                            > Do you have any theories about why no one on the team is interested
                            > enough in the full project status to review the information? It seems
                            > that if a team, or even a few individuals on the team, felt accountable
                            > for delivering on team agreements with the customer they'd seek at
                            > least enough information to know the team is on track.

                            It no longer seems quite that way to me. I don't think it's about
                            lack of commitment or accountability, it's just a fact of life.

                            My experience with myself and others is that the press of the day is
                            often such that one doesn't reach out to browse the team wiki or web
                            page. That's why Big Visible Chart, or Information Radiator are such
                            good metaphors: they point out that sometimes, especially when the
                            pressure is on, we need some help looking at what we want to look
                            at.

                            > If you were on this team, would you feel it was important for
                            > yourself to know the full project status? Why or why not?

                            Of course I would. And I would have a million things to do. Reading
                            is weak at the best of times; remembering to read at the right time
                            is unlikely ... especially when it's most important.

                            >> I allowed as how things like stand-up meetings are "push": everyone
                            >> hears what is said, while things like wikis are "pull": you only
                            >> find things out if you look.

                            > I agree there is often a lot of benefit to "push" information
                            > channels. However, when I'm very interested in information that's
                            > only available through a "pull" channel it's not a problem to
                            > get it. I'm guessing there is more than a push/pull issue here.
                            > For example, the web-based project data could be emailed (pushed)
                            > to the team each day. Do you think that would make a significant
                            > difference in their knowledge of project status... or would they
                            > not pay much attention to the emails (like some people don't pay
                            > much attention in standup meetings)?

                            I know that I pay far more attention to email than to things like
                            wikis or blogs. And when the phone rings, I answer it, even if I'm
                            reading email. Even blogs work better when we leave our reader open
                            and the RSS updates and the reader flashes.

                            I don't think it's about caring ... but even if it were, push would
                            still work better than pull.

                            It might relate to the slack discussion that's been going on on the
                            xp2e group. Some folks have brought up the urgency / importance
                            dimension found in Covey and other places. The wiki is important,
                            but since it's not urgent, it often gets short shrift. The standup
                            meeting, the email, the phone call ... those are more urgent and we
                            pay attention.

                            I'd like to be a better person ... but if you want my attention
                            before that time, whap me with a pig bladder. [Name that reference.]

                            Ron Jeffries
                            www.XProgramming.com
                            I could be wrong, but I'm not. --Eagles, Victim of Love
                          • Steve Bate
                            ... What do you mean when you say it s a fact of life? I agree there are other potential reasons for the team not reviewing the information available to them.
                            Message 13 of 16 , Mar 19, 2005
                            • 0 Attachment
                              > From: Ron Jeffries [mailto:ronjeffries@...]
                              >
                              > On Saturday, March 19, 2005, at 12:00:28 PM, Steve Bate wrote:
                              >
                              > > Do you have any theories about why no one on the team is interested
                              > > enough in the full project status to review the information? It seems
                              > > that if a team, or even a few individuals on the team, felt accountable
                              > > for delivering on team agreements with the customer they'd seek at
                              > > least enough information to know the team is on track.
                              >
                              > It no longer seems quite that way to me. I don't think it's about
                              > lack of commitment or accountability, it's just a fact of life.

                              What do you mean when you say it's a fact of life? I agree there are
                              other potential reasons for the team not reviewing the information
                              available to them. Wouldn't most of the reasons boil down to lack of
                              interest (relative to other, more valued, uses of their time) or lack
                              of will or self-control? I'm not saying lack of interest is always
                              wrong. It's entirely possible that the project isn't important enough
                              for a single person to spend a little time to monitor the status.
                              It's always surprising to me when even the customer has this perspective.
                              If it's lack of will, that's a tough problem. (I wonder if Dale has any
                              suggestions for this latter issue.)

                              > My experience with myself and others is that the press of the day is
                              > often such that one doesn't reach out to browse the team wiki or web
                              > page. That's why Big Visible Chart, or Information Radiator are such
                              > good metaphors: they point out that sometimes, especially when the
                              > pressure is on, we need some help looking at what we want to look
                              > at.

                              I believe information radiators are a great idea although they have
                              well-known limitations such as a requirement for physical proximity.
                              The comment about the radiators being more useful when the pressure
                              is on interests me. What is it about pressure that would lead someone,
                              especially someone who is committed and accountable, to be less
                              interested in project status relative to other activities?

                              I wonder if we asked individual people on a team under pressure which
                              is more important to them, finishing their current story or satisfying
                              the customer, how they'd answer? My guess is that some would say the
                              story completion is more important. Many developers work best by
                              focusing on the coding they need to get done, right now. Others would
                              say customer satisfaction is more important. The customer might prefer to
                              drop this particular story to increase the chances of completing other
                              stories. In my experience, people giving the second answer will be the
                              ones that actively go and look at the BVC or other information radiators.
                              They don't rely on absorbing the information through cognitive osmosis
                              as they walk by. These same people also don't seem to have a problem
                              with actively obtaining information from other sources.

                              > > If you were on this team, would you feel it was important for
                              > > yourself to know the full project status? Why or why not?
                              >
                              > Of course I would. And I would have a million things to do. Reading
                              > is weak at the best of times; remembering to read at the right time
                              > is unlikely ... especially when it's most important.

                              Interesting. Speaking for myself, I prefer not read project status
                              unless it's necessary. I want to be able to determine overall project
                              status very rapidly (a few seconds). If that rapid assessment triggers
                              warning signals, then I want to be able to drill down into more detail
                              and possibly do some reading eventually. Most of the time, even in high
                              pressure situations, the status is fine (or at least as expected) so it
                              doesn't require any detailed reading to monitor project status.

                              > ...
                              > I know that I pay far more attention to email than to things like
                              > wikis or blogs. And when the phone rings, I answer it, even if I'm
                              > reading email. Even blogs work better when we leave our reader open
                              > and the RSS updates and the reader flashes.

                              I agree about the difficulty in tracking information on most wikis. Email
                              notifications about wiki changes can help, but most wikis don't provide much
                              direct support for project status information aggregation and abstraction
                              like I described above. I find RSS to be very useful. However, in my case,
                              it's still "pull" and not "push". I use the Bloglines web-based aggregator
                              and I don't use an active notifier. I am monitoring so many blogs that a
                              notifier would be very disruptive. I choose to access Bloglines when I
                              decide I have some time to review my subscriptions. I actively do this
                              because I find the information if often very interesting. I like the RSS
                              aggregator because it provides an abstract view of blog activity. With a
                              glance I can see what categories of blogs have new postings and decide if
                              I'm more interested in looking at those than doing whatever I was currently
                              doing.

                              I do something similar with my email. I don't use an active notifier and my
                              mail program categorizes the messages as they arrive. I have a view that
                              shows me the activity in the various categories and this view helps me
                              decide when to "pull" the information.

                              For phone calls, I assign custom ring tones to my family and some friends.
                              If I'm concentrating on something and it's the standard ring tone, I often
                              don't answer the phone. If needed, I'll return the call later and pull the
                              information.

                              > I don't think it's about caring ... but even if it were, push would
                              > still work better than pull.

                              I'd only agree if I have sufficient control over what's being pushed to
                              me. I'd prefer spam to be pull rather than push, for example. If I subscribe
                              to email notifications from a wiki or a project management tool I want to be
                              able to specify the types and scope of notifications.

                              Also, in a standup meeting, if I have a question about a topic I care about,
                              I'll ask the question (pull) rather than wait for someone to read my mind
                              and push the information to me. My experience with standup meetings is that
                              there is frequently both pushing and pulling of information.

                              > It might relate to the slack discussion that's been going on on the
                              > xp2e group. Some folks have brought up the urgency / importance
                              > dimension found in Covey and other places. The wiki is important,
                              > but since it's not urgent, it often gets short shrift. The standup
                              > meeting, the email, the phone call ... those are more urgent and we
                              > pay attention.

                              You've used phrases like "high pressure situations", "when the pressure
                              is on" and "when it's the most important". To me, this sounds like
                              situations that are both urgent and important, and yet it's apparently
                              still difficult to focus attention on project status in those situations.

                              I don't think that pushing information has any direct relationship to
                              urgency. I could list many examples of low urgency information being
                              pushed at me frequently. I'm not saying that's always bad. Standup
                              meetings often fall into that category of important, low urgency
                              information transmission. It's interesting, but often not
                              very urgent, that I found out what someone else coded yesterday and what
                              they'll do tomorrow. If someone summarized the important and urgent
                              information from a typical 15-20+ minute standup meeting, I'm guessing
                              they could often do it in 1-2 minutes. If so, it says something about
                              the efficiency of that method of status communication. I think the
                              more important aspects of the standup meeting are related to bonding
                              and interpersonal interaction. It's also a dedicated time to focus
                              awareness on the WholeTeam.

                              I'm interested in these topics because, in my experience, there are
                              usually at least one or two people on a team who will actively
                              monitor project status. It seems like those people are often the
                              same ones who are the most committed and feel personal accountability
                              for the overall success of the project. The other developers are often
                              happy to just write code and passively let information be pushed at
                              them when someone else thinks they need it. It seems to me that a
                              team without anyone with an active interest in project status that
                              would be at risk. It also seems to me like a bigger issue than
                              whether the team uses paper or electronic tools for tracking project
                              status.

                              > I'd like to be a better person ... but if you want my attention
                              > before that time, whap me with a pig bladder. [Name that reference.]

                              :) You stumped me, but it sounds like a funny one.

                              Steve
                            • Ron Jeffries
                              ... I agree that there are people who are more into project status than others. Some of the conversation here suggests that the others are somehow less
                              Message 14 of 16 , Mar 19, 2005
                              • 0 Attachment
                                On Saturday, March 19, 2005, at 4:38:23 PM, Steve Bate wrote:

                                > I'm interested in these topics because, in my experience, there are
                                > usually at least one or two people on a team who will actively
                                > monitor project status. It seems like those people are often the
                                > same ones who are the most committed and feel personal accountability
                                > for the overall success of the project. The other developers are often
                                > happy to just write code and passively let information be pushed at
                                > them when someone else thinks they need it. It seems to me that a
                                > team without anyone with an active interest in project status that
                                > would be at risk. It also seems to me like a bigger issue than
                                > whether the team uses paper or electronic tools for tracking project
                                > status.

                                I agree that there are people who are more into project status than
                                others. Some of the conversation here suggests that the others are
                                somehow less interested or less committed. While that is surely
                                sometimes true, I think it is far from always true.

                                Some people organize things differently from others, regardless of
                                commitment level. Ways of communicating important information that
                                can't be missed will attract people's attention, and in my
                                experience, people who might not have browsed the wiki will still
                                help.

                                A very powerful example: imagine that when people needed help, they
                                posted on a wiki. Then wiki prowlers would be the only people ever
                                to give help. But if people mention in the standup meeting that they
                                need help, IME more folks are likely to respond "I can help with that."

                                Ron Jeffries
                                www.XProgramming.com
                                Knowledge must come through action;
                                you can have no test which is not fanciful, save by trial. -- Sophocles
                              • Steve Bate
                                ... We ve moved into the topic of requests for assistance rather than project management and status tracking. Imagine people only requested help on urgent
                                Message 15 of 16 , Mar 19, 2005
                                • 0 Attachment
                                  > From: Ron Jeffries [mailto:ronjeffries@...]
                                  > ...
                                  > A very powerful example: imagine that when people needed help, they
                                  > posted on a wiki. Then wiki prowlers would be the only people ever
                                  > to give help. But if people mention in the standup meeting that they
                                  > need help, IME more folks are likely to respond "I can help with that."

                                  We've moved into the topic of requests for assistance rather
                                  than project management and status tracking.

                                  Imagine people only requested help on urgent issues at a daily standup
                                  meeting? Personally, I think it's far better to ask for help when one
                                  needs it, especially when it's an urgent issue, rather than relying on
                                  either a wiki or a standup meeting for that purpose.

                                  Some people will wait until the standup meeting to ask important
                                  questions although everybody is sitting in the same room all the time.
                                  I've actually seen this happen a few times and it's baffling to me. This
                                  is an example of how excessive reliance on the standup meeting as the
                                  primary means of requesting help is a productivity risk (although a
                                  relatively mild one, IME).

                                  As for project management and status tracking, I've seen teams that
                                  used web-based tools (some with email notification) for this purpose
                                  and the people who wanted the information had no trouble getting it
                                  -- and everyone on these particular teams wanted it. I've read on
                                  this list about teams that are not able to use online project
                                  management tools effectively and I'm trying to understand the
                                  differences between their situation and the ones I've experienced.

                                  Steve
                                • Ron Jeffries
                                  ... Yes ... it s an example. ... Certainly. I m the guy who s in favor of push, not pull, after all. However, it s an example of push. It is common in standup
                                  Message 16 of 16 , Mar 19, 2005
                                  • 0 Attachment
                                    On Saturday, March 19, 2005, at 5:47:37 PM, Steve Bate wrote:

                                    >> A very powerful example: imagine that when people needed help, they
                                    >> posted on a wiki. Then wiki prowlers would be the only people ever
                                    >> to give help. But if people mention in the standup meeting that they
                                    >> need help, IME more folks are likely to respond "I can help with that."

                                    > We've moved into the topic of requests for assistance rather
                                    > than project management and status tracking.

                                    Yes ... it's an example.

                                    > Imagine people only requested help on urgent issues at a daily standup
                                    > meeting? Personally, I think it's far better to ask for help when one
                                    > needs it, especially when it's an urgent issue, rather than relying on
                                    > either a wiki or a standup meeting for that purpose.

                                    Certainly. I'm the guy who's in favor of push, not pull, after all.

                                    However, it's an example of push. It is common in standup meetings
                                    to address three things: what we did yesterday, what we plan to do
                                    today, and what is standing in our way. When these things are
                                    spoken, understanding and interactions happen that would not happen
                                    if we just posted something in a more passive medium.

                                    > Some people will wait until the standup meeting to ask important
                                    > questions although everybody is sitting in the same room all the time.
                                    > I've actually seen this happen a few times and it's baffling to me. This
                                    > is an example of how excessive reliance on the standup meeting as the
                                    > primary means of requesting help is a productivity risk (although a
                                    > relatively mild one, IME).

                                    Yes ... we're now at the other end of the spectrum of course. From
                                    publishing on a wiki to pushing the information out at a standup, to
                                    pushing it out all the time. Since I find that people aren't all
                                    equally reliable at pulling information, I favor pushing it out, in
                                    all the ways at our disposal.

                                    > As for project management and status tracking, I've seen teams that
                                    > used web-based tools (some with email notification) for this purpose
                                    > and the people who wanted the information had no trouble getting it
                                    > -- and everyone on these particular teams wanted it. I've read on
                                    > this list about teams that are not able to use online project
                                    > management tools effectively and I'm trying to understand the
                                    > differences between their situation and the ones I've experienced.

                                    I believe that it's not a difference in the situation, but in the
                                    people. It would surprise me if everyone on the teams you mention
                                    was really equally on top of things, but I'm sure it's possible. Some people read the news, some watch it, some hear about it
                                    from their friends. It might be thought that the ones that read it
                                    are "more interested". It might even be true. But if we want
                                    everyone to know the news, we need to be aware of and accommodate
                                    these differences.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Accroche toi a ton reve. --ELO
                                  Your message has been successfully submitted and would be delivered to recipients shortly.