[TEAM] A couple of process suggestions

Peter Crowther Peter at ozzard.org
Thu Jun 9 23:02:55 UTC 2005


I'm a little scared to post this, as it's likely to stir up some
sentiment and I'm leaving for two weeks' vacation tomorrow.  Equally, I
want to comment, and the topic will be dead by the time I get back.  If
I can get to an Internet cafe, I'll try to respond to the flames...

> From: squeak-dev-bounces at lists.squeakfoundation.org 
> Subject: [REPORT] Report 3, kick in the behind!
> But is there something inherently wrong in the
> model or is there something we can improve to possibly maintain
> momentum?

1) Where possible, teams should be composed of team players.  This is
sometimes difficult in the Smalltalk world, which seems to attract the
lone developer to develop in the exquisite personal computing
environment.  Check the chapter on teams in McConnell's "Rapid
Development" - it's as relevant now as it was when it was written, and
the comments apply to open source development as much as they do to
commercial development.  The case study at the start of the chapter on a
dysfunctional team reminds me *so* much of the Squeak development
community.

2) The team leader should be able to ask team members to leave - this
should be made clear from the outset, and it should be made clear that
it is not a reflection on an individual's ability.  Sometimes a
well-meaning, motivated individualist wrecks a team unintentionally,
despite being a very good individual worker.  This needs to be dealt
with as soon as it arises, otherwise the team has a hard time working
together and can disintegrate.  The same person might work perfectly
well within a different team; sometimes it's the combination of
personalities that's the problem.

3) The team leader should be a leader.  The leader should not be someone
who has a known history of being a Jekyll and Hyde character who will
suddenly want off the team.  It doesn't motivate the team when that
happens.  Even if such a person is available and willing to act as team
leader, it may be preferable to pick an alternative person - even if
that delays the formation of the team until an alternative candidate is
found.

> And are there other things in the model we can improve?

Who selects team leaders?  Why them?  How are the leaders selected?

Do / should teams operate by consensus?  If so, how is it determined
when consensus is reached?  If not, how are decisions made?  Is the
decision as to how the team operates up to the team leader?  Is it up to
the team?  If it's up to the team, how is the decision made as to how
the decision is made as to the team operates?  [And so on to infinite
regression :-)]

What are the teams trying to do?  Do teams have realistic targets given
the effort that's available from the team members?  How many teams know
what their targets are?  How many teams know what effort is available
from their members?  Is the lack of progress now simply a reflection of
unreasonable targets that the team members didn't buy into?

All textbook stuff, I know - but textbooks contain this stuff for good
reason.  If we haven't thought about our team structures, the textbook
may be a good place to start.  If we *have*, the discussion about where
we've moved away from textbook models, and why, could be illuminating.
Oh - and if you want one textbook to read in this area, I'd suggest
Steve McConnell, "Rapid Development", Microsoft Press, for a broad and
entertaining treatment of the subject.  It's ten years old, but the
problems haven't changed much in that time.

		- Peter



More information about the Squeak-dev mailing list