Working in teams is great. And a massive pain. It depends on a lot of
things: the other team members, the team lead, the project itself, your
motivation for being in the team, the structuring of the team, plus the
general environment of the team. Obviously, in a normal job, the
individual doesn't have too much influence on most of these factors:
your team lead is a given, project is set by your boss, you've got a
given position determined by what others think is best, the environment
is set ... most of the factors you'll have no influence on.
Things are supposed to be different in an open source project. You have
much more of a say in things: you determine what, if anything, you
contribute. You determine what parts of the project you're working on,
if any. The structure of the team is - with a bit of luck - also
something you can have effect on. Open source projects could thus be a
dream come true in terms of development experience: people that want to
work together on a project they want to participate in. What could go
wrong?
Needless to say, tons of things could make things problematic in OS
projects. My personal experiences come from working with
BeWelcome, a hospitality/cultural exchange
organisation and website. Founded on the bad experiences a number of
people had with other sites (notably
HospitalityClub and
Couchsurfing) these people set out to
avoid the problems they saw with the other sites. This, unfortunately,
led to defining BeWelcome first negatively in terms of the other sites
and only secondly to try defining it positively. In terms of the
organisation it has led to a lot of bureaucracy - something that has
also been felt in the various teams, including the dev team. The main
problem has been a lack of clearly defined leadership. There have been
team leads, for sure, great ones as well, but an overall problem with
leadership in the project has influenced all teams as well (a team
environment factor: the outside world influencing the team because the
team feels it should mimic the outside world).
By far the biggest problem that I have experienced till now, though, has
been lacking a team lead. After the last guy stopped no one stepped up
to the plate so we've been working without one for a while now and boy!
does that suck if there are ever differences between members in the
team. Lacking a clear way to resolve differing opinions, point out the
way or decide upon the priority of tasks is a major problem. Even just a
thing like processes in the team needs a team lead to enforce them: if
one person doesn't like the way things are done and starts working in a
different way, who's to stop her?
While it's true that in an OS project anyone can step up and take on
ownership, human nature would have it that not everyone does. In a
project that runs on volunteer motivation, taking part already costs
energy ... and taking on more responsibility can easily be too much.
There's no extra pay to sweeten the deal, no perks, just more
responsibility, more people calling on you to help them with bug fixes
and feature requests. Obviously, seeing the project take the right turns
and head in the right direction is a reward, but is it enough to
outweigh the extra weight on your shoulders? I think the amount of
people fighting to take on the role of team lead reflects just how much
status is attached to the project - in most situations, it's not going
to be many people.
Then what?
The possibilities for dealing with leadership in development teams fall
in three groups:
- having a team lead
- sharing the team lead role between several members
- not having a team lead
1. This is the obvious possibility and the best in my opinion. In
order for it to work properly, a good team lead is required but it's a
role in which people can learn and rise to the task.
2.This means cutting the role down to size, sharing out
responsibilities and making sure the resulting roles are not too big or
too small. If the team gets the roles right and make sure there are no
overlapping responsibilities, this can probably work almost as good as
option #1. It's a requirement that the roles are clearly defined and
that the people sharing the team lead role can work together without
problems.
3. An alternative to having a lead is having clearly defined
processes and sticking to them. If the group can agree to some clearly
defined procedures for working and follow them, most differences in the
every run of things can be resolved by pointing to the rules. Bigger
differences in opinion or view of goals and mission can be resolved
through a democratic show of hands in the group. This solution might
work if all the people in the team shares a mindset and like to work
together, but if not it's doomed from the outset.
In BeWelcome we're currently going with option #3 and my personal
experience is that it's not working and it's not worth using - we're
spending way too much time discussing and arguing things, and there's no
option for resolving differences over working processes. Too many
confrontations which takes time away from development.
So, time to change things.