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
      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.
    • 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 2 of 21 , Feb 12, 2003
        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 3 of 21 , Feb 13, 2003
          > 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.