884Re: daily status blogs
- Feb 10, 2003Mary'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 firstname.lastname@example.org, "Mike Cohn" <mike@m...>
> I worked on a project that started in December 1994 and wentthrough almost
> all of 1995. When I first got there the company admitted to havinga "voice
> mail rather than email culture." I thought that was nuts becausevoice mail
> is so much more intrusive for most little communications. (I'm notsaying
> I'm opposed to verbal communication, just that email can be so muchbetter
> for little things.)system
> So, this company didn't have a big reliance on email and I needed a
> to do the things that Mary describes below--mostly, threadeddiscussion
> about issues and some way of noting when an issue had beenresolved. We put
> Lotus Notes in place and it was phenomenal. I spent a few nightslearning
> how to program for it and set up different databases, such asour "issues
> database." When issues were added you could indicate who needed tohelp
> resolve the issue (multiple people if you wanted) and each issuehad a
> default set of people it started with. Each was subsequentlynotified via a
> Notes "inbox" (not email). As long as everyone logged into Notesonce or
> more per day it worked great. I've never had as much success on aproject
> with issue tracking and resolution.Microsoft email
> What killed it was that the company eventually settled on a
> server and client and the whole company started using email for allthe
> little issues that had been going into Notes. I doubt things wouldhave been
> better if we'd used Lotus' cc:Mail product as the cause was theincreased
> use of email, not any specific product. Gradually people stoppedusing Notes
> at all (and by then we were on to new projects). It was fantasticwhile it
> lasted but with everyone so addicted to email today (count me amongthe
> worst) it seems so much harder to achieve today due to the reasonsMary
> points out below.you
> -----Original Message-----
> From: Mary Poppendieck <mary@p...> [mailto:mary@p...]
> Sent: Monday, February 10, 2003 12:44 PM
> To: email@example.com
> Subject: [scrumdevelopment] Re: daily status blogs
> --- In firstname.lastname@example.org, "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?up,
> > 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 betterweak
> 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 withfile
> 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 peopleit
> 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,always
> 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 thehttp://docs.yahoo.com/info/terms/
> 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@e...
> To Unsubscribe, send a blank message to:
> Your use of Yahoo! Groups is subject to
- << Previous post in topic Next post in topic >>