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.
    • Dean Goodmanson
      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.
      Message 2 of 21 , Jan 31, 2003
      • 0 Attachment
        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


        __________________________________________________
        Do you Yahoo!?
        Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
        http://mailplus.yahoo.com
      • Paul Hodgetts
        ... I like what the article says about opening up the flow of information about the project, and removing secrecy. I think this is a vital part of what makes
        Message 3 of 21 , Jan 31, 2003
        • 0 Attachment
          Dean Goodmanson 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?

          I like what the article says about opening up the flow of
          information about the project, and removing secrecy. I
          think this is a vital part of what makes agile processes
          successful.

          The article talks about using a weblog to form a community
          between the development organization and the users/customers
          /partners, which is interesting. It may be a tool to help a
          single "customer" (e.g., product manager) that has to act as
          a proxy for a larger group of actual customers/end users.

          But I don't think it applies well to the immediate
          development team. They shouldn't be isolated enough from
          each other to make the use of a weblog something they would
          choose to do.

          I prefer the daily scrum/stand up meeting for communicating
          status amongst the immediate team members, which includes
          all the developers, the "customers" (product manager, QA,
          IA/UI folks), and the project manager(s). At this level of
          immediacy and detail, the higher bandwidth and dynamics of
          face-to-face communication facilitates the work much better.

          This assumes the immediate team is collocated, and that a
          permanent record of the daily status is not an issue
          (although it could be captured by a scribe if need be).
          Distributed "immediate" teams are a whole different issue.

          For communicating to more distant team members, perhaps a
          weblog might work. I've never tried it, but instead we use
          just a normal doc, distributed at the end of each weekly
          iteration. Frankly, daily status for non-immediate team
          members is overkill and probably a warning sign of micro-
          management at too high a level.

          Regards,
          Paul
          -----
          Paul Hodgetts -- President, Principal Consultant
          Agile Logic -- www.agilelogic.com
          Consulting, Coaching, Training -- On-Site & Out-Sourced Development
          Java, J2EE, C++, OOA/D -- Agile Methods/XP/Scrum, Use Cases, UI/IA
        • Ron Jeffries
          ... Yes. Plus, the weblog, or a wiki, does not implement communication. It implements /publication/ which is emphatically not the same thing. ... Yes. Strongly
          Message 4 of 21 , Jan 31, 2003
          • 0 Attachment
            On Friday, January 31, 2003, at 3:38:07 PM, Paul Hodgetts wrote:

            > But I don't think it applies well to the immediate
            > development team. They shouldn't be isolated enough from
            > each other to make the use of a weblog something they would
            > choose to do.

            Yes. Plus, the weblog, or a wiki, does not implement communication. It
            implements /publication/ which is emphatically not the same thing.

            > I prefer the daily scrum/stand up meeting for communicating
            > status amongst the immediate team members, which includes
            > all the developers, the "customers" (product manager, QA,
            > IA/UI folks), and the project manager(s). At this level of
            > immediacy and detail, the higher bandwidth and dynamics of
            > face-to-face communication facilitates the work much better.

            Yes. Strongly agree.

            Ron Jeffries
            www.XProgramming.com
            To be on the wire is life. The rest is waiting. --Karl Wallenda
          • Alan Shalloway <alshall@netobjectives.co
            Although publication often results in no communication, I can atest that my company and many of our clients get a lot of communication done via wikis and
            Message 5 of 21 , Jan 31, 2003
            • 0 Attachment
              Although publication often results in no communication, I can atest
              that my company and many of our clients get a lot of communication
              done via wikis and bulletin boards. In fact, often _better_
              communication than verbally.
              Alan Shalloway


              --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
              <ronjeffries@a...> wrote:
              > On Friday, January 31, 2003, at 3:38:07 PM, Paul Hodgetts wrote:
              >
              > > But I don't think it applies well to the immediate
              > > development team. They shouldn't be isolated enough from
              > > each other to make the use of a weblog something they would
              > > choose to do.
              >
              > Yes. Plus, the weblog, or a wiki, does not implement
              communication. It
              > implements /publication/ which is emphatically not the same thing.
              >
              > > I prefer the daily scrum/stand up meeting for communicating
              > > status amongst the immediate team members, which includes
              > > all the developers, the "customers" (product manager, QA,
              > > IA/UI folks), and the project manager(s). At this level of
              > > immediacy and detail, the higher bandwidth and dynamics of
              > > face-to-face communication facilitates the work much better.
              >
              > Yes. Strongly agree.
              >
              > Ron Jeffries
              > www.XProgramming.com
              > To be on the wire is life. The rest is waiting. --Karl Wallenda
            • Ron Jeffries
              ... How do you ensure that everyone who needs the word gets the word? Ron Jeffries www.XProgramming.com Only the hand that erases can write the true thing. --
              Message 6 of 21 , Jan 31, 2003
              • 0 Attachment
                On Friday, January 31, 2003, at 5:01:10 PM, Alan Shalloway <alshall@...> wrote:

                > Although publication often results in no communication, I can atest
                > that my company and many of our clients get a lot of communication
                > done via wikis and bulletin boards. In fact, often _better_
                > communication than verbally.

                How do you ensure that everyone who needs the word gets the word?

                Ron Jeffries
                www.XProgramming.com
                Only the hand that erases can write the true thing. -- Meister Eckhart
              • Alan Shalloway
                Trust and e-mails. Everyone in my company, for example, is supposed to check the recent changes topic and look. Otherwise, we post an entry to the wiki and
                Message 7 of 21 , Jan 31, 2003
                • 0 Attachment
                  Trust and e-mails.
                  Everyone in my company, for example, is supposed to check the recent
                  changes topic and look. Otherwise, we post an entry to the wiki and
                  just tell people - hey read this!

                  The advantage is two of us can have a conversation when a third person
                  isn't there and then they can catch up by reading the entries. For many
                  things, however a bulletin board with a threaded discussion is better.
                  We use both, depending upon the type of material to be discussed.

                  We have one client who uses a wiki to discuss QA issues - relates
                  acceptance tests back to the use-cases. We have another client who uses
                  a bulletin board (we like the UBB from info pop - cheap and easy) to
                  coordinate his customers (they've got lot's of users so the lead - who
                  plays the role of customer as he used to be one - coordinates with
                  dozens of customers to get a single voice).

                  Alan Shalloway, Sr. Consultant, CEO
                  office: 425-313-3065. mobile: 425-531-0810

                  Net Objectives' vision is effective software development without
                  suffering. Our mission is to assist software development teams in
                  accomplishing this through a combination of training and mentoring.


                  -----Original Message-----
                  From: Ron Jeffries [mailto:ronjeffries@...]
                  Sent: Friday, January 31, 2003 2:15 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Re: daily status blogs

                  On Friday, January 31, 2003, at 5:01:10 PM, Alan Shalloway
                  <alshall@...> wrote:

                  > Although publication often results in no communication, I can atest
                  > that my company and many of our clients get a lot of communication
                  > done via wikis and bulletin boards. In fact, often _better_
                  > communication than verbally.

                  How do you ensure that everyone who needs the word gets the word?

                  Ron Jeffries
                  www.XProgramming.com
                  Only the hand that erases can write the true thing. -- Meister Eckhart


                  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/
                • Ron Jeffries
                  ... Trust is good. So is email. ... Of course, I see the advantage. Do you see the disadvantage? ... Yes, lots of people use them. They re good. They have that
                  Message 8 of 21 , Jan 31, 2003
                  • 0 Attachment
                    On Friday, January 31, 2003, at 5:21:50 PM, Alan Shalloway wrote:

                    > Trust and e-mails.

                    Trust is good. So is email.

                    > Everyone in my company, for example, is supposed to check the recent
                    > changes topic and look. Otherwise, we post an entry to the wiki and
                    > just tell people - hey read this!

                    > The advantage is two of us can have a conversation when a third person
                    > isn't there and then they can catch up by reading the entries. For many
                    > things, however a bulletin board with a threaded discussion is better.
                    > We use both, depending upon the type of material to be discussed.

                    Of course, I see the advantage. Do you see the disadvantage?

                    > We have one client who uses a wiki to discuss QA issues - relates
                    > acceptance tests back to the use-cases. We have another client who uses
                    > a bulletin board (we like the UBB from info pop - cheap and easy) to
                    > coordinate his customers (they've got lot's of users so the lead - who
                    > plays the role of customer as he used to be one - coordinates with
                    > dozens of customers to get a single voice).

                    Yes, lots of people use them. They're good. They have that one key
                    disadvantage, however.

                    Ron Jeffries
                    www.XProgramming.com
                    Accroche toi a ton reve. --ELO
                  • Alan Shalloway
                    Yeah, there are disadvantages. Verbal communication on some things is just more energizing and clearer. I don t mean to imply that written communication is
                    Message 9 of 21 , Jan 31, 2003
                    • 0 Attachment
                      Yeah, there are disadvantages. Verbal communication on some things is
                      just more energizing and clearer. I don't mean to imply that written
                      communication is superior to verbal, just sometimes (and at least not
                      always inferior).

                      The thing that is often overlooked in verbal communication (and
                      definitely in pairing in design/coding) is that there is synergy between
                      two people talking to each other. It can't be explained, but it can be
                      experienced. However, if it's opinions on things you want, or tracking
                      facts, written works well.

                      Alan Shalloway, Sr. Consultant, CEO
                      office: 425-313-3065. mobile: 425-531-0810

                      Net Objectives' vision is effective software development without
                      suffering. Our mission is to assist software development teams in
                      accomplishing this through a combination of training and mentoring.


                      -----Original Message-----
                      From: Ron Jeffries [mailto:ronjeffries@...]
                      Sent: Friday, January 31, 2003 2:32 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: Re: [scrumdevelopment] Re: daily status blogs

                      On Friday, January 31, 2003, at 5:21:50 PM, Alan Shalloway wrote:

                      > Trust and e-mails.

                      Trust is good. So is email.

                      > Everyone in my company, for example, is supposed to check the recent
                      > changes topic and look. Otherwise, we post an entry to the wiki and
                      > just tell people - hey read this!

                      > The advantage is two of us can have a conversation when a third person
                      > isn't there and then they can catch up by reading the entries. For
                      many
                      > things, however a bulletin board with a threaded discussion is better.
                      > We use both, depending upon the type of material to be discussed.

                      Of course, I see the advantage. Do you see the disadvantage?

                      > We have one client who uses a wiki to discuss QA issues - relates
                      > acceptance tests back to the use-cases. We have another client who
                      uses
                      > a bulletin board (we like the UBB from info pop - cheap and easy) to
                      > coordinate his customers (they've got lot's of users so the lead - who
                      > plays the role of customer as he used to be one - coordinates with
                      > dozens of customers to get a single voice).

                      Yes, lots of people use them. They're good. They have that one key
                      disadvantage, however.

                      Ron Jeffries
                      www.XProgramming.com
                      Accroche toi a ton reve. --ELO


                      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/
                    • Andrew Gilmartin
                      A principle advantage to using a weblog to support Scrum over a wiki to support Scrum is the time dimension. Weblogs are primarily organized by time. This
                      Message 10 of 21 , Feb 2, 2003
                      • 0 Attachment
                        A principle advantage to using a weblog to support Scrum over a wiki to
                        support Scrum is the time dimension. Weblogs are primarily organized by
                        time. This makes them a great tool for delivering project information to
                        tangential parties and keeping a record of the history of the project. Each
                        day's signature graph could be published in the weblog along with a
                        transcript of the stand up meeting. These parties now have a single place to
                        go to see what is happening without being a direct part of the sprint.

                        ps I thought the news.com article was awful. I don't think the author
                        understood that weblogs -- as they are used by most development projects --
                        have a single author with a single perspective and are not collaborative
                        tools at all.

                        --
                        Andrew Gilmartin
                        US Engineering Team Leader
                        andrew.gilmartin@...
                        401-743-3713 (cell)
                        andrewgilmartin (aim)
                      • Alan Shalloway
                        Andrew: I would appreciate your saying more about this. I have great experience with wikis and bulletin boards in supporting Scrum. We get some of the time
                        Message 11 of 21 , Feb 2, 2003
                        • 0 Attachment
                          Andrew:
                          I would appreciate your saying more about this. I have great experience
                          with wikis and bulletin boards in supporting Scrum. We get some of the
                          time issues done by using the recent changes page to find latest entries
                          (although this doesn't track things this way). We also just put entries
                          in at the bottom, so we get some chronological order.

                          I'll admit I've never used a blog and therefore do not know all of its
                          capabilities. One thing I really like about a wiki that I did not see a
                          blog could do was its sort of reorganizing capabilities. In other
                          words, when our wiki starts expanding in an area where it becomes
                          unwieldy, it is really easy to reorganize it by adding some pages and
                          splitting some things out (hyperlinks are wonderful aren't they?).
                          Also, little functions are easy to write in perl or vbscript if you need
                          them (two on our team can write special scripts so we can organize
                          things even more).

                          My impression (probably incorrect) of blogs is that they are best used
                          as an automated journal, so to speak. You can split things up into
                          topics, but hyperlinking from one to the other or reorganizing as new
                          structures makes sense is not that easy.

                          Please advise.

                          Alan Shalloway, Sr. Consultant, CEO
                          office: 425-313-3065. mobile: 425-531-0810

                          Net Objectives' vision is effective software development without
                          suffering. Our mission is to assist software development teams in
                          accomplishing this through a combination of training and mentoring.


                          -----Original Message-----
                          From: Andrew Gilmartin [mailto:andrew.gilmartin@...]
                          Sent: Sunday, February 02, 2003 6:48 AM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] daily status blogs

                          A principle advantage to using a weblog to support Scrum over a wiki to
                          support Scrum is the time dimension. Weblogs are primarily organized by
                          time. This makes them a great tool for delivering project information to
                          tangential parties and keeping a record of the history of the project.
                          Each
                          day's signature graph could be published in the weblog along with a
                          transcript of the stand up meeting. These parties now have a single
                          place to
                          go to see what is happening without being a direct part of the sprint.

                          ps I thought the news.com article was awful. I don't think the author
                          understood that weblogs -- as they are used by most development projects
                          --
                          have a single author with a single perspective and are not collaborative
                          tools at all.

                          --
                          Andrew Gilmartin
                          US Engineering Team Leader
                          andrew.gilmartin@...
                          401-743-3713 (cell)
                          andrewgilmartin (aim)


                          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/
                        • Andrew Gilmartin
                          ... This is correct. I was thinking only about supporting Scrum in particular and not software development in general. Wikis and weblogs offer good ways of
                          Message 12 of 21 , Feb 3, 2003
                          • 0 Attachment
                            > My impression (probably incorrect) of blogs is that they are best used
                            > as an automated journal, so to speak.

                            This is correct. I was thinking only about supporting Scrum in particular
                            and not software development in general.

                            Wikis and weblogs offer good ways of recording what is happening and why.
                            For long lived projects or projects with staff turnover having this record
                            is important to continuity. Both tools would benefit from being combined.
                            That is, the development record would greatly benefit from being accessible
                            from topic, time, and person dimensions. E.g., "show me everything about
                            search (topic) for AccessMedicine (topic) written by Andrew (person) and
                            Yuliya (person) early last year (time)."

                            -- Andrew

                            --
                            Andrew Gilmartin
                            US Engineering Team Leader
                            andrew.gilmartin@...
                            401-743-3713 (cell)
                            andrewgilmartin (aim)
                          • 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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.