I have been reading Hunt and Thomas's The Pragmatic Programmer (which I probably don't have to recommend to anyone anymore) and was pretty astonished when I read the section "Pragmatic Teams" in chapter 8. Everything I read seemed to ring a familiar bell somewhere in the back of my head. And every ring could be translated to "been there, done that"; I was part of a team like that once.
There were four (and a half) of us. We joined the company one by one and worked separately at first. Later, when the company hired more programmers, we became one of two teams working on the company's two (partly overlapping) products. Unofficially, we were the "senior" team, since all of us had worked in the company longer than anyone in the other team. (Nowadays I would say such division is probably not the way to go...) But to many of us, this was the first (IT-related) job and our skills were based only on academic studies and personal spare-time projects.
We still managed to triumph. (When I say "we", I mainly mean the others. Although I did my share of some improvements, I was more like an innocent bystander compared to the others.) Perhaps the biggest reason for this was that things were in a horrible state. There was no source code control system. There were no builds (and I am not talking about automated builds here, but builds in general). There was no way of knowing which version of the product each client had. (Well, since there were no versions, this was quite understandable.) There was no documentation whatsoever on the database tables the products used. I guess nobody liked it that way. Things had just happened when there were a couple of people writing code as fast as they could, and soon most of the work was putting out small fires everywhere. However, even the bugs that were found were not reported anywhere.
The team managed to change much of this. We started using source code control. We started writing small descriptions of database tables we added or modified, and put those in a common binder. (It would have been better to use plain text documents and store them in the version control system, but at least we did something...) We built a small intranet that included a bug-reporting service and a bug database. The customer service people could add bug reports and follow the fixing process as we assigned each bug to one of us and kept track of its status. Using the version control, we started making builds and keeping track of the versions each customer had. (We also made a proper installation media for the software but I think it was mainly done in the other team.)
We also did things that were not that obvious but which Hunt and Thomas mention in their book (and their book was out by then, so this probably wasn't a coincidence - even though I personally didn't read it back then). We came up with a name for the team and used it in all of our documents, and pretty soon the rest of the organization started using the name, too. We shared knowledge by making small handouts of books we had read and sharing them with other members of the team and everyone else in the company who was interested. We added a page in the intranet where people could write short reviews of new books. We even had names for the builds we were making (thanks to Pekka and his imagination :) ). And we sat together in one small corner of the company office, talking out loud when we faced problems.
Even though we all eventually left the company to find new (and probably not so many) challenges, I can truly say we all learned a lot. And while doing it, we had some serious fun. I can't say I miss working there in whole. But I definitely miss working as a part of that team. *sob*