Martin Fowler writes that he prefers functional organization over a technical organization with regard to development teams. I think Martin’s perspective comes from internal development teams within a single company.
If you read his description of technical organization, he lists several negatives about a technical organization, all of which I consider valid points. It becomes clear that he considers functional organization to have a single major drawback. To quote Martin, “Functional teams tend to do things their own way and not communicate with each other much, which leads to this kind of wasteful duplication.” Emphasis is mine.
I added emphasis to the “tends to” statement because tendencies can be managed. If you have teams that are large enough to need structure, I would argue that you should have an ad-hoc staff organization. By an ad-hoc staff organization, I propose that the development staff have specialists. But I would not have permanent teams. I would ask developers to be flexible to work on any functional project, and allow them to apply their expertise.
I know that meetings are often considered a bad thing, but I would have two types of regular meetings. I would have functional meetings where all the developers of a particular project gather to discuss the functional issues they encountering. I would also have some regular meetings for technical discussions. All the DBAs get together, for example, to discuss the tehcnical issues they are dealing with on their current functional project. The technical meetings would probably not occur as frequently as the functional meetings.
The technical meetings could also be handled informally through discussion through a discussion forum, a blog, or a wiki. They don’t usually need as much interaction as a functional discussion, so these communication methods can be quite useful.
For each new project, I would not assign the same people all the time. I would mix the teams up. When maintenance issues arise on a particular project, I would not always assign Joe to work on it just because he was the one who wrote the code in the first place. Because this method has no fixed structure, I call this an “ad-hoc” structure.
I realize that this kind of structure requires active management. It also requires that there be certain domain experts who are available as resources. I also realize that there may be a little productivity lost while developers peform maintenance on functional projects for the first time.
I admit that I haven’t worked in this kind of environment, so I may be proposing a socialst-style structure that won’t work. It sure seems to make sense to me, right now, though.