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

Re: [XP] XP Project Management tool recommendation?

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