Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

At previous employers I have suggested the idea of a Team Wiki and have never been able to get one implemented. I had bought into the concept so thoroughly that I assumed if I could ever just get approval then people would quickly see the value and start using it.

So when I brought the idea up at my new job I was very surprised to hear that it had already been tried... twice; And people didn't use it. It seems the main problem was that there was limited collaboration because the team was small and segmented (not a lot of duplicated work/roles).

It's a lost opportunity because one of the best times to implement a wiki is when you first bring someone on board (like me). Then every time they ask a question you have them document the answer for you and you review it to make sure that they understood. When the next new employee starts then have them search the wiki for answers before asking questions. If the information there is hard to understand or wrong, have them clarify or correct it.

The biggest benefit of having new people do the documentation is that they will get the details that are ignored by those who already know the system (because once you know a system everything seems intuitive and obvious).

I'll have to put some more thought into how to make wikis successful in small groups. In the mean time I've started documenting the details myself before I get too used to everything; maybe I'll get the chance to turn that information into a wiki yet.