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

Re: [XP] XP Project Management tool recommendation?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.