[MUD-Dev] Re: DevCore Project Management

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Adam Wiggins wrote:
> to get done.  The idea behind the benevolent dictator is that at some
> point he or she can simply say, "Okay, we've discussed it to death - here's
> how we're going to do it, end of discussion."  JC does this for mud-dev.
> Linus does this for Linux.  It works well as long as people continue to
> perceive them as benevolent.

Hmm... This perceived ownership is tied to up-front investment...  It is
easier, if you are able to establish that type of ownership, but then you
become really dependent on that one person. And he _has_ to produce more
than everybody else, I think?

In the most successful (process wise) project group I've been in (not
software) any authority would have been a waste, too strong personalities,
too much competitive peers. So basically process is dependent not only on
project, but also on team members. In such a group having a
"bookkeeper/QA/pushy person" seems to work quite well. Peers reach consensus
or agree to disagree, but decides to yield because of the future of the
project (group failure is seen as worse). An appointed leader would have
been perceived as a threat rather than as a safety mechanism ;). Competitive
peers can be quite productive. (We used a leader during meetings of course
(rotated))

Anyway, I think it is a good idea to discuss process, formalize
responsibilities and conflict resolution up front.  You cannot construct
those during a conflict (it will be seen as unfair), someone will become
unhappy and leave. An official decision diary perhaps, to avoid reoccurring
discussions of whether something is decided or not...  It is utterly
boooring to have to make the same decision 2 months later because the former
was never formally accepted.

It might be a good idea to think about whether the first system is going to
be a prototype (expected to be completely redesigned) or is to be a
"production" system (expected to support running muds). I guess that
there would be less conflict if one went for the first approach. Then you
can always say: Ok, we understand your needs, we'll look into it in the
next major iteration...
Different expectations being a nasty source for conflict. (which is one
reason for why talking through the vision is good)  

Hmmm, the forking stuff in that Halloween article was interesting... Watch
out!! :*)
--
Ola

(I don't see conflict as a problem, avoiding conflict is worse.
 Hegel: Thesis - antithesis - synthesis.)