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

883RE: [scrumdevelopment] Re: daily status blogs

Expand Messages
  • Mike Cohn
    Feb 10, 2003
      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.


      -----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


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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 21 messages in this topic