883RE: [scrumdevelopment] Re: daily status blogs
- Feb 10, 2003I 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.
From: Mary Poppendieck <mary@...> [mailto:mary@...]
Sent: Monday, February 10, 2003 12:44 PM
Subject: [scrumdevelopment] Re: daily status blogs
--- In firstname.lastname@example.org, "Pascal Roy"
> Hi Mary,What didn't work:
> Can you describe what was not working? What useful features do you
> think would help remotely located teams?
> Pascal Roy
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/
- << Previous post in topic Next post in topic >>