Assume your company is developing some kind of service platform for business and/or consumer interaction (like mine does in the performance advertising area). At some point – your success is growing and growing – you suddenly will find yourself with eight development teams multiplied by four technical, architectural layers.
So the 1.000.000 Euro question is: how do you organize your teams to avoid ending up with a totally messed up technology stack?
Basically there are two approaches widely known: either you focus on component (a.k.a. layer/technology) teams, working “horizontally” in a layer, or on feature (a.k.a product/project) teams, working “vertical” through all layers.
Granted we speak about truely cross-functional teams, having all skills needed to do their best job in their fields, each of these approaches has its strengths and weaknesses:
| Pro | Contra | |
| Component Teams |
|
|
| Feature Teams |
|
|
As you see, neither is the right answer. In the Agile community the tendency seems to lead towards feature teams at a first glance. They promise fast delivery of customer value, setteled on virtues like collaboration, communication, and the pursuit of personal enhancement. But from my experience in a distributed, complex enterprise architecture developers tend to prefer the component team approach to care for their babies.
The question is: how to get the best from both sides (or eliminate the drawbacks)?
Well, let’s take a look at another “Agile” approach for spreading knowledge and driving innovation within a company: Communities of Practice. A self-organizing group of people sharing a craft, an interest, and/or a profession. So wouldn’t that be a possible tool to solve the conflict between great architecture and high value delivery?
I think so.
The idea is to keep feature teams but encourage the members having the skills and interests in maintaining and developing a technology layer to actively participate in an appropriate Community of Practice. The duty of this comunity is to assure a clean, maintainable, reliable architecture over a whole layer, striving for improvements – yet always keeping in mind that the user basically doesn’t care about awesome technology in a layer but about great, functional, working features he can use.
One more word on this Community of Practice thing. I heard people saying “It’s pointless. We didn’t see any valueable output from many of our communities.” Most times this came from the (middle) management. Well – I think it’s the duty of even this management to assure valueable output of such a community. By setting contraints and expectations, by supervising progress and results, by creating good working conditions for the community. Despite you need committed, self-disciplined people for producing great value.
