Project Management: Communication

I’ve been working with Python/Zope/Plone for humm… more than 3 years
now. When I started, I had just left a small ISP where I worked as
sysadmin and php-master. We started a new company, me and 4 friends
from university, a guy that worked with me on the ISP and another guy
that worked with those 4 friends in a small web shop.

By the time we started, nobody had any Python knowledge, but everyone
could write some PHP. I think we were just like every other web shop
out there: a group of people trying to get some jobs done, everyone
trying to do it’s best but no notion of cooperative work. Everyone was
able to carry a project on its own, but for several reasons we haven’t
worked together on the same project except in extreme fuckup
cases. That was our notion of extreme programming. Program to the
extreme to try to revert the fuckup ;)

I’ve learned Python on my own, and I’ve learnt Zope quite
fast. Looking back, I can see how smart of a decision it was to drop
ZClasses right away. I think I only prototyped a small project in
ZClasses, say, for a week, and then never touched it again.

One of the main problems we had at that time was that I learnt way too
fast. While they were busy working on the orphaned projects from their
previous company, I was spending the whole day with Zope and
Python. Soon, I was the only person able to fix major fuckups, and the
only who could dig comfortably inside Zope. There was a huge gap of
knowledge that we didn’t had the time to fill, because we were all
busy doing real work. If we only knew that would mean slow death to
our company…

I’m pretty sure most of you have been through this, or are living it
right now. Just stop for a second and look around and you may
understand what I’m saying.

Now here I am. More than 3 years later, working for Enfold Systems,
a company in Texas. My closest co-worker lives 1000km from me, in the
same timezone. Another two in a timezone -3h from me, another in a
timezone -7h from me and another in a timezone +11h from me. I bet you
can imagine how hard it is to communicate within this
environment. Either you work late hours, or you send an email and wait
12h to get some feedback. Sometimes you just have no clue about what
everyone else is doing, unless you keep your irc client open and watch
the backlog closely.

Now, my question: is anyone out there experienced in working on this
kind of environment? How do you manage communication within the team?
And most importantly, how you spread knowledge within the team?

I can see the Ubuntu team, for example, facing a similar problem. It’s
even worse, because they are more and more far apart. Of course, they
have their own conference, but that only happens every couple
months. How do they manage those issues mentioned?

One thing I can say for sure. If you can identify you or your company
being on a situation like described above, you better take
action. Those modern days require dynamic teams, which can learn fast
and share knowledge. Everyone must be aware of what everyone else is
doing. The one-man-army cannot survive for long. Even worse for several
one-man-armies working inside the same company on the absence of a
general. Sooner or later they may turn against each other. And you may
find yourself alone, and jobless.


4 thoughts on “Project Management: Communication

  1. source repositories
    It seems like a source repository (CVS, svn, whatever) is the easiest place to start, especially if everyone throws everything in there. I.e., don’t wait for files to be finished. And also all the client-specific code, installation files, configuration, etc. Then there’s a fairly transparent and centralized repository of all those details that are often otherwise forgotten.

    If everyone pays at least a little attention to everyone else’s commits, it seems like a decent way to keep it together. It doesn’t capture the entire history of a bug report, or some of the transient system administration issues, but it does help. I try to create scripts for all but the most trivial administration tasks, which leaves behind evidence of what I’ve done and how others might do it.

  2. yes, thats the obvious start…
    …in fact, I can’t even think about checking in code without getting an email notification about the checkin. The same is starting to happen about tests. I feel very bad when I write code, even a single line, without writing a test for it. I’ve become very insecure with regards to just checkin code with no tests. I suspect that is a *good thing*, but others may think differently.

    Another idea I’ve been tinkering with is to setup internal mailing lists for discussion and announcements. Say, I start on a project, then I send an email to the internal list saying:

    ‘Hey, I’m starting this cool project and I’m thinking about using this and that technology, what you guys think? Anyone has a suggestion?’


    ‘Hey, I’ve faced this problem while doing X, and I’ve solved it by doing Y and Z’

    I suspect that can have a better short term effect than using a Wiki or some other way of communication. The only problem is if people *don’t use it* it *will never work*. Maybe what’s needed is some sort of dictator that prods people constantly to get them on track.

  3. quick and dirty
    I think if you wait until the code is pretty or tested or whatever before you check it in, a lot of code will never get in the repository. Or, if it had gotten in earlier maybe someone would have given feedback or caught something, or people would be more aware of the dead ends you pursued.

    It might be good to use conventions about locations, so that when code goes in some locations it doesn’t mean it’s good or useful or tested, but it exists. Also one-off code should go somewhere, but typically won’t have tests, or will be a shell script, or whatever. I think it’s valuable to prioritize the communication aspect of the repository over other standards.

  4. While I can’t comment the specific issue’s you’re referring to involving coding and such, as far as the communication issue goes, I think its something you just have to learn to deal with. The fact that you’re already using an IRC client is a good start. I’ve heard of some businesses setting up private blogs for project teams with different sub categories for different project related issues. Communication is always a tough hurdle to overcome when dealing with international project management. Good luck in finding a solution that works best for you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.