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

884Re: daily status blogs

Expand Messages
  • Hal Macomber <hal@halmacomber.com>
    Feb 10, 2003
      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? ;)


      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      > 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
      > I'm opposed to verbal communication, just that email can be so much
      > for little things.)
      > So, this company didn't have a big reliance on email and I needed a
      > to do the things that Mary describes below--mostly, threaded
      > 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
      > 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
      > 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
      > 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
      > 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
      > 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
      > worst) it seems so much harder to achieve today due to the reasons
      > 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
      > > 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
      > 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
      > 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
      > 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
      > 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
      > 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
    • Show all 21 messages in this topic