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

Re: [scrumdevelopment] Re: daily status blogs

Expand Messages
  • worleys@project-inspiration.com
    laughing I got so involved at looking in p-logs and blogs that I forgot that I am using sharepoint team services for a lot of my project and list tracking, and
    Message 1 of 21 , Feb 19, 2002
    • 0 Attachment
      laughing I got so involved at looking in p-logs and blogs that I forgot that I am using sharepoint team services for a lot of my project and list tracking, and using the discussions like a mini blog.
       
      heh, talk about not seeing the forrest for the trees ;)
       
      Scott Worley,
        Blind in the fa
      ----- Original Message -----
      Sent: Wednesday, February 19, 2003 12:35 AM
      Subject: Re: [scrumdevelopment] Re: daily status blogs

      Months ago I customized a wiki-engine to let a customer of mine use it for requirements management in a collaborative way. That tool is proprietary but I uploaded an alpha-version of an open source implementation here: http://armwiki.agilemovement.it/

      Development of this OpenSource version has been stopped on August 2002.....

      Just to let you know about it :-)

      >My current p-log plans focus on zwiki as a platform. see
      >http://webseitz.fluxent.com/wiki/ProjectManagementSoftware for linky
      >writeup.


      Marco Abis - CEO & Chairman
      Agility SPI: Software Process Improvement
      abis@... - abis@...
      http://agilemovement.it



      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Andrew Gilmartin
      ... I forgot to mention that I am assuming a software development team with a tendency to write as much as talk. Over the last five years, however, I have
      Message 2 of 21 , Feb 3, 2003
      • 0 Attachment
        > Wikis and weblogs offer good ways of recording what is happening and why.

        I forgot to mention that I am assuming a software development team with a
        tendency to write as much as talk. Over the last five years, however, I have
        found that I seem to be working more in verbal development cultures than
        written ones. I don't know if this is an industry trend or not.

        -- Andrew

        --
        Andrew Gilmartin
        US Engineering Team Leader
        andrew.gilmartin@...
        401-743-3713 (cell)
        andrewgilmartin (aim)
      • Mary Poppendieck <mary@poppendieck.com>
        I had experience using one of those project management sites with threaded discussions, issue tracking, and document management. We used it to coordinate a
        Message 3 of 21 , Feb 7, 2003
        • 0 Attachment
          I had experience using one of those project management sites with
          threaded discussions, issue tracking, and document management. We
          used it to coordinate a development team in Malaysia and two
          disperse teams in the US. Basically, it didn't work. The tool was
          too difficult to use, the information that needed to be communicated
          was too dense to be done by typing (you could spend all of your time
          typing), and the document management system was not useful –
          although that was what we needed more than anything. We reverted
          mainly to e-mail, tried an unsuccessful web-based issue tracking
          system, and finally settled on a spreadsheet-based defect tracking
          system. Nothing worked very well, and I'd sure love to see more
          useful tools in this area.

          I don't see how a weblog works to maintain outstanding issues, or a
          defect log. Of course we had a code repository, but it didn't work
          for use cases, or other preliminary models. We could have used
          better tools for all of these things. Our backlog was spreadsheet-
          based, but that seemed adequate.

          Mary Poppendieck

          --- In scrumdevelopment@yahoogroups.com, Dean Goodmanson
          <goodmansond@y...> wrote:
          > This article at CNet prompted a thoughts/questions..
          >
          > "Blogs open doors for developers"
          > http://news.com.com/2100-1001-982854.html?tag=fd_lede1_hed
          >
          > Thoughts..
          >
          > 1. Using a weblog/rss feed for daily reporting?
          >
          > 2. Communicating status to customers via a weblog?
          >
          > Best Regards,
          >
          > Dean Goodmanson
          >
        • worleys@project-inspiration.com
          Hmm this is interesting, maybe I should think about creating some tools for this if there is enough requests, I will certainly do. What do you reckon, people,
          Message 4 of 21 , Feb 8, 2003
          • 0 Attachment
            Hmm this is interesting, maybe I should think about creating some tools for this if there is enough requests, I will certainly do.
             
            What do you reckon, people, if there is enough feedback I will do and get this community to help me design it, maybe even set up a case study on scrum practice for this product for the community.
             
            please dump your comments either online here, or to my private account: zhangscott@... or worleys@...
             
            Scott Worley
            CTO
            Author: Inside ASP.NET, and a few others
            Speaker, Consultant and Enabler
            ----- Original Message -----
            Sent: Saturday, February 08, 2003 1:52 PM
            Subject: [scrumdevelopment] Re: daily status blogs

            I had experience using one of those project management sites with
            threaded discussions, issue tracking, and document management.  We
            used it to coordinate a development team in Malaysia and two
            disperse teams in the US.  Basically, it didn't work.  The tool was
            too difficult to use, the information that needed to be communicated
            was too dense to be done by typing (you could spend all of your time
            typing), and the document management system was not useful –
            although that was what we needed more than anything.  We reverted
            mainly to e-mail, tried an unsuccessful web-based issue tracking
            system, and finally settled on a spreadsheet-based defect tracking
            system.  Nothing worked very well, and I'd sure love to see more
            useful tools in this area.

            I don't see how a weblog works to maintain outstanding issues, or a
            defect log.  Of course we had a code repository, but it didn't work
            for use cases, or other preliminary models. We could have used
            better tools for all of these things.  Our backlog was spreadsheet-
            based, but that seemed adequate. 

            Mary Poppendieck

            --- In scrumdevelopment@yahoogroups.com, Dean Goodmanson
            <goodmansond@y...> wrote:
            > This article at CNet prompted a thoughts/questions..
            >
            > "Blogs open doors for developers"
            > http://news.com.com/2100-1001-982854.html?tag=fd_lede1_hed
            >
            > Thoughts..
            >
            > 1. Using a weblog/rss feed for daily reporting?
            >
            > 2. Communicating status to customers via a weblog?
            >
            > Best Regards,
            >
            > Dean Goodmanson




            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Pascal Roy
            Hi Mary, Can you describe what was not working? What useful features do you think would help remotely located teams? Pascal Roy ...
            Message 5 of 21 , Feb 10, 2003
            • 0 Attachment
              Hi Mary,

              Can you describe what was not working? What useful features do you think
              would help remotely located teams?

              Pascal Roy





              >From: "Mary Poppendieck <mary@...>" <mary@...>
              >Reply-To: scrumdevelopment@yahoogroups.com
              >To: scrumdevelopment@yahoogroups.com
              >Subject: [scrumdevelopment] Re: daily status blogs
              >Date: Sat, 08 Feb 2003 05:52:01 -0000
              >
              >I had experience using one of those project management sites with
              >threaded discussions, issue tracking, and document management. We
              >used it to coordinate a development team in Malaysia and two
              >disperse teams in the US. Basically, it didn't work. The tool was
              >too difficult to use, the information that needed to be communicated
              >was too dense to be done by typing (you could spend all of your time
              >typing), and the document management system was not useful �
              >although that was what we needed more than anything. We reverted
              >mainly to e-mail, tried an unsuccessful web-based issue tracking
              >system, and finally settled on a spreadsheet-based defect tracking
              >system. Nothing worked very well, and I'd sure love to see more
              >useful tools in this area.
              >
              >I don't see how a weblog works to maintain outstanding issues, or a
              >defect log. Of course we had a code repository, but it didn't work
              >for use cases, or other preliminary models. We could have used
              >better tools for all of these things. Our backlog was spreadsheet-
              >based, but that seemed adequate.
              >
              >Mary Poppendieck
              >
              >--- In scrumdevelopment@yahoogroups.com, Dean Goodmanson
              ><goodmansond@y...> wrote:
              > > This article at CNet prompted a thoughts/questions..
              > >
              > > "Blogs open doors for developers"
              > > http://news.com.com/2100-1001-982854.html?tag=fd_lede1_hed
              > >
              > > Thoughts..
              > >
              > > 1. Using a weblog/rss feed for daily reporting?
              > >
              > > 2. Communicating status to customers via a weblog?
              > >
              > > Best Regards,
              > >
              > > Dean Goodmanson
              > >
              >
              >


              _________________________________________________________________
              MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
              http://join.msn.com/?page=features/virus
            • Mary Poppendieck <mary@poppendieck.com>
              ... What didn t work: First of all, the project management system which was chosen was a bad choice. It was clumsy to use and had a structure which made
              Message 6 of 21 , Feb 10, 2003
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "Pascal Roy"
                <pascal_roy_1967@h...> wrote:
                > Hi Mary,
                >
                > Can you describe what was not working? What useful features do you
                > think would help remotely located teams?
                >
                > Pascal Roy
                >

                What didn't work:

                First of all, the project management system which was chosen was a
                bad choice. It was clumsy to use and had a structure which made
                relevant information difficult to find. It was laborious to set up,
                so it was set up quickly and poorly. I imagine there are better
                ones out there, but this one was chosen on the (mistaken) notion
                that it could be used as a time tracking system.

                Second of all, there was no motivator for using the system. It
                never replaced e-mail and regular video conferences as the way to
                exchange information. The biggest problem with most systems like
                this is that no one NEEDS to keep it up to date or read it to get
                information. Unless such a system becomes the only way to transfer
                information, it simply will not be used, because it is an extra
                step. And yet, it is not possible to transfer all – or even most –
                information by writing it down. Since this system did not work
                well, it was abandoned as the authoritative source of information.
                I think that EVERY blog, WIKI, or bulletin board suffers from this
                likely problem. Few become indispensable.

                What did we need?

                1. We kept and regularly revised use cases, because these were
                what everyone used to communicate. They were very useful, but they
                needed to be versioned and people had to know when a new version
                affecting them was posted. The mechanism for doing this was so weak
                as to be useless. Too bad, because assuring we were working with
                the latest use cases and notifying the RIGHT people when changes
                were made was not done very effectively. Everyone turned off the
                notification system immediately, because it flooded them with
                useless update notifications. In fact, full notification of any
                file changes or discussion postings was set `on' by default. One
                day I did a web file transfer of hundreds of files to fill the
                database, and every single member got an e-mail of every single file
                transfer. It brought down the e-mail server – since most people
                were in the same company – similar to a denial-of-service attack.

                2. We needed to be able to post issues – questions – that one
                team had of a remote team, with the expectation that the team
                needing to address the issue would know it was posted and address it
                the same day. This is much more tricky than a threaded discussion,
                but that was about the level of the tool we had to use. Again,
                notification of an outstanding issue was a big issue – e-mail always
                worked better. But also, you needed to have a trail of the
                discussion to see the progress of the issue, as well as a quick
                summary of outstanding issues. Also, typically, issues were
                assigned to someone to answer – normally the person who should know
                the answer. Then they would re-assign it, etc. The system needed
                to support this, but it didn't.

                3. The same kind of issue tracking system was needed to track
                defects, with perhaps a few added features, like defect resolution,
                date/build of resolution, etc.

                4. We needed general threaded discussions also, but they
                somehow never happened. Things like – this batch process is really
                tricky – who knows about it? Pretty much it's hard to replace face-
                to-face conversations in this regard.

                5. Finally, there was a BIG DEAL as to whether or not the
                customer should have access to the system. Because of the time
                tracking (which never worked) and because some things were written
                on the system that should not have been said in the presence of
                customers, they were never allowed access – which made the system
                really ineffective. It was a bad decision, and not one I agreed
                with.

                Mary
              • Mike Cohn
                I worked on a project that started in December 1994 and went through almost all of 1995. When I first got there the company admitted to having a voice mail
                Message 7 of 21 , Feb 10, 2003
                • 0 Attachment
                  I worked on a project that started in December 1994 and went through almost
                  all of 1995. When I first got there the company admitted to having a "voice
                  mail rather than email culture." I thought that was nuts because voice mail
                  is so much more intrusive for most little communications. (I'm not saying
                  I'm opposed to verbal communication, just that email can be so much better
                  for little things.)

                  So, this company didn't have a big reliance on email and I needed a system
                  to do the things that Mary describes below--mostly, threaded discussion
                  about issues and some way of noting when an issue had been resolved. We put
                  Lotus Notes in place and it was phenomenal. I spent a few nights learning
                  how to program for it and set up different databases, such as our "issues
                  database." When issues were added you could indicate who needed to help
                  resolve the issue (multiple people if you wanted) and each issue had a
                  default set of people it started with. Each was subsequently notified via a
                  Notes "inbox" (not email). As long as everyone logged into Notes once or
                  more per day it worked great. I've never had as much success on a project
                  with issue tracking and resolution.

                  What killed it was that the company eventually settled on a Microsoft email
                  server and client and the whole company started using email for all the
                  little issues that had been going into Notes. I doubt things would have been
                  better if we'd used Lotus' cc:Mail product as the cause was the increased
                  use of email, not any specific product. Gradually people stopped using Notes
                  at all (and by then we were on to new projects). It was fantastic while it
                  lasted but with everyone so addicted to email today (count me among the
                  worst) it seems so much harder to achieve today due to the reasons Mary
                  points out below.

                  -Mike

                  -----Original Message-----
                  From: Mary Poppendieck <mary@...> [mailto:mary@...]
                  Sent: Monday, February 10, 2003 12:44 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Re: daily status blogs

                  --- In scrumdevelopment@yahoogroups.com, "Pascal Roy"
                  <pascal_roy_1967@h...> wrote:
                  > Hi Mary,
                  >
                  > Can you describe what was not working? What useful features do you
                  > think would help remotely located teams?
                  >
                  > Pascal Roy
                  >

                  What didn't work:

                  First of all, the project management system which was chosen was a
                  bad choice. It was clumsy to use and had a structure which made
                  relevant information difficult to find. It was laborious to set up,
                  so it was set up quickly and poorly. I imagine there are better
                  ones out there, but this one was chosen on the (mistaken) notion
                  that it could be used as a time tracking system.

                  Second of all, there was no motivator for using the system. It
                  never replaced e-mail and regular video conferences as the way to
                  exchange information. The biggest problem with most systems like
                  this is that no one NEEDS to keep it up to date or read it to get
                  information. Unless such a system becomes the only way to transfer
                  information, it simply will not be used, because it is an extra
                  step. And yet, it is not possible to transfer all - or even most -
                  information by writing it down. Since this system did not work
                  well, it was abandoned as the authoritative source of information.
                  I think that EVERY blog, WIKI, or bulletin board suffers from this
                  likely problem. Few become indispensable.

                  What did we need?

                  1. We kept and regularly revised use cases, because these were
                  what everyone used to communicate. They were very useful, but they
                  needed to be versioned and people had to know when a new version
                  affecting them was posted. The mechanism for doing this was so weak
                  as to be useless. Too bad, because assuring we were working with
                  the latest use cases and notifying the RIGHT people when changes
                  were made was not done very effectively. Everyone turned off the
                  notification system immediately, because it flooded them with
                  useless update notifications. In fact, full notification of any
                  file changes or discussion postings was set `on' by default. One
                  day I did a web file transfer of hundreds of files to fill the
                  database, and every single member got an e-mail of every single file
                  transfer. It brought down the e-mail server - since most people
                  were in the same company - similar to a denial-of-service attack.

                  2. We needed to be able to post issues - questions - that one
                  team had of a remote team, with the expectation that the team
                  needing to address the issue would know it was posted and address it
                  the same day. This is much more tricky than a threaded discussion,
                  but that was about the level of the tool we had to use. Again,
                  notification of an outstanding issue was a big issue - e-mail always
                  worked better. But also, you needed to have a trail of the
                  discussion to see the progress of the issue, as well as a quick
                  summary of outstanding issues. Also, typically, issues were
                  assigned to someone to answer - normally the person who should know
                  the answer. Then they would re-assign it, etc. The system needed
                  to support this, but it didn't.

                  3. The same kind of issue tracking system was needed to track
                  defects, with perhaps a few added features, like defect resolution,
                  date/build of resolution, etc.

                  4. We needed general threaded discussions also, but they
                  somehow never happened. Things like - this batch process is really
                  tricky - who knows about it? Pretty much it's hard to replace face-
                  to-face conversations in this regard.

                  5. Finally, there was a BIG DEAL as to whether or not the
                  customer should have access to the system. Because of the time
                  tracking (which never worked) and because some things were written
                  on the system that should not have been said in the presence of
                  customers, they were never allowed access - which made the system
                  really ineffective. It was a bad decision, and not one I agreed
                  with.

                  Mary



                  To Post a message, send it to: scrumdevelopment@...
                  To Unsubscribe, send a blank message to:
                  scrumdevelopment-unsubscribe@...

                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                • Hal Macomber <hal@halmacomber.com>
                  Mary s description of project collaboration and tracking environments was oh-too familiar. We have a practice of not providing the tools teams need (threaded
                  Message 8 of 21 , Feb 10, 2003
                  • 0 Attachment
                    Mary's description of project collaboration and tracking environments
                    was oh-too familiar. We have a practice of not providing the tools
                    teams need (threaded discussion) while insisting they use the
                    coprorately approved tools. This only adds waste to the project
                    while tearing down the spirit of the team.

                    I was the event producer (project manager) for the 2001 US Freestyle
                    (Skiing) Championships. I used an eGroup for that. The environment
                    was simple even though the task was immense. It helped that we were
                    all volunteers (all 400 of us). We had a middle school english class
                    do all the PR writing stories for the local papers every week. We
                    worked out the terms of our sponsor contracts among about 10 people
                    spread over the country. We organized the 400 volunteers for a
                    series of tasks that they had never performed before. It was hard
                    work, fun, and we used just the tools we needed to use.

                    Let's remember that. Provide only those tools that are of value to
                    the team AND they are prepared to use. Everything else is waste.

                    We might not agree on what we should be doing. Currently, best
                    practices fall short of sound theory. While we continue to work that
                    out, there are three things we can be doing:

                    ..1 Grant project teams legitimacy to do the job they set out to
                    do. Don't ask them to do what doesn't add value.
                    ..2 Be unconditionally constructive in our interactions with teams.
                    (more Larry Bird than Bobby Knight)
                    ..3 Continue to experiment, collaborate, and innovate project tools
                    and practices. There's a crack in the project paradigm; let's
                    redouble our efforts.

                    So, in the spirit of this posting, tomorrow I will offer this group
                    my half-baked, hare-brained premature specification for a p-log. I
                    have been working on this to publish on my weblog in the next month
                    along with a template design. Instead, let's see what this group has
                    to say. And need I ask you to be unconditionally constructive? ;)

                    Hal

                    --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                    wrote:
                    > I worked on a project that started in December 1994 and went
                    through almost
                    > all of 1995. When I first got there the company admitted to having
                    a "voice
                    > mail rather than email culture." I thought that was nuts because
                    voice mail
                    > is so much more intrusive for most little communications. (I'm not
                    saying
                    > I'm opposed to verbal communication, just that email can be so much
                    better
                    > for little things.)
                    >
                    > So, this company didn't have a big reliance on email and I needed a
                    system
                    > to do the things that Mary describes below--mostly, threaded
                    discussion
                    > about issues and some way of noting when an issue had been
                    resolved. We put
                    > Lotus Notes in place and it was phenomenal. I spent a few nights
                    learning
                    > how to program for it and set up different databases, such as
                    our "issues
                    > database." When issues were added you could indicate who needed to
                    help
                    > resolve the issue (multiple people if you wanted) and each issue
                    had a
                    > default set of people it started with. Each was subsequently
                    notified via a
                    > Notes "inbox" (not email). As long as everyone logged into Notes
                    once or
                    > more per day it worked great. I've never had as much success on a
                    project
                    > with issue tracking and resolution.
                    >
                    > What killed it was that the company eventually settled on a
                    Microsoft email
                    > server and client and the whole company started using email for all
                    the
                    > little issues that had been going into Notes. I doubt things would
                    have been
                    > better if we'd used Lotus' cc:Mail product as the cause was the
                    increased
                    > use of email, not any specific product. Gradually people stopped
                    using Notes
                    > at all (and by then we were on to new projects). It was fantastic
                    while it
                    > lasted but with everyone so addicted to email today (count me among
                    the
                    > worst) it seems so much harder to achieve today due to the reasons
                    Mary
                    > points out below.
                    >
                    > -Mike
                    >
                    > -----Original Message-----
                    > From: Mary Poppendieck <mary@p...> [mailto:mary@p...]
                    > Sent: Monday, February 10, 2003 12:44 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: [scrumdevelopment] Re: daily status blogs
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Pascal Roy"
                    > <pascal_roy_1967@h...> wrote:
                    > > Hi Mary,
                    > >
                    > > Can you describe what was not working? What useful features do
                    you
                    > > think would help remotely located teams?
                    > >
                    > > Pascal Roy
                    > >
                    >
                    > What didn't work:
                    >
                    > First of all, the project management system which was chosen was a
                    > bad choice. It was clumsy to use and had a structure which made
                    > relevant information difficult to find. It was laborious to set
                    up,
                    > so it was set up quickly and poorly. I imagine there are better
                    > ones out there, but this one was chosen on the (mistaken) notion
                    > that it could be used as a time tracking system.
                    >
                    > Second of all, there was no motivator for using the system. It
                    > never replaced e-mail and regular video conferences as the way to
                    > exchange information. The biggest problem with most systems like
                    > this is that no one NEEDS to keep it up to date or read it to get
                    > information. Unless such a system becomes the only way to transfer
                    > information, it simply will not be used, because it is an extra
                    > step. And yet, it is not possible to transfer all - or even most -
                    > information by writing it down. Since this system did not work
                    > well, it was abandoned as the authoritative source of information.
                    > I think that EVERY blog, WIKI, or bulletin board suffers from this
                    > likely problem. Few become indispensable.
                    >
                    > What did we need?
                    >
                    > 1. We kept and regularly revised use cases, because these were
                    > what everyone used to communicate. They were very useful, but they
                    > needed to be versioned and people had to know when a new version
                    > affecting them was posted. The mechanism for doing this was so
                    weak
                    > as to be useless. Too bad, because assuring we were working with
                    > the latest use cases and notifying the RIGHT people when changes
                    > were made was not done very effectively. Everyone turned off the
                    > notification system immediately, because it flooded them with
                    > useless update notifications. In fact, full notification of any
                    > file changes or discussion postings was set `on' by default. One
                    > day I did a web file transfer of hundreds of files to fill the
                    > database, and every single member got an e-mail of every single
                    file
                    > transfer. It brought down the e-mail server - since most people
                    > were in the same company - similar to a denial-of-service attack.
                    >
                    > 2. We needed to be able to post issues - questions - that one
                    > team had of a remote team, with the expectation that the team
                    > needing to address the issue would know it was posted and address
                    it
                    > the same day. This is much more tricky than a threaded discussion,
                    > but that was about the level of the tool we had to use. Again,
                    > notification of an outstanding issue was a big issue - e-mail
                    always
                    > worked better. But also, you needed to have a trail of the
                    > discussion to see the progress of the issue, as well as a quick
                    > summary of outstanding issues. Also, typically, issues were
                    > assigned to someone to answer - normally the person who should know
                    > the answer. Then they would re-assign it, etc. The system needed
                    > to support this, but it didn't.
                    >
                    > 3. The same kind of issue tracking system was needed to track
                    > defects, with perhaps a few added features, like defect resolution,
                    > date/build of resolution, etc.
                    >
                    > 4. We needed general threaded discussions also, but they
                    > somehow never happened. Things like - this batch process is really
                    > tricky - who knows about it? Pretty much it's hard to replace face-
                    > to-face conversations in this regard.
                    >
                    > 5. Finally, there was a BIG DEAL as to whether or not the
                    > customer should have access to the system. Because of the time
                    > tracking (which never worked) and because some things were written
                    > on the system that should not have been said in the presence of
                    > customers, they were never allowed access - which made the system
                    > really ineffective. It was a bad decision, and not one I agreed
                    > with.
                    >
                    > Mary
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@e...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@e...
                    >
                    > Your use of Yahoo! Groups is subject to
                    http://docs.yahoo.com/info/terms/
                  • Pascal Roy
                    Thanks for sharing that Mary, I can t really point to specific products but my first impression is there has got to be some products out there that would allow
                    Message 9 of 21 , Feb 12, 2003
                    • 0 Attachment
                      Thanks for sharing that Mary,

                      I can't really point to specific products but my first impression is there
                      has got to be some products out there that would allow you to do a lot of
                      what you are looking for, no? Maybe I'm wrong. Or perhaps there are but
                      everything is not in one well integrated product...

                      Now that I thnk of it, I haven't been too impressed with the collaboration
                      tools I've tried up to now (especially in terms of people in the team
                      acutally using it even if they selected it)...

                      But then again, it would seem to be really hard to provide a
                      communication/cooperation tool that would fit all the needs of diverse teams
                      working under different conditions. Maybe that's why there is nothing out
                      there that has managed to stick...

                      It really is an interesting problem. Is it me or does it feel like it has a
                      tendency to polarize people in two camps? People looking for the tool to fix
                      all their communication problems and people who say that tools are useless
                      and you must communicate mano a mano to get things done anyway. But things
                      are not always ideal and we must very often live with very real constraints.
                      Perhaps there is a sweet spot in the middle where a good tool might actually
                      support enhanced communication for remotely located (and even collocated)
                      teams, we just need to figure what that is... Easier said than done...

                      Pascal Roy





                      >From: "Mary Poppendieck <mary@...>" <mary@...>
                      >Reply-To: scrumdevelopment@yahoogroups.com
                      >To: scrumdevelopment@yahoogroups.com
                      >Subject: [scrumdevelopment] Re: daily status blogs
                      >Date: Mon, 10 Feb 2003 19:44:27 -0000
                      >
                      >--- In scrumdevelopment@yahoogroups.com, "Pascal Roy"
                      ><pascal_roy_1967@h...> wrote:
                      > > Hi Mary,
                      > >
                      > > Can you describe what was not working? What useful features do you
                      > > think would help remotely located teams?
                      > >
                      > > Pascal Roy
                      > >
                      >
                      >What didn't work:
                      >
                      >First of all, the project management system which was chosen was a
                      >bad choice. It was clumsy to use and had a structure which made
                      >relevant information difficult to find. It was laborious to set up,
                      >so it was set up quickly and poorly. I imagine there are better
                      >ones out there, but this one was chosen on the (mistaken) notion
                      >that it could be used as a time tracking system.
                      >
                      >Second of all, there was no motivator for using the system. It
                      >never replaced e-mail and regular video conferences as the way to
                      >exchange information. The biggest problem with most systems like
                      >this is that no one NEEDS to keep it up to date or read it to get
                      >information. Unless such a system becomes the only way to transfer
                      >information, it simply will not be used, because it is an extra
                      >step. And yet, it is not possible to transfer all � or even most �
                      >information by writing it down. Since this system did not work
                      >well, it was abandoned as the authoritative source of information.
                      >I think that EVERY blog, WIKI, or bulletin board suffers from this
                      >likely problem. Few become indispensable.
                      >
                      >What did we need?
                      >
                      >1. We kept and regularly revised use cases, because these were
                      >what everyone used to communicate. They were very useful, but they
                      >needed to be versioned and people had to know when a new version
                      >affecting them was posted. The mechanism for doing this was so weak
                      >as to be useless. Too bad, because assuring we were working with
                      >the latest use cases and notifying the RIGHT people when changes
                      >were made was not done very effectively. Everyone turned off the
                      >notification system immediately, because it flooded them with
                      >useless update notifications. In fact, full notification of any
                      >file changes or discussion postings was set `on' by default. One
                      >day I did a web file transfer of hundreds of files to fill the
                      >database, and every single member got an e-mail of every single file
                      >transfer. It brought down the e-mail server � since most people
                      >were in the same company � similar to a denial-of-service attack.
                      >
                      >2. We needed to be able to post issues � questions � that one
                      >team had of a remote team, with the expectation that the team
                      >needing to address the issue would know it was posted and address it
                      >the same day. This is much more tricky than a threaded discussion,
                      >but that was about the level of the tool we had to use. Again,
                      >notification of an outstanding issue was a big issue � e-mail always
                      >worked better. But also, you needed to have a trail of the
                      >discussion to see the progress of the issue, as well as a quick
                      >summary of outstanding issues. Also, typically, issues were
                      >assigned to someone to answer � normally the person who should know
                      >the answer. Then they would re-assign it, etc. The system needed
                      >to support this, but it didn't.
                      >
                      >3. The same kind of issue tracking system was needed to track
                      >defects, with perhaps a few added features, like defect resolution,
                      >date/build of resolution, etc.
                      >
                      >4. We needed general threaded discussions also, but they
                      >somehow never happened. Things like � this batch process is really
                      >tricky � who knows about it? Pretty much it's hard to replace face-
                      >to-face conversations in this regard.
                      >
                      >5. Finally, there was a BIG DEAL as to whether or not the
                      >customer should have access to the system. Because of the time
                      >tracking (which never worked) and because some things were written
                      >on the system that should not have been said in the presence of
                      >customers, they were never allowed access � which made the system
                      >really ineffective. It was a bad decision, and not one I agreed
                      >with.
                      >
                      >Mary
                      >
                      >


                      _________________________________________________________________
                      Protect your PC - get McAfee.com VirusScan Online
                      http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
                    • Andrew Gilmartin
                      ... teams ... Once upon a time, long long ago, I once asked a toy maker how he could use an online tool to facilitate communication between all parties
                      Message 10 of 21 , Feb 13, 2003
                      • 0 Attachment
                        > But then again, it would seem to be really hard to provide a
                        > communication/cooperation tool that would fit all the needs of diverse
                        teams
                        > working under different conditions. Maybe that's why there is nothing out
                        > there that has managed to stick...

                        Once upon a time, long long ago, I once asked a toy maker how he could use
                        an online tool to facilitate communication between all parties involved in
                        building a toy. (If the toy is a girl doll that talks then you have clothing
                        designers, mold makers, mechanical engineers (the leg bone is connected to
                        the thigh bone, etc), embedded systems engineers, toy brokers or companies,
                        parts suppliers, etc. There is a long list of specialists.) He told me that
                        he *would not* use it. The reason it added another means of communication to
                        the project. And further, the communication did not allow for the transfer
                        of all the artifacts of the project -- examples of molded pieces for
                        example. His current modes of communication worked well for him and his
                        business. Telephone calls where handled by his assistant, postal mail came
                        once a day at 1pm, and FedEx came once a day at 11am. These where the points
                        in his day when the vast majority of people working on the project contacted
                        him. His day was thus mostly uninterrupted time with which he could
                        concentrate on the project at hand.

                        The principles here are that the tools should not add another mode of
                        communication and should not frequently interrupt your day. Most tools out
                        there do both. (Software folk seem to be obsessed with the clock inside
                        their computer.)

                        In my office text email and instant messaging (im) are the tools of choice.
                        To facilitate projects in my office a tool should allow communication via
                        email and im. For example, want yesterday's project signature send a simple
                        request to a chat-bot via im and have it return the signature via email (or
                        perhaps a URL in the im response). For example, expect to receive a project
                        status summary in email each morning between 7am and 9am.

                        Most tools want you to be in the tool's interface. I want my project
                        management tools to be in my communication interface.

                        -- Andrew

                        --
                        Andrew Gilmartin
                        andrew.gilmartin@...
                        401-743-3713 (cell)
                        andrewgilmartin (aim)
                      Your message has been successfully submitted and would be delivered to recipients shortly.