What are the personalities of the people in the team?
With 20 people, you might get 1 fellow enthusiast out to 4 or 5 who
wish to participate. And maybe even 1 or 2 who are actively hostile.
Don't worry about a forum, 20 people isn't enough to make it worth
while. If you have email, use an email alias, if it can be archived
somewhere, that's even better.
Getting a wiki would be good, something simple to begin with, you
want to have as few information repositories as possible. Between a
wiki and a mailing list that should be all you need.
If the wiki has comments, then that's most of the forum functional.
But expect little discussion. You need an audience of 1000's before
real discussion happens.
A good way to build wiki traffic is to write a wiki page and then
email the link around, always try and bring people back to the wiki to
get people into the habit of visiting there.
I can recommend Confluence (for $$ although there is a cheap license)
or MediaWiki. Value simplicity over function (both my suggestions are
rich)
A nice simple URL for the wiki is also good ('ie just 'wiki' not
synint01.na.company.com/prod/confluence/ )
Don't start with a big organisation structure with lots of stubs, let
it grow organically.
Be relentless, make your lunches happen like clockwork so people see
its a regular thing, encourage other participants (lightening talks
are good to limit the effort/time/exposure for the uncomfortable),
befriend new starters, get some support from management for anything
(pizza mainly)
Expect it to take time. (see point 1 about personalities). If you in
some kind of Type A personality world then it'll take of, if you are
like most places I've been, you'll be a voice in the wilderness for
longer than you expected, or potentially forever :)
On Jun 29, 7:01 pm, Phil <[email protected]> wrote:
> There are loads of different ways to introduce and encourage best
> practice but I think your biggest challenge is going to be making it
> stick when your 'teams' are so small.
>
> Are teams isolated physically from each other? I'd be looking to form
> bigger localised groups of developers so that there can be ongoing
> discussions and exchange of ideas.
>
> I'd also be thinking about a degree of mobility / knowledge transfer -
> so if you have a group of 5-6 people working on (say) 3-4 small
> projects, try and either spread the work a little further or rotate
> people through the projects.
>
> If you have one or two people following through a single project from
> beginning to end, in relative isolation, you're always going to get
> silo'd development to some degree. If you can get people into bigger
> groups and rotate projects (or bits of projects) around, you'll
> automatically start to get existing good practices propagating around,
> and you'll be more successful in encouraging/introducing others.
>
> On Jun 29, 2:57 am, Derek <[email protected]> wrote:
>
>
>
>
>
>
>
> > Howdy all,
>
> > Long time lurker, first time poster here (though I sent in the article
> > about the science of the honey badger referred to in ep 356).
>
> > I work in a research organisation that relies heavily on coders to
> > build stuff but large multi-person projects (e.g > 2 coders) are rare
> > and most work is on concept demonstrators (ie not for production). In
> > my area (~50 people, 20 coders) I'm trying to organise some sharing of
> > expertise (practices, tools, approaches, even development mentalities)
> > with a view to making it easier for us to integrate what we build.
>
> > In short, I would love any advice on how to do this. Other than
> > talking a lot with people, I'm going start up a Brown Bag lunch
> > session series (e.g. videos on Google Collections, use of git, and
> > learning Scala), documenting some of the practices in the small groups
> > I work with, and develop a website of some sort with a wiki and forums
> > to give a single location for people to look at for such information
> > (I was considering Drupal, but know bugger all about web tech - again,
> > recommendations greatly received).
>
> > My initial focus is to focus on spreading expertise and awareness,
> > though management is very receptive and wants actual collaboration, so
> > nothing about forcing the use of particular technologies or techniques
> > as yet. We mostly write in Java, so that's an advantage, but there's a
> > great deal of variety, even in areas like whether version control is
> > used (meep!), let alone what sort.
>
> > Anyway, any advice would be greatly appreciated. Thanks in advance.
>
> > Derek.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
